I thought I ought to note this so I don’t forget. I’m running JBoss 4.2.2. GA, and yesterday I hot-deployed a .war project that contained classes that JBoss also had (it was the activemq-core .jar, I think). Anyway, the .war project hot-deployed ok and ran fine. It wasn’t until I shut down JBoss and started it up again that the class loading problems manifested themselves. This leads me to a rule of thumb:
Don’t consider the deployment testing complete until you’ve started JBoss with the deployment already in place.
If I hadn’t restarted JBoss when I did, I might have gone on to make other code changes, and the next time I restarted JBoss I would have seen the error and maybe attributed it to the new changes I had made… Eep!
I think I’m starting to understand why everyone around who has more experience with app servers than I do always seems to want to shut down JBoss before each new deployment, avoiding hot deploy.
Mainly a problem during development?
Hot deploy is probably not so problematic when you’re using stable, tested components. I bet it’s mainly a problem during development, when all the dependencies haven’t been fully worked out yet.
Another interesting hot-deploy behavior: phantom consumers
I just changed my MessageListener to not propagate exceptions. I hot-deployed my .war project to JBoss and used the ActiveMQ Console to send a message to the queue. The JBoss console showed that the message was duly picked up by the newly updated messagelistener. On a whim, I sent a second message to the queue. This time, I got a stack trace on the JBoss console — the MessageListener had thrown an exception, the way it did before I made my most recent code change. I looked in the ActiveMQ console and noticed that there were three consumers watching that queue, when normally there are two*. It looked like JBoss still had the old MessageListener running in addition to the new one! I restarted JBoss and the old exception-throwing MessageListener went away.
Update: The larger issue seems to be that the .war file is not cleanly undeploying (it leaves a consumer attached to the queue when it’s undeployed).
*I’m not sure why there seem to normally be two consumers and not one, watching the queue. (Update 2: I found out why there were two.)