Whether file changes are noticed or not depends on what loads the file to begin with. JSP changes are noticed because Tomcat looks for such changes. Various configuration xml file are noticed because the hot deployer looks for them. Even changes to log4j.xml are noticed by the logging service. But for everything else, changes are probably ignored. For a properties file, only if the code that reads the properties file checks for changes will the file ever be reloaded. If that is your code, you need to do the checking.
That makes sense, thanks.
Does it ever make sense to deploy an exploded archive? I've noticed that in the Ant build, as it copies the folder over, the JBoss console starts to show different parts of the application deploying in bursts and before the Ant build has completed. Is this expected behavior? (Should there be console output before the Ant build completes? This never happens with packaged archives...)
Is the only reliable way to deploy to JBoss through packaged archives? Or can exploded archives work reliably?
What's recommended for production use?
If exploded archives aren't good for production purposes, can they reliably be used in a development environment or will the problem with the Ant builds keep happening? (Btw, the Ant build happens from within Eclipse.)
I'd really like for the exploded archive strategy to work, because am I correct to say that the whole application won't be undeployed/redeployed as in the packaged archive case?
Can anybody please clarify all this for me?
As Ant copies over files, if the hot deployer wakes up, it will check what files have been updated even if Ant is not finished. There is no way to coordinate Ant and the hot deployer.
For production use, turn off the hot deployer. While this is a great developer feature I recommend not having it on for production. Do you really want who-knows-what being deployed to a production system? Additionally, consider the performance implications of having the hot deployer thread trash your CPUs cache and the thrash the disk every 5 seconds.
If you must deploy something, and the hot deployer is off, you can always copy it to the deploy directory and then invoke the deployer manually (via JMX). This works for exploded archives as well as for packaged ones.
Oh, that makes sense.
For production would you generally deploy things packaged or exploded (with the hot deployer turned off)? Any advantages to either (e.g. convenience, performance, other issues...)
Could you point me to resources for how to turn the hot deployer off and to invoke it manually? (Would both of these be done from within the JMX Console or through some configuration file...I can never tell the difference between these two approaches!)
If you package an archive, JBoss will unpack it to the tmp directory, so either way it works with unpacked applications. Of course, tmp is named that for a reason, you should not assume that anything in there is permanent in any way. So the way you deploy is really up to you and what you feel most comfortable with. I know that some of the denizens of this forum deploy exploded because their code can handle new or updated content, such as a servlet that serves PDF files, thus adding a new one to a directory that the servlet scans is easy.
To turn the hot deployer off, look at the jboss.system:service=MainDeployer MBean defined at the end of the server/default/conf/jboss-service.xml file. There are lots of comments there to guide you. To manually invoke the deployer, call the deploy method on that same mbean.
The documentation for this is at http://docs.jboss.com/jbossas/guides/j2eeguide/r2/en/html_single/#d0e3104.
How can I remove a servlet in a running JBoss instance? I want to debug the init() method of the servlet but it only runs the first time after being instantiated. The only option I see is to restart the server, which would not be a good option because of the time involved.
(I can't just delete the servlet from the deploy directory because it's part of an external library, so if I delete it I'm sure I'll break something else in the running app, requiring a restart anyways!) Hopefully JBoss has this capability.