Re: [JBoss-dev] multiple deployment info entries for invoker.war
David Jencks wrote: I don't know what you mean. Can you give a specific example? The example Rod gave of an ejb.jar deployment being stopped by shutting down the ejb container is an example. Again, I don't have any idea what you mean and an example would be very helpful. Personally, I think that the current version of XSLSubDeployer in head is very close to a good universal solution for deployment, with a couple of helpers that aren't yet written. The name XSLSubdeployer may not be ideal. I propose that all deployment is handled by a single chain of subdeployers. The chain links can be XSLSubDeployers and various things analogous to SARDeployer and ServiceConfigurator. XSLSubDeployer can be configured to look for and load into the DeploymentInfo any number of xml deployment descriptors, and to apply one or two xsl transformations of any xml documents that may be loaded. (There is a URIResolver that makes all loaded xml documents available to stylesheets). Currently this scheme is used in the jca deployer to construct standard jboss mbean deployment descriptors. This unfortunately results in excessively complicated xsl, at least with my level of xsl expertise. I think the solution to this problem is a wider variety of mbean configurators. For instance, it would be easy to write a configurator based on apache digester, which would apply rules to map xml elements to mbean construction and attribute setting. This might eliminate the need for complex metadata objects for, e.g., ejbs. Many if not all of the ejb configuration in the ejb metadata objects could be attributes of the container mbeans. The ejb-jar.xml and jboss.xml and possibly jbosscmp-jdbc.xml could be processed sequentially by sets of digester rules to directly create and configure the container mbeans. This would avoid the need to combine the 2 or 3 xml documents into one, which has proved to be an xsl nightmare. I think this will be more flexible and usable than a jaxb based solution which would require either combining the 2 or 3 documents into one, eliminating all redundancy (and introducing nightmare xsl), or a set of objects that delegate to each other depending on which document the required info actually came from. Yes, the currently XSL and population of the deployemnt info with dom elements is not what I want. There are two phases of deployment that are not clearly defined currently; parsing the deployment package and installing the services defined in the deployment. I'm saying this needs to be an explicit part of the deployer model. The result of step 1 is that there is a deployment info, with all metadata associated with it. There can be many ejb deployment processors dealing with the mapping of different versions of metadata representation onto the associated deployer. There are no xml doms at the end of this step, just the metadata. I don't buy the need or even desire to expose every piece of metadata that affects the deployment via JMX at this step. The deployment info should be an mbean available for information and possibly even in memory editing to trigger redeployment without have to go to the deployment descriptors. The apache digester mechanism could be used, but it does not solve the current problem of not having an external defintion of what metadata is valid for a given deployment. With jaxb you can have a schema spaning multiple namespaces and parse data from multiple documents. Until jaxb is shown as not viable it is the mechanism I want to use. Anything that we choose to replace jaxb should preferably support xml schemas so that tools and users have a basis for knowing what a deployment supports. Step 2 is the mapping of the deployment info to the mbeans identified by the deployment metadata. It is at this point that the deployer chooses which metadata it is willing to expose via jmx. I think the class loader setup itself needs to be a deployer that can look at the deployment classes and try to make a determination of what class loading model is needed. The JARDeployer should morph into this deployer perhaps. Calling stop on a service does not stop its dependent components. This requires invoking stop on the ServiceController. I agree. I think this involves moving the lifecycle/dependency stuff out of ServiceController into a central dependency mbean triggered by mbean interceptors. I also think these interceptors can take over most or all of the ServiceMBeanSupport functionality. Are you aware of any other problems this proposal doesn't solve? This would require all beans to be xmbeans and a change of the base interceptor stack to include a dependency interceptor. The only issue I see with this is updating the xmbean implementation to better delegate to the underlying resource. There is currently no provision to take metadata from a resource that implements DynamicMBean for example. - Being able to redeploy portions of a deployment. How can
Re: [JBoss-dev] multiple deployment info entries for invoker.war
On Friday, July 11, 2003, at 01:29 PM, Scott M Stark wrote: The whole service life-cycle, deployer, dependency management layer needs to be rethought to come up with a more coherent behavior. Right now there are too many ways a collection of components can be brought into the server and insufficient knowledge of how this was done to allow startup/shutdown to be service based. There is too much reliance on the deployment as a first class thing rather than just a packaging of code and metadata. I don't know what you mean. Can you give a specific example? Some issues that need to be cleared up include: - Removing the metadata from the deployers to allow them to be useful across deployment versions as well as minimizing the importance of the deployment package. A current issue related to this is that a given deployment package is only assigned to a single deployer as dictated by the primary deployment descriptor. This is too limiting and J2EE centric a view of a deployment package. Again, I don't have any idea what you mean and an example would be very helpful. Personally, I think that the current version of XSLSubDeployer in head is very close to a good universal solution for deployment, with a couple of helpers that aren't yet written. The name XSLSubdeployer may not be ideal. I propose that all deployment is handled by a single chain of subdeployers. The chain links can be XSLSubDeployers and various things analogous to SARDeployer and ServiceConfigurator. XSLSubDeployer can be configured to look for and load into the DeploymentInfo any number of xml deployment descriptors, and to apply one or two xsl transformations of any xml documents that may be loaded. (There is a URIResolver that makes all loaded xml documents available to stylesheets). Currently this scheme is used in the jca deployer to construct standard jboss mbean deployment descriptors. This unfortunately results in excessively complicated xsl, at least with my level of xsl expertise. I think the solution to this problem is a wider variety of mbean configurators. For instance, it would be easy to write a configurator based on apache digester, which would apply rules to map xml elements to mbean construction and attribute setting. This might eliminate the need for complex metadata objects for, e.g., ejbs. Many if not all of the ejb configuration in the ejb metadata objects could be attributes of the container mbeans. The ejb-jar.xml and jboss.xml and possibly jbosscmp-jdbc.xml could be processed sequentially by sets of digester rules to directly create and configure the container mbeans. This would avoid the need to combine the 2 or 3 xml documents into one, which has proved to be an xsl nightmare. I think this will be more flexible and usable than a jaxb based solution which would require either combining the 2 or 3 documents into one, eliminating all redundancy (and introducing nightmare xsl), or a set of objects that delegate to each other depending on which document the required info actually came from. - Coming up with a well defined service life-cycle diagram that is honored under all use cases. One simple problem that exists now is that the life-cycle operations exposed by a service do not integrate with the dependency management service. Calling stop on a service does not stop its dependent components. This requires invoking stop on the ServiceController. I agree. I think this involves moving the lifecycle/dependency stuff out of ServiceController into a central dependency mbean triggered by mbean interceptors. I also think these interceptors can take over most or all of the ServiceMBeanSupport functionality. Are you aware of any other problems this proposal doesn't solve? - Being able to redeploy portions of a deployment. How can redeployment of a war in an ear be allowed for example? Well, I've found I can redeploy just about any subpackage by simply invoking redeploy on it through the jmx console. Please explain any problems you have found with this. Of course this does not mean that the need to redeploy is easy to detect automatically. If you have ideas on this please explain. - Better automation of choosing the appropriate deployment class loading model taking into account duplicate/conflicting classes, missing classes, etc. The issue is being able to go from minimal canonical packages that need a flat shared class loading model to heavy weight packages that include redundant and conflicting classes with respect to the server and/or other deployments. I agree this is still a problem. Do you think a good start would be to list a bunch of use cases? So let's fix it. Agreed. Thanks /** * David Jencks * Partner * Core Developers Network * http://www.coredevelopers.net **/ Scott Stark Chief Technology Officer JBoss Group, LLC On Thursday, July 10, 20
Re: [JBoss-dev] multiple deployment info entries for invoker.war
The whole service life-cycle, deployer, dependency management layer needs to be rethought to come up with a more coherent behavior. Right now there are too many ways a collection of components can be brought into the server and insufficient knowledge of how this was done to allow startup/shutdown to be service based. There is too much reliance on the deployment as a first class thing rather than just a packaging of code and metadata. Some issues that need to be cleared up include: - Removing the metadata from the deployers to allow them to be useful across deployment versions as well as minimizing the importance of the deployment package. A current issue related to this is that a given deployment package is only assigned to a single deployer as dictated by the primary deployment descriptor. This is too limiting and J2EE centric a view of a deployment package. - Coming up with a well defined service life-cycle diagram that is honored under all use cases. One simple problem that exists now is that the life-cycle operations exposed by a service do not integrate with the dependency management service. Calling stop on a service does not stop its dependent components. This requires invoking stop on the ServiceController. - Being able to redeploy portions of a deployment. How can redeployment of a war in an ear be allowed for example? - Better automation of choosing the appropriate deployment class loading model taking into account duplicate/conflicting classes, missing classes, etc. The issue is being able to go from minimal canonical packages that need a flat shared class loading model to heavy weight packages that include redundant and conflicting classes with respect to the server and/or other deployments. So let's fix it. Scott Stark Chief Technology Officer JBoss Group, LLC On Thursday, July 10, 2003, at 06:24 AM, Rod Burgett wrote: 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 t
RE: [JBoss-dev] multiple deployment info entries for invoker.war
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. > > -- > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > 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 hous
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. -- Scott Stark Chief Technology Officer JBoss Group, LLC 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
RE: [JBoss-dev] multiple deployment info entries for invoker.war
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" > -Original Message- > From: Scott M Stark [mailto:[EMAIL PROTECTED] > Sent: Monday, July 07, 2003 11:35 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] multiple deployment info entries for > invoker.war > > > The bigger problem is that the deployment layer does not run > a clean state > machine. Requests to deploy content should not be allowed > when the MainDeployer > is being shutdown and therefore the deployment list copy is > not needed. > > 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. > > -- > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > 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.
Re: [JBoss-dev] multiple deployment info entries for invoker.war
The bigger problem is that the deployment layer does not run a clean state machine. Requests to deploy content should not be allowed when the MainDeployer is being shutdown and therefore the deployment list copy is not needed. 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. -- Scott Stark Chief Technology Officer JBoss Group, LLC 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/psa0016ave/direct;at.asp_061203_01/01 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] multiple deployment info entries for invoker.war
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.
>
> --
>
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
>
>
> 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 Dr
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.
--
Scott Stark
Chief Technology Officer
JBoss Group, LLC
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/psa0016ave/direct;at.asp_061203_01/01
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] multiple deployment info entries for invoker.war
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/psa0016ave/direct;at.asp_061203_01/01
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
