How do we a deploy a simple war file on the websphere server 8 without using the websphere administration console?
As a part of the manual deployment I will need to know,
where to put the war file manually on the server?
war uses jndi for db connection, since we do not want to use admin console,
how do we create jndi data sources?
we would also want to externalize the properties file. (like I used to keep
application.properties in JBOSS_HOME/server/default/conf folder in jboss instead of the app.war/web-inf/classes)
Please help
PS: Actually we will be having an ant build which will do these three things for us so that we don't have to go to the admin console. Just run the ant build and it will copy war, create jndi etc stuff.
The best way of doing what you want is writing a wsadmin script.
Using wsadmin you can deploy, add/delete/modify resources in WebSphere, pretty much anything.
I would suggest you read Getting started with wsadmin scripting
You can also use 'monitoredDeployableApps' folder under server profile. You can enable this feature from the admin console -> Applications -> Global deployment settings.
Simple and best way to do this is in two steps: (v 8+)
Enable 'monitoredDeployableApps' feature in Admin Console -> Applications -> Global Deployment Settings and restart the server. (once restart you will see a folder in your profile 'monitoredDeployableApps' (default name and can be changed while enabling this feature)
Drag and Drop your war file in this folder (no restart needed) and observer Systemout.log of the server. Verify in Admin Console for the deployed application.
NOTE: Make sure your context-root is populating to your deployable (war,ear,...) files.
-- Prakash Karri
Related
I am (finally) upgrading from JBoss5.1 to Wildfly 9.0.2.Final (standalone). I am trying to learn how to redeploy a zipped EAR via scp, hoping to have it picked up by the deployment scanner. Per the documentation, all I have to do is set auto-deploy-zipped="true" in standalone.xml (in the deployment descriptor), then copy the .ear into the deployments folder. However, when I do so the scanner places a 'failed' file in the deployments folder with this message:
"There is already a deployment called EAR with the same runtime name EAR.ear"
It sounds like it will not automatically redeploy. I tried adding a signal file named Ear.ear.dodeploy to deployments, but this made no change.
I am able to deploy the EAR via the administration console, but I'm hoping to 'save time' with this scp approach. Hasn't saved time yet! :)
Thanks for any help.
Josh
I figured this out. It turns out that the auto-deploy scheme won't work if you originally deployed the .ear via the administration console. The fix was simply to remove the .ear via the administration console, then take the steps indicated above. Now it deploys and redeploys as expected.
Just trying to setup remote deployment of projects to Jboss AS 4.2.1 using Jrebel.
After enabling the JRebel for my project in eclipse along with the remoting feature, it asks for the deployed app's URL in the server. How do I get to know the URL of my project so that I can mention that in the JRebel remoting section?
I thought of looking it up in the JMX console but my project jar will reside in the lib folder of the EAR that's deployed to the server, so I wasn't able to locate it there. Can anyone help me out?
JRebel Remoting requires a HTTP facing component to function. It makes use of the HTTP protocol using the same port as the web container. This means zero conf (sort of) and no holes to poke into the firewall, but the downside is that it won't work for apps with no WAR module in them (yet :)).
I assume your app is a jar file inside an ear. All it needs is a war module in that ear. That war does not need to have rebel.xml nor rebel-remote.xml in it. Create the WAR if one does not exist.
The URL would be the address you have to enter in a web browser to access that webapp. For example http://example.org:8080/MyWar/
Also make sure you have the rebel.xml and rebel-remote.xml in the deployed library project (simply creating them in Eclipse is not enough, those two xml files have to end up in the server).
Also, you need to install and activate JRebel on the remote server machine, then start JBoss with the following JVM arguments: -javaagent:path/to/jrebel.jar -Drebel.remoting_plugin=true
where path/to/jrebel.jar points to the installed jrebel.jar file
More info: http://zeroturnaround.com/software/jrebel/remoting/
In your case the layout of the EAR could look like this:
- myapp.ear
- webapp.war
- someEJB.jar
- lib/
- yourApp.jar
- WEB-INF/classes/
- rebel.xml
- rebel-remote.xml
- someOtherLib.jar
--
Arnel
JRebel Remoting Tech Lead
When webapps are deployed via Eclipse to Tomcat, $catalina_home/conf/server.xml is getting overwritten by Eclipse. This means, whatever changes I make to server.xml prior to app deployment is overwritten by Eclipse.
My application uses GridGain and hence I need to add the following line to server.xml:
<Listener className="org.gridgain.grid.loaders.tomcat.GridTomcatLoader" configurationFile="config/default-spring.xml"/>
Since Eclipse overwrites server.xml every time I deploy a new version of the app, I need to instruct Eclipse to insert the above line (this is applicable for all tomcat event listeners) as well during deployment. Is this possible? If not is there a workaround for GridGain based applications to be deployed via Eclipse?
Eclipse uses ${workspace}/Servers/${server-name}/server.xml for its configuration. That directory is created when you setup a new server. It's not overwritten every time you deploy the app but only if you make changes in the server config UI. If you need to add something manually to server.xml then do so and set the file to read-only e.g. directly in Eclipse:
locate the file (see path above)
right-click
Properties
Resource
enable "Read only"
That way Eclipse will ask/notify you everytime it tries to alter the file and you can allow/disallow that.
I have developed an web application using HTML, Java Servlet and all. While developing I was using Tomcat to deploy it in order to test it.
Now my development is done and I want to make it live. For that we have live server but as I am new to all this I dont know how to deploy my java web application on live server?
So please help me if you know to answer?
My Project Structure
ProjectName
->src
->beanClass
->class1
->Class2
->easyServlet
->Servlet1
->Servlet2
->Servlet3
->easyTrans
->Class1
->Class2
->Class3
->Class4
->build
->WebContent
->META-INF
->MENIFEST.mf
->WEB-INF
->lib(contain javascript files)
->web.xml
->html1
->html2
->html3
->html4
->html5
I am also using MySql so what I have to about it..
You will have to build a WAR of the project.
You can do this
in eclipse: right click on the project, Click "Export", and choose war file in the dialog (and mention, the destination, name and all)
via ant using the war task
The ant option is better because when you have multiple developers on the project and the code is in version control, it is easier to get the project automatically (using ant) and build a war. (you have version control, don't you?)
But this is more of an operational difference (albeit an important one) but the war created in either way are same
Deploy the war to the server
You can manually copy the war file to the $TOMCAT_HOME/webapps directory (See the "Creating and Deploying a WAR File" section on this article)
You can use the Tomcat 6 "Manager" application.
Update
You said that you are using MySql also. MySql should be installed on a server (it can be on the same server) and the configuration should be changed (username, password, server details) so that the application connects to the same database (I am sure you are not hard coding database details and credentials in your application and reading them from some configuration, this is the configuration that has to be changed)
For that we have live server but as I am new to all this I dont know how to deploy my java web application on live server?
I assume by this you meant , you have a public IP assigned to a server. Now you can install tomcat into this server and open the tomcat port for public and you will be able to access.
Now build a war file of your webapplication and put it into web-apps dir of the tomcat and start the server
Making a few assumptions here. You need
A tomcat instance running on your production server
Permissions to make changes to the tomcat instance
A war file that bundles your application
If you have both, then you need to navigate to the Tomcat manager page and follow the instructions to upload your war file.
Deploy the war to the server
You can manually copy the war file to the $TOMCAT_HOME/webapps directory.
You can use the Tomcat 6 "Manager" application.
I would like to collect some best-practices on deployment of a web-application to a running Tomcat. Not long ago I had to describe the deployment process of our web-application and the process appeared rather confusing.
Say, we have an application in a WAR file (foo.war) correctly configured and not requiring additional configuration. In this case, the deployment process is rather easy:
Copy the foo.war file to the $CATALINA_HOME/webapps directory. If the application starts correctly, the application will automatically deploy to $CATALINA_HOME/webapps/foo directory.
To undeploy the application:
Remove the foo.war file from the $CATALINA_HOME/webapps. If the application unloads correctly, it will be unloaded and the $CATALINA_HOME/webapps/foo will be removed.
Now I want to override some context parameters in my running application. Having read the docs, all I need to do:
Create a context.xml file called foo.xml
Copy the file to the $CATALINA_BASE/conf/[enginename]/[hostname]/ directory.
Unfortunately, that did not work: the application would not restart. Empirically, we found out that the only working solution is when the war file is deployed to a location outside the $CATALINA_HOME/webapps.
Besides, the default values of the configurable context parameters in the WAR file should be specified in the web.xml, since context.xml in the WAR file is not read when there is a context.xml outside.
Here is an easy example of the foo.xml:
<?xml version='1.0' encoding='utf-8'?>
<Context docBase="/path-to-deployment-directory/foo.war">
<Parameter name="myparam" value="newvalue" override="false"/>
</Context>
Be sure to specify override=false for the parameter if you want the 'newvalue' to override the value specified in the WAR's web.xml. This was not obvious for us.
Thus, to deploy an aplication to a running Tomcat:
Create a context.xml file called foo.xml
Copy the file to the $CATALINA_BASE/conf/[enginename]/[hostname]/ directory.
Copy the foo.war to the location specified in the docBase of the foo.xml; the application will deploy automatically.
To apply new context parameters:
Add the parameter values to the foo.xml and save the file; the application will re-deploy automatically.
To undeploy the application:
Remove the foo.xml from the $CATALINA_BASE/conf/[enginename]/[hostname]/ directory
Note that removing the foo.war will also work, but will remove the foo.xml as well.
By now, I have the following questions:
Is it a best-practice at all to deploy a web-application without stopping the tomcat? I heard an opinion that deployment to a running tomcat is never needed since people run each application in a separate tomcat.
Is it a good idea to copy WAR files to $CATALINA_HOME/webapps or they should better be kept in a separate location?
How can I configure an application deployed to $CATALINA_HOME/webapps
Why there is no INFO line in the catalina.out for deployment of an application and there is one for undeployment? Is it configurable?
On question (1), Tomcat works great for deploying servlets into a running server. There may be concerns w.r.t. security or possibly D.O.S. or provisioning reasons why you would have separate server instances.
You have the flexibility to do either way, but it is often more convenient to deploy to an already running server. This is a BUILT-IN feature in the servlet architecture. :)
For (2), again it is at your discretion where you you want to put WARs. It sounds like you already have it configured a non-standard (non-default I should say) way. Check your server.xml file for the settings in your server instance(s). Check for attributes like unpackWARs and autoDeploy.
For (3) and (4), plus your (1,2) questions, it might be a good idea to consult the Tomcat docs for your version of Tomcat on its deployment model. You should be able to use the same docs to figure out how your server has been configured.
See Tomcat Web Application Deployment in the Tomcat manual, adjusting for your version of Tomcat.
One solution would be to use the manager application. If you decide that is safe to use it, then you can easily deploy, start, stop and undeploy applications:
http://localhost:8080/manager/deploy?path=[context_path]
http://localhost:8080/manager/start?path=[context_path]
http://localhost:8080/manager/stop?path=[context_path]
http://localhost:8080/manager/undeploy?path=[context_path]
There are ant tasks that can help you with these.
I am guessing, but do not know for sure, that stopping and starting an application will make it reread the context.xml.
Regarding your second question, I believe it is better for maintenance reasons to keep the war files in the webapps directory.