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.
Related
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 am facing a very weird problem. This is one of those errors that just doesn't make sense. Please read till the end before jumping to conclusions.
When I deploy our web application (.ear file) containing web services written in Apache CXF on JBoss without making any changes to the web.xml file, everything seems to work fine.
When I make some changes to the web.xml file and rebuild the ear and redeploy the application, JBoss is unable to deploy my application because of some class loader conflicts. This is completely alright because I am expecting JBoss to throw these errors.
After I stop the JBoss server instance and revert the changes made in Step 2 to the web.xml and rebuild my .ear file and redeploy the application in JBoss, the same errors that were thrown in Step 2 are thrown again. How is this possible considering that I reverted all the changes I had made to the web.xml in Step 2 and restarted JBoss with a fresh .ear file to use?
I even tried downloading a fresh copy of JBoss and rebuilding and redeploying the application on the fresh copy. The same errors that were displayed in Step 2 are displayed in the application even though the web.xml no longer contains the changes that were made in step 2.
The only way I am able to get rid of the errors is by taking a fresh checkout of my code base and building my application and deploying a fresh version of my application in a fresh JBoss server. This doesn't make sense because changing the web.xml doesn't implicitly change other files or classes in the application as far as my knowledge goes.
I am clueless about how to solve this problem. The only change I make is to the web.xml file and I don't touch any other classes or files. Why do the errors persist permanently?
This time before you start your JBoss server, delete tmp and work folders under the server profile directory. That should take care of it.
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.
Environment: WinXP.
RAD: Version: 7.5.3 (Eclipse 3.4.2)
Websphere 6.1
I have two web projects on my local RAD environment and 4 or 5 sub jar projects. When I change classes in debug and regular start mode, the files don't get copied to the server for runtime.
So, normally I have to restart the server completely or add/remove the project all together.
I may make a change to Servlet.java
When I do "publish", the ear/application seems to restart, but my changes are not there. So I normally restart the server. This is a productivity killer.
Additional settings:
* Publish automatically turned off.
* Minimize resources. Use workspace.
What can I do to make sure that the classes get copied over.
My theories:
I have parent_first/application for the class loader/war settings. Is that an issue?
Maybe I should remove the ear and add it back to websphere
I did a clean on the server?
Delete your application from the server.
Restart the server
Go to the admin console and ensure the application is not listed in the list of applications, if it is then delete it.
Restart the server
Deploy/publish again.
Unfortunatelly, RAD with WebSphere are very unstable environment.
From my experience, debug mode is causing a lot of problems. It's mainly what you describe, changes not being seen after republish, additionally very quick memory depletion. I'm using debug mode as last report.
In normal mode everything should (read: in most cases) work correctly. You add/change some classes and make 'republish'. Sometimes it's necessary to do clean on project before republishing it.
But when the Websphere is running longer together with RAD, I observe that often something get stuck. You have there clean option on the server, with is expected to clean the cache (which included also compiled classes). You should also observe memory usage. If it's nearing the limits of JVM (memory leaks are heavy) Websphere stops to function correctly, and you must restart it.
However, I sometimes get serious issues where the clean isn't helping, and then it's necessary to remove all applications, stop the websphere (close all projects and open then again) and then start Websphere and add all applications, restarting RAD in the meanwhile. But it's not everyday, maybe every month or so...
If you are really unlucky, RAD can break your workspace, which will force you to delete all project, delete project files (or do a fresh checkout) and import everything once again, or even start a new workspace (happens also with 'normal' Eclipse, ~1-2 years).
You are using the latest RAD so do I... here is my guide for solving this issue:
Enable the error log to see if you get intuitive info on internal RAD errors, in 7.5 it is available on "Show views"
If your changes are not deployed Clean project
If your changes are not deployed yet Rebuild project
If your changes are not deployed yet Redeploy project
If your changes are not deployed yet Clean server
If your changes are not deployed yet Restart server
Or:
- Use ant or maven to make deployments straighforward and ignore the pain due to websphere and eclipse having internal bugs (which you may see in the error log if it is fully enabled).
Regards.
Are your JSPs copied correctly? That is, when you make a change in one JSP, can you see change immediately upon browser refresh? If this works, then I see no reason why classes aren't also published. JSP auto refresh should work in normal and debug modes.
Now, is "build automatically" enabled? If no, your classes won't get compiled and transferred. Parent_first/application for class loading shouldn't be an issue.
Is the local app. server running in development mode? If not, it should be.
While developing, use debug mode. Hot deploy will assure changes to your methods are seen immediately. Changes in classes won't be seen (i.e. adding a method will require application restart).
Is your app. server using global security? I have it turned off and auto redeploy works without problems.
Class reloading has always been a problem while developing Java EE applications. Try do erase that ear file from your WAS and redeploy it again.
If all else fails, try JRebel.