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" > -----Original Message----- > From: Scott M Stark [mailto:[EMAIL PROTECTED] > Sent: Friday, July 04, 2003 9:35 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] multiple deployment info entries for > invoker.war > > > The cause of this is logic in MainDeployer.addDeployer to attempt > to deploy any waitingDeployments entries. The invoker.war is deployed > before there is a WAR deployer and as new deployers are added > an attempt > is made to reprocess the invoker.war. The MainDeployer.init > most likely > needs to be cleaned up to remove the update of the > deploymentList out of > the finally block since the only deployment in this list > should be those > with a deployer. > > -- > xxxxxxxxxxxxxxxxxxxxxxxx > Scott Stark > Chief Technology Officer > JBoss Group, LLC > xxxxxxxxxxxxxxxxxxxxxxxx > > Rod Burgett wrote: > > > I'm seeing something odd in the deploymentList for > > org.jboss.deployment.MainDeployer. You can see the results > by invoking > > listDeployed() method on MainDeployer from the jmx-console. > The output is > > from DeploymentInof.toString() for everything deployed. > > > > My output includes 4 copies of the DeploymentInfo for > > (server)/deploy/http-invoker.sar/invoker.war. They all > have the same object > > hash: [EMAIL PROTECTED] > > > > Also, if you replace the > > > > if (deploymentList.lastIndexOf(di) != -1) > > > > line of MainDeployer.destroy() with > > > > while (deploymentList.lastIndexOf(di) != -1) > > > > and add this line > > > > log.info("Removing > > deploymentList["+deploymentList.lastIndexOf(di)+"] for "+di.url); > > > > to the loop block, you'll see at shutdown that invoker.war > gets removed 4 > > times. > > > > I haven't found the cause yet. My first guess was that > it's related to the > > fact that there are 4 attempts to deploy invoker.war before > an appropriate > > deployer is found. But a quick look at the code seems to > indicate that it > > won't get into deploymentList until a deployer is found. > > > > It seems an innocuous, since they are 4 references to the > same object. > > Replacing deploymentList.add(...) with a conditional add > would eliminate the > > duplicates, but that really addresses the symptom, not the cause. > > > > Has anyone seen this? Searched down the cause? > > > > > > 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_06 > 1203_01/01 > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ------------------------------------------------------- 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
