Adding a removeDeployer loop in the MainDeployer.shutdown actually breaks the current start/stop mirror behavior since currently all but the bootstrap jar and sar deployers are added/removed in the SubDeployerSupport.startService/stopService methods. What makes more sense to me is to have the MainDeployer.shutdown stop all deployers which will have the side affect of undeploying all content and removing the deployers. What is inconsistent here is that the MainDeployer, JARDeployer and SARDeployer are started as bootstrap services by the ServerImpl, but shutdown does not simply stop and unregister these services in reverse order.
-- xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx
Rod Burgett wrote:
D-oh! That's embarrassing, I missed the finally block, thinking that 'return' meant return. Thanks for pointing that out.
I stumbled onto this duplication while investigating some extra warning messages during shutdown. I'm working on a patch to clean those up. I'll add something to that patch for this up as well.
The extra warning messages are from .war files nested inside .sar or .ear files; for example invoker.war inside http-invoker.sar. They both have entries in deploymentList, and undeploying the .sar undeploys the .war, which removes the .war from the deploymentList. But after the .sar undeployment finishes, shutdown() attempts to undeploy the .war, again. Why does it try again when the .war is no longer in deploymentList? Because shutdown is working from a copy of deploymentList.
You see the same message with welcome.ear and welcome.war. Also, I think the same sequence occurs with nested .jar files, but the JARDeployer doesn't complain, so it's not noticable.
I think the best solution for this is to add a removeDeployer loop to MainDeployer.shutdown(), prior to the 'undeploy everything in sight' loop. That will change the order of undeployment some, but not materially. Basically, this eliminates the duplicate undeployment by splitting it up, so a new deploymentList copy is made for each deployer.
Conceptually, this is a cleaner shutdown than the current one, since the current shutdown doesn't go through the removeDeployer processing. A graceful shutdown should mirror startup as much as possible.
This isn't a perfect solution, because this removeDeployer loop can't remove the JAR and SAR deployers. There may still be nesting scenarios - maybe an archive nesting an archive of the same type - where the list gets out of synch with it's copy. I'm open to other suggestions.
Rod Burgett Senior Software Engineer
webMethods, Inc. 3930 Pender Drive Fairfax, VA 22030 USA Ph: 703.460.5819 (tty only)
"It's all just 0s & 1s - the trick is getting them lined up in the proper order"
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
