We package our application as a .war file, we advertise support for JBoss AS5 and instruct our clients to copy the .war into their JBoss 'deploy' directory, and start up their application server in order to deploy the .war.
We are introducing support for JBoss AS7, so our deployment instructions for AS7 will have to change to something like
-copy the application.war to $JBOSS_HOME/standalone/deployments
-touch $JBOSS_HOME/standalone/deployments/application.war.dodeploy
-start JBoss AS7
This deployent method seems awkward to me, and possibly fragile, as failure to successfully create the *.dodeploy file would cause the deploy to fail. Also JBoss startup problems may cause the deploy to fail, causing the *.dodeploy file to be renamed *.failed - so it would have to be renamed back to *.dodeploy before attempting to redeploy. We are thinking the process seems a little awkward for some of our clients, who may not be familiar with JBoss AS7.
Is there any way to automate this deployment process so that it is smoother for deployers who may not be comfortable with how things work with JBoss AS7? How are other people handling this type of situation? thanks for any suggestions.
There is a web interface that's fairly easy to use. You can access it after JBoss AS7 has been started by going to http://localhost:8080. There is a link on that page that takes you to the administration console.
You could also write scripts for deployments using the CLI interface. There is some information here https://docs.jboss.org/author/display/AS7/Management+Clients about how to use it.
Lastly you can always write your own Java client to deploy applications. I wrote a blog post a while back on how to write a custom deployment CLI interface.
If you're aware of the marker files then you might have made a conscious choice to disable the automatic deployment mode for the deployment folder, which ships enabled by default. Autodeploy is great for everything but exploded files, and removes the need to manually manage the marker files. With autodeploy enabled, you can use the "touch" command on the application itself, which will update the timstamp and trigger the application for deployment (or redeployment). So you can still script if need be, but focus on the file rather than the marker files.
Just for reference, there are five ways to deploy files, of which three will be common to the typical administration setup. These are the graphical Management Console, the Management Command Line Interface (CLI) and the deployment folder you mention. The other two are via an IDE (such as JBoss Developer Studio or Eclipse with JBoss Tools), and even via Maven.
For people that may not be comfortable with the scripting as you say, then you can't go past the Manage Deployments section in the Console GUI. The Console deployment does not move/copy the application to the deployment folder, so using both the Console and the Deployment folder can make for some effort in file management.
For bash-savvy users, the CLI is great, and is often recommended by the AS7 team as a preferred method of deploying and managing applications. The user guide section on the CLI is located here: https://docs.jboss.org/author/display/AS7/Admin+Guide#AdminGuide-RunningtheCLI.
An example of all deployment methods can be found on this YouTube video by one of the developers: "5 ways to deploy your application to JBoss AS 7". Hope that helps.
You only need .dodeploy for exploded deployments. If your deployment is a zipped war,ear,etc. then it will be picked up automatically.
Change your deployment mode from manual to auto which does this deployment automatically.
Steps :
1) Open your jboss configuration file : standalone.xml.
2) Look for deployment-scanner and add auto-deploy-zipped="true"
<deployment-scanner scan-interval="5000" relative-to="jboss.server.base.dir"
path="deployments" auto-deploy-zipped="true" auto-deploy-exploded="false"/>
3) Restart your Jboss.
Now it will automatically pick your zipped version of ear/war/jar/sar files for deployment.
You can still use your old scripts without using any markers.
This can be changed in the standalone.xml by changing the "auto-deploy" attributes on the deployment-scanner element in the standalone.xml configuration file.
More details can be found in the deployments folder README.
Related
Recently, I have had to port an app from Tomcat to Wildfly and I'm currently working on setting up the modules directory for Wildfly.
It took a little bit of learning, but I figured out how to set up Spring, ActiveMQ RA, and several other libs as modules. This is working, but it has me worried about future maintenance of the modules directory. I have had to craft the entire directory by hand and I am worried about having to do this for every new dependency that every new app needs.
What are the best practices for maintaining JBoss Modules? Is the modules directory put into some version control system like SVN to detect and propagate changes?
Lets say I need a new framework in my app. From my understanding I would need to download the jars, create a modules directory for the jars, and then repeat this process for each environment in which I need Wildfly. What happens when needing to do this while other apps are running? This seems extremely time consuming in the long run.
I feel like there is a much better way to do this that I am either not realizing or too green with JBoss to understand.
With Maven and a pom, its so simple to hook up to a local or remote repo, and have the entire directory built out and available everywhere automatically. I feel like there must be something similar for JBoss Modules.
At the heart of my question: How are others using JBoss Modules and maintaining it within a production environment? What resources should I read or utilize?
Thanks for your time.
Kevin
I'm also looking for a solution for this.
I have previously been in projects where the JBoss CLI is being used. But I dont like that. It adds complexity as the JBoss CLI scripts are something new that developers need to understand. Changes in files are easier to understand.
I'm thinking of this:
Put a directory in a git-repo that has the exact directory structure as JBoss version used.
standalone-full.xml is put in git-repo/jboss-eap-6.4/standalone/configuration/standalone-full.xml
module.xml-files is put in git-repo/jboss-eap-6.4/modules/system/layers/.../module.xml
Also a setup.sh that will:
Copy the files from the git-repo to the installation directory of JBoss.
Download any jar-files, needed for the modules.xml, from a configured Nexus server. And put them into correct modules-directory.
The benefits are:
No binary files in git.
Changes to configuration of JBoss can be tracked.
The setup can be a part of a bigger scripted setup of for developers or docker images...
I'm working with Java and I've been asked to Hotreload a jar file to an ejb-server.
So my question is (and yes I've googled it!), what is the definition of Hot reload anyway?
It is hot deployment and not hot reload of ejb, which means, updating an EJB without having to stop and restart the application server. Few application servers support this few don't. You don't have to worry about it, its application server that provides it for your use.
Few application servers does it seamlessly, for example, In weblogic, you can just copy a modified jar file into your applications directory, and changes will take place immediately.
Is there a way to deploy apps without deploying it as a war file? At the moment I am repackaging and redeploying the war after every change. Is there a way to host it like IIS so changes can be done to an individual file without having to repackage and redeploy. Im using glassfish at the moment
Glassfish permits deploying applications and modules in an exploded directory format. It also supports automatic deployment and dynamic reloading.
You can hot deploy few things. By hot deploy I mean replacing the file not full app. Like hot deploying a jsp file, some static content there might be some more things. But then there are other things which may not work properly if you try to just replace a file.
Having said that it's not a recommended practice in most production environments. Most people would like to deploy a full war file.
But if you are simply looking for productivity in development environment you can use tools like JRebel. It works great. You don't have to keep deploying the war file again and again.
With Tomcat, you can configure the container to serve a webapp that is located in another directory (such as your build target directory) using a config file found under tomcat/conf/Catalina/localhost
But, you generally need to restart Tomcat if you make changes other than static content or JSP changes.
This sort of approach should be restricted to development environments only.
I agree with Laird Nelson that GlassFish can do that the reason is that Glassfish use Apache Felix which is an OSGI implementation (OSGi Framework and Service platform). Here you can find projects using felix. If you are using a simple Servlet Container like Tomcat there a lot of solutions.
I want to deploy a WAR to multiples tomcat servers (they may change) and do this from a java project.
I've searched and i find cargo, but in cargo i need to know all the servers were i want to deploy my WAR and create a config file with them. The thing is that those servers will change for sure in my enviroment (i may add some, remove some or modify some).
Is there any way i can do what i want?
i'll repeat what i want: From an java app deploy a WAR to a list of tomcat servers (running servers)
PS: sry for my english
EDIT:
this is an example of what i want to do:
Every tomcat its independent from the rest, its like ATM's and i want to "update" their "software" every time in a while, an ATM may be removed or added. so the number of ATM's to update may change
Why don't you publish your WAR file into a Maven repository and then use that as a platform for deployment? See the diagram in the following answer:
Should Artifactory NOT be used to capture the build artifacts that Jenkins produces?
This approach would neatly decouple the process that builds your software from the process(es) that deploy your software. Specifically you won't have to track your deployments in Maven anymore.
You can try with maven-deploy-plugin: http://maven.apache.org/plugins/maven-deploy-plugin/examples/deploy-ftp.html
You can configure where to put WAR file, there are possibilities to deploy using ssh or ftp protocol.
If you're running your Tomcats in a cluster, use the FarmWarDeployer.
I'm new to JBoss Seam and Java web app development in general. One thing that I cannot figure out while going through a few tutorials is how to redeploy beans that I've made changes to in an EJB project without having to restart the JBoss Application Server (6.0) that is hosting the JBoss Seam web project which uses the beans. The JBoss AS takes about 2 mins to start up, and it is painful making changes to the project and redeploying at present.
Some suggestions that I've read on the web include:
Using the jmx-console eg. go to http://localhost:8080/jmx-console/ ... ok, but how? What do I do exactly?
creating a build.xml file for ant, and get some sort of autodeploy thing going... are there any good examples around?
How do the rest of you more experienced JBoss Seam web app developers deploy your projects more rapidly?
Any help much appreciated, thanks.
This can be due to a number of reasons:
An application attempting to maintain state.
The new deployed application having a different classloader than the old one.
Other random causes. In our case, the jboss-classloading.xml configuration was not correct and this caused the hot deployment not to work.
Did you make any changes to your JBoss configuration? This can also lead to hot deployment issues.
Good luck.
Use JBoss hot redeploy feature: just remove your EAR (WAR) from deploy directory and copy there your new version.
Start JBoss in debug mode from your IDE (Eclipse). Then some code changes can be hot swapped directly into the JVM. If the hot swap fails, then do 1. hot redeploy.
Try great JRebel plugin. Much more powerful than 2. JVM hot swapping. You can combine Jrebel with 1. hot redeploys - when JRebel plugin fails, then do hot redeploy.
Just beware, hot redeploying may reveal memory leaks in some libraries (e.g. Jasperreports). If so, do restart your server. But you need to restart JBoss very rarely.
Another option that I have been told is to use the "Touch Descriptors" button (which is like a "quick redeploy" option) in JBoss.
Dev Studio 4.0 has it, not sure about earlier versions though. Apparently it creates a new timestamp on the server and forces the web.xml file to be re-read, thus redeploying.