I noticed that removeDeployer does a first-to-last traversal of deploymentList. I wondered if that was an oversight or part of some strategy that wasn't obvious to me.
But, it gets uglier. Commenting MainDeployer.shutdown() produces a batch of warnings from ServiceController.shutdown(), it complains about ignoring a request to stop/destroy/remove nonexistent services. Here's the scenario, as I understand it. startup: - xxx.jar is detected and deployed - service (EjbModule) is created to represent xxx.jar, - jboss.j2ee:service=EjbModule,url=...xxx.jar - xxx.jar contains ejb ABC - EjbModule.createService() creates a container for ABC - EjbModule.createService() creates a service to represent ABC bean container - jboss.j2ee:jndiName=ABC,service=EJB shutdown: - service controller shutdown finds ABC container service and stops/destroys/removes it - since containerServiceContext.dependsOnMe is empty, svc controller removes this context from nameToServiceMap - service controller shutdown finds xxx.jar service and tries to stop it - EjbModule.stopService() tries to stop the ABC container service, again - when svc controller.stop can't find the container context in nameToServiceMap, it whines about a nonexistent service - service controller shutdown tries to destroy xxx.jar service - EjbModule.stopService() tries to destroy the ABC container service, again - when svc controller.destroy still can't find the container context, it whines, again - service controller shutdown tries to remove xxx.jar service - EjbModule.stopService() tries to remove the ABC container service, again - when svc controller.remove still can't find the container context, it whines, again I'm guessing that this issue is masked by MainDeployer.shutdown's undeployment of everything. Since the containers aren't deployed, they aren't explicitly handled by MainDeployer.shutdown. Their jar file is undeployed and takes them along. It will probably show up in a scenario where a container is stopped, then it's jar service is stopped. It looks like declaring the xxx.jar to depend on the containers it creates would prevent the containers from being removed from nameToServiceMap. Though I don't see how - yet - to do that without either exposing ServiceContext in the controller mbean, or changing the bean deployment sequence so that the jars containers are known when its service is created. Reversing the order of service controller shutdown would solve this, but cause other problems. Changing the whine message level (WARN->INFO) would make the message less worrisome, but that addresses the symptom, not the problem. Putting the MainDeployer.shutdown() back with a removeDeployer loop will get rid of all the warnings, but breaks the service life cycle symmetry. Is there a good solution? Or only the lesser of evils? What am I missing? 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: Tuesday, July 08, 2003 1:54 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] multiple deployment info entries for > invoker.war > > > Theoretically, but a problem with not using the > MainDeployer.shutdown is that > the deployment shutdown order will change since the > MainDeployer.removeDeployer > method is not iterating over the deploymentList in reverse > order as is the case > for MainDeployer.shutdown. If this is corrected then the > shutdown method and the > ServerImpl*.shutdownDeployments method seem uneccessary and the > MainDeployer.shutdown could call the ServiceController.shutdown. > > -- > xxxxxxxxxxxxxxxxxxxxxxxx > Scott Stark > Chief Technology Officer > JBoss Group, LLC > xxxxxxxxxxxxxxxxxxxxxxxx > > Rod Burgett wrote: > > > I see what you are saying about breaking the mirror, the removal of > > deployers should be controlled by the deployer services. > > > > Code already exists in ServerImpl.ShutdownHook.shutdown() to invoke > > ServiceController.shutdown(), which walks backwards through > it's service > > list to stop, destroy and remove each. From what you say, > this could handle > > undeploying everything. Currently, nothing actually gets > undeployed at that > > point because MainDeployer.shutdown() gets called, and > undeploys everything, > > before ServiceController.shutdown() is called. > > > > So, if service shutdown effectively handles undeployment, > and preserves the > > mirror, is there really a need for MainDeployer to undeploy > anything at > > shutdown? Can MainDeployer do all its housekeeping in > destroyService()? > > Then what's left for shutdown() do? Except maybe ask the > service controller > > to stop the deployer services? > > > > > > > > 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: Parasoft > Error proof Web apps, automate testing & more. > Download & eval WebKing and get a free book. > www.parasoft.com/bulletproofapps > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ------------------------------------------------------- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
