[JBoss-dev] Mbean package deployment and undeployment
I thought I'd write a note explaining what my recent changes to the mbean deployment in rh do. 1. Recursive deployment. The classpath elements in a *service.xml file may be used to specify dependencies on jar and zip archives, sar archives (containing a jboss-service.xml file), or *-service.xml files. Each listed dependency is loaded before the mbeans in the current *service.xml file are created and started. There's a test case for this in jmx. This functionality is actually used in the current jboss: jbossmq-service.xml is in the deploy/lib directory, and is autodeployed after the core jboss-service.xml. jbossmq-service.xml depends on jbosscx.sar (due to the jmsra resource adapter), so jbosscx.sar is recursively deployed. 2. Recursive undeployment based on package dependencies. If C depends on B which in turn depends on A, as just noted deploying C will deploy A, then B, then C. Recursive undeployment means undeploying A will undeploy B and C. Redeploying A will redeploy B and C automatically. 3. Undeploying a package actually works. Mbeans specified in the package are removed, and the classes from the codebase are removed from the classloader system (if they are not also deployed by another package not dependent on the one you are undeploying). There are test for this in jmx. (As part of the jbosscx reorganization, all jca related classes are in the jbosscx.sar, which contains the mbean configuration for the ConnectionManagerFactoryLoaders and the RARDeployer. The jbossmq configuration is now in a jbossmq-service.xml file, which depends on the jbosscx.sar ( and causes it to be recursively deployed). The configuration for the Hypersonic-based DefaultDS is in hsql-default-service.xml, which is also autodeployed.) The classpath element in a *service.xml file works like this: attribute codebase -- if missing, specifies the jboss.system.libraryDirectory set on startup -- if . specifies the same directory as the current file is in (not tested with http) -- if a url, specifies the url. attribute archives is a comma delimited list of jar, zip, sar, and *service.xml packages the current package depends on. If the archives attribute is missing and the codebase is a file url, all jar and zip files in the directory are added. There can now be multiple classpath elements. Known problems: Currently, deploying an already deployed package undeploys and (re) deploys it. This can cause churn if you are autodeploying a set of interdependent packages. Say C depends on B which depends on A. If the autodeployed picks C to deploy first, when it deploys B C will be undeployed and redeployed, and when it deploys A B and C will be undeployed and redeployed. I can think of 2 solutions: a. deploying an already deployed packaged does nothing. To refresh, undeploy and redeploy. I like this one, but it changes current behavior. b. The autodeployer keeps track of a autodeployment session and recieves notifications of deployed packages. It doesn't try to deploy anything it received a deploy notification for in the current session. All comments appreciated. thanks david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Mbean package deployment and undeployment
For the jbossmq-service.xml example, does reploying jbossmq-service.xml cause jboss-service.xml to be undeployed and redeployed? Likewise, would just undeploying jbossmq-service.xml undeploy jboss-service.xml? - Original Message - From: David Jencks [EMAIL PROTECTED] To: jboss-dev [EMAIL PROTECTED] Sent: Monday, September 10, 2001 11:16 AM Subject: [JBoss-dev] Mbean package deployment and undeployment I thought I'd write a note explaining what my recent changes to the mbean deployment in rh do. 1. Recursive deployment. The classpath elements in a *service.xml file may be used to specify dependencies on jar and zip archives, sar archives (containing a jboss-service.xml file), or *-service.xml files. Each listed dependency is loaded before the mbeans in the current *service.xml file are created and started. There's a test case for this in jmx. This functionality is actually used in the current jboss: jbossmq-service.xml is in the deploy/lib directory, and is autodeployed after the core jboss-service.xml. jbossmq-service.xml depends on jbosscx.sar (due to the jmsra resource adapter), so jbosscx.sar is recursively deployed. 2. Recursive undeployment based on package dependencies. If C depends on B which in turn depends on A, as just noted deploying C will deploy A, then B, then C. Recursive undeployment means undeploying A will undeploy B and C. Redeploying A will redeploy B and C automatically. 3. Undeploying a package actually works. Mbeans specified in the package are removed, and the classes from the codebase are removed from the classloader system (if they are not also deployed by another package not dependent on the one you are undeploying). There are test for this in jmx. (As part of the jbosscx reorganization, all jca related classes are in the jbosscx.sar, which contains the mbean configuration for the ConnectionManagerFactoryLoaders and the RARDeployer. The jbossmq configuration is now in a jbossmq-service.xml file, which depends on the jbosscx.sar ( and causes it to be recursively deployed). The configuration for the Hypersonic-based DefaultDS is in hsql-default-service.xml, which is also autodeployed.) The classpath element in a *service.xml file works like this: attribute codebase -- if missing, specifies the jboss.system.libraryDirectory set on startup -- if . specifies the same directory as the current file is in (not tested with http) -- if a url, specifies the url. attribute archives is a comma delimited list of jar, zip, sar, and *service.xml packages the current package depends on. If the archives attribute is missing and the codebase is a file url, all jar and zip files in the directory are added. There can now be multiple classpath elements. Known problems: Currently, deploying an already deployed package undeploys and (re) deploys it. This can cause churn if you are autodeploying a set of interdependent packages. Say C depends on B which depends on A. If the autodeployed picks C to deploy first, when it deploys B C will be undeployed and redeployed, and when it deploys A B and C will be undeployed and redeployed. I can think of 2 solutions: a. deploying an already deployed packaged does nothing. To refresh, undeploy and redeploy. I like this one, but it changes current behavior. b. The autodeployer keeps track of a autodeployment session and recieves notifications of deployed packages. It doesn't try to deploy anything it received a deploy notification for in the current session. All comments appreciated. thanks david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Mbean package deployment and undeployment
On 2001.09.10 15:39:58 -0400 Scott M Stark wrote: For the jbossmq-service.xml example, does reploying jbossmq-service.xml cause jboss-service.xml to be undeployed and redeployed? No, jboss-service.xml is not listed as a dependency of jbossmq-service.xml. Likewise, would just undeploying jbossmq-service.xml undeploy jboss-service.xml? In the current situation, as just noted, no. Hmmm. If it was listed, I think it would undeploy, which seems like a bad idea. What would be the desirable behavior in these scenarios? 1. B and C both depend on A. B and C are explicitly deployed, causing A to be recursively deployed. B is undeployed. What happens? - A remains deployed, since C is still depending on it. (good, I think) - A is undeployed, causing C to be undeployed. (bad, I think) assuming A remains deployed, then undeploy C - A is now undeployed, since nothing depends on it and it was not explicitly deployed. (good, I think) - A remains deployed. (bad, I think) 2. B depends on A. A and B are explicitly deployed. B is undeployed. No other packages depend on A. - A remaings deployed, since it was explicitly deployed (good, I think) - A is undeployed since nothing depends on it.(bad, I think) any opinions or other scenarios? david jencks - Original Message - From: David Jencks [EMAIL PROTECTED] To: jboss-dev [EMAIL PROTECTED] Sent: Monday, September 10, 2001 11:16 AM Subject: [JBoss-dev] Mbean package deployment and undeployment I thought I'd write a note explaining what my recent changes to the mbean deployment in rh do. 1. Recursive deployment. The classpath elements in a *service.xml file may be used to specify dependencies on jar and zip archives, sar archives (containing a jboss-service.xml file), or *-service.xml files. Each listed dependency is loaded before the mbeans in the current *service.xml file are created and started. There's a test case for this in jmx. This functionality is actually used in the current jboss: jbossmq-service.xml is in the deploy/lib directory, and is autodeployed after the core jboss-service.xml. jbossmq-service.xml depends on jbosscx.sar (due to the jmsra resource adapter), so jbosscx.sar is recursively deployed. 2. Recursive undeployment based on package dependencies. If C depends on B which in turn depends on A, as just noted deploying C will deploy A, then B, then C. Recursive undeployment means undeploying A will undeploy B and C. Redeploying A will redeploy B and C automatically. 3. Undeploying a package actually works. Mbeans specified in the package are removed, and the classes from the codebase are removed from the classloader system (if they are not also deployed by another package not dependent on the one you are undeploying). There are test for this in jmx. (As part of the jbosscx reorganization, all jca related classes are in the jbosscx.sar, which contains the mbean configuration for the ConnectionManagerFactoryLoaders and the RARDeployer. The jbossmq configuration is now in a jbossmq-service.xml file, which depends on the jbosscx.sar ( and causes it to be recursively deployed). The configuration for the Hypersonic-based DefaultDS is in hsql-default-service.xml, which is also autodeployed.) The classpath element in a *service.xml file works like this: attribute codebase -- if missing, specifies the jboss.system.libraryDirectory set on startup -- if . specifies the same directory as the current file is in (not tested with http) -- if a url, specifies the url. attribute archives is a comma delimited list of jar, zip, sar, and *service.xml packages the current package depends on. If the archives attribute is missing and the codebase is a file url, all jar and zip files in the directory are added. There can now be multiple classpath elements. Known problems: Currently, deploying an already deployed package undeploys and (re) deploys it. This can cause churn if you are autodeploying a set of interdependent packages. Say C depends on B which depends on A. If the autodeployed picks C to deploy first, when it deploys B C will be undeployed and redeployed, and when it deploys A B and C will be undeployed and redeployed. I can think of 2 solutions: a. deploying an already deployed packaged does nothing. To refresh, undeploy and redeploy. I like this one, but it changes current behavior. b. The autodeployer keeps track of a autodeployment session and recieves notifications of deployed packages. It doesn't try to deploy anything it received a deploy notification for in the current session. All comments appreciated. thanks david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Mbean package deployment and undeployment
From: David Jencks [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: jboss-dev [EMAIL PROTECTED] Subject: [JBoss-dev] Mbean package deployment and undeployment Date: Mon, 10 Sep 2001 14:16:17 -0400 (As part of the jbosscx reorganization, all jca related classes are in the jbosscx.sar, which contains the mbean configuration for the ConnectionManagerFactoryLoaders and the RARDeployer. The jbossmq configuration is now in a jbossmq-service.xml file, which depends on the jbosscx.sar ( and causes it to be recursively deployed). The configuration for the Hypersonic-based DefaultDS is in hsql-default-service.xml, which is also autodeployed.) JBossMQ does not depend on jbosscx.sar... The MDB and JMS RA stuff is what depends on jbosscx.sar. the jbossmq-service.xml file needs to get split into two files to show this. Regards, Hiram _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Mbean package deployment and undeployment
On 2001.09.10 15:39:58 -0400 Scott M Stark wrote: For the jbossmq-service.xml example, does reploying jbossmq-service.xml cause jboss-service.xml to be undeployed and redeployed? No, jboss-service.xml is not listed as a dependency of jbossmq-service.xml. But JBossMQ requires that a JNDI naming service be present, so how is that dependency specified? Also in the future I want to make better use of the JBossSX framework for authentication and authorization in other JBoss services to avoid the passwords spread all over the place configuration issue we now have so this is another future core service dependency. Likewise, would just undeploying jbossmq-service.xml undeploy jboss-service.xml? In the current situation, as just noted, no. Hmmm. If it was listed, I think it would undeploy, which seems like a bad idea. What would be the desirable behavior in these scenarios? 1. B and C both depend on A. B and C are explicitly deployed, causing A to be recursively deployed. B is undeployed. What happens? - A remains deployed, since C is still depending on it. (good, I think) - A is undeployed, causing C to be undeployed. (bad, I think) A should remain deployed. assuming A remains deployed, then undeploy C - A is now undeployed, since nothing depends on it and it was not explicitly deployed. (good, I think) - A remains deployed. (bad, I think) Things are not this black and white. Just because I don't have any services deployed that depend on A does not mean that it should be undeployed. The naming service is a perfect example. Just because I don't have any services deployed that depend on the naming service does not mean that I don't have external clients using the naming service. 2. B depends on A. A and B are explicitly deployed. B is undeployed. No other packages depend on A. - A remaings deployed, since it was explicitly deployed (good, I think) - A is undeployed since nothing depends on it.(bad, I think) A remains deployed, since it was explicitly deployed. This is the naming service example as it will be explictly deployed and many other services will depend on it. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Mbean package deployment and undeployment
Thanks, Hiram Are the attached files what you mean? (I haven't tested to make sure they work). Is some part of the jbossmq-service.jar required for jbossmq to work, whereas the rest is an example of how to set up usage of it? If so, can we package the required part into a jboss-service.xml in a sar? If you let me know which parts are required/optional I will try out the packaging. Thanks david jencks On 2001.09.10 16:18:57 -0400 Hiram Chirino wrote: From: David Jencks [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: jboss-dev [EMAIL PROTECTED] Subject: [JBoss-dev] Mbean package deployment and undeployment Date: Mon, 10 Sep 2001 14:16:17 -0400 (As part of the jbosscx reorganization, all jca related classes are in the jbosscx.sar, which contains the mbean configuration for the ConnectionManagerFactoryLoaders and the RARDeployer. The jbossmq configuration is now in a jbossmq-service.xml file, which depends on the jbosscx.sar ( and causes it to be recursively deployed). The configuration for the Hypersonic-based DefaultDS is in hsql-default-service.xml, which is also autodeployed.) JBossMQ does not depend on jbosscx.sar... The MDB and JMS RA stuff is what depends on jbosscx.sar. the jbossmq-service.xml file needs to get split into two files to show this. Regards, Hiram _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ?xml version=1.0 encoding=UTF-8? !-- = -- !-- -- !-- JBoss Server Configuration -- !-- -- !-- = -- !-- $Id: jbossmq-service.xml,v 1.2 2001/09/09 05:40:47 d_jencks Exp $ -- !-- | This is where you can add and configure your MBeans. | | *ATTENTION* | | The order of the listing here is the same order as | the MBeans are loaded. Therefore if a MBean depends on another | MBean to be loaded and started it has to be listed after all | the MBeans it depends on. -- server classpath archives= jbossmq.jar/ !-- -- !-- JBossMQ -- !-- -- mbean code=org.jboss.mq.server.JBossMQService name=JBossMQ:service=Server/ !-- | The StateManager is used to keep JMS perisitent state data. | For example: what durable subscriptions are active. -- mbean code=org.jboss.mq.server.StateManager name=JBossMQ:service=StateManager attribute name=StateFileconf/default/jbossmq-state.xml/attribute /mbean !-- The PersistenceManager is used to store messages to disk. -- mbean code=org.jboss.mq.pm.file.PersistenceManager name=JBossMQ:service=PersistenceManager attribute name=DataDirectorydb/jbossmq//attribute /mbean !-- | InvocationLayers are the different transport methods that can | be used to access the server. -- mbean code=org.jboss.mq.il.jvm.JVMServerILService name=JBossMQ:service=InvocationLayer,type=JVM attribute name=ConnectionFactoryJNDIRefjava:/ConnectionFactory/attribute attribute name=XAConnectionFactoryJNDIRefjava:/XAConnectionFactory/attribute /mbean mbean code=org.jboss.mq.il.rmi.RMIServerILService name=JBossMQ:service=InvocationLayer,type=RMI attribute name=ConnectionFactoryJNDIRefRMIConnectionFactory/attribute attribute name=XAConnectionFactoryJNDIRefRMIXAConnectionFactory/attribute /mbean mbean code=org.jboss.mq.il.oil.OILServerILService name=JBossMQ:service=InvocationLayer,type=OIL attribute name=ConnectionFactoryJNDIRefConnectionFactory/attribute attribute name=XAConnectionFactoryJNDIRefXAConnectionFactory/attribute /mbean mbean code=org.jboss.mq.il.uil.UILServerILService name=JBossMQ:service=InvocationLayer,type=UIL attribute name=ConnectionFactoryJNDIRefUILConnectionFactory/attribute attribute name=XAConnectionFactoryJNDIRefUILXAConnectionFactory/attribute /mbean !-- | The following three line create 3 topics named: | | testTopic, example, bob -- mbean code=org.jboss.mq.server.TopicManager name=JBossMQ:service=Topic,name=testTopic/ mbean code=org.jboss.mq.server.TopicManager name=JBossMQ:service=Topic,name=example/ mbean code=org.jboss.mq.server.TopicManager name=JBossMQ:service=Topic,name=bob/ !-- | The following 9 line create 9 topics named
RE: [JBoss-dev] Mbean package deployment and undeployment
Time for my two cents... I have just finished incorporating my scheme (the use of the depends elements) with David J's and it seems to work for the simple examples I have tested it on. I am a bit unsure whether or not to commit the changes (after more testing) though because the two schemes don't mesh particularly well in the source. Some odd behaviour would be possible if deployments attempt to use both mechanisms at the same time. In my opinion some of the problems or discussion points that are coming up in this thread are because the recursive deployment model is not always suitable, when all you want to do is specify a simple dependency. The naming service (JNDI) is a classic example, where many of the other services need this service to be started before they will successfully start but it is easy to deploy on its own. The recursive deployment mechanism I feel is excellent for deploying and undeploying applications that are spread across multiple sar's and comprise multiple mbean services. I don't think it is so effective at specifying simple dependencies between services, especially the core ones that exist during the startup process. David -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 11, 2001 8:42 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Mbean package deployment and undeployment On 2001.09.10 15:39:58 -0400 Scott M Stark wrote: For the jbossmq-service.xml example, does reploying jbossmq-service.xml cause jboss-service.xml to be undeployed and redeployed? No, jboss-service.xml is not listed as a dependency of jbossmq-service.xml. But JBossMQ requires that a JNDI naming service be present, so how is that dependency specified? Also in the future I want to make better use of the JBossSX framework for authentication and authorization in other JBoss services to avoid the passwords spread all over the place configuration issue we now have so this is another future core service dependency. Likewise, would just undeploying jbossmq-service.xml undeploy jboss-service.xml? In the current situation, as just noted, no. Hmmm. If it was listed, I think it would undeploy, which seems like a bad idea. What would be the desirable behavior in these scenarios? 1. B and C both depend on A. B and C are explicitly deployed, causing A to be recursively deployed. B is undeployed. What happens? - A remains deployed, since C is still depending on it. (good, I think) - A is undeployed, causing C to be undeployed. (bad, I think) A should remain deployed. assuming A remains deployed, then undeploy C - A is now undeployed, since nothing depends on it and it was not explicitly deployed. (good, I think) - A remains deployed. (bad, I think) Things are not this black and white. Just because I don't have any services deployed that depend on A does not mean that it should be undeployed. The naming service is a perfect example. Just because I don't have any services deployed that depend on the naming service does not mean that I don't have external clients using the naming service. 2. B depends on A. A and B are explicitly deployed. B is undeployed. No other packages depend on A. - A remaings deployed, since it was explicitly deployed (good, I think) - A is undeployed since nothing depends on it.(bad, I think) A remains deployed, since it was explicitly deployed. This is the naming service example as it will be explictly deployed and many other services will depend on it. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Mbean package deployment and undeployment
Yes.. almost perfect. Just move the - !-- The JMS provider loader -- - mbean code=org.jboss.jms.jndi.JMSProviderLoader name=:service=JMSProviderLoader,name=JBossMQProvider attribute name=ProviderNameDefaultJMSProvider/attribute attribute name=ProviderAdapterClassorg.jboss.jms.jndi.JBossMQProvider/attribute attribute name=QueueFactoryRefjava:/XAConnectionFactory/attribute attribute name=TopicFactoryRefjava:/XAConnectionFactory/attribute /mbean section into the ra xml file. Regards, Hiram From: David Jencks [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Mbean package deployment and undeployment Date: Mon, 10 Sep 2001 16:55:02 -0400 Thanks, Hiram Are the attached files what you mean? (I haven't tested to make sure they work). Is some part of the jbossmq-service.jar required for jbossmq to work, whereas the rest is an example of how to set up usage of it? If so, can we package the required part into a jboss-service.xml in a sar? If you let me know which parts are required/optional I will try out the packaging. Thanks david jencks On 2001.09.10 16:18:57 -0400 Hiram Chirino wrote: From: David Jencks [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: jboss-dev [EMAIL PROTECTED] Subject: [JBoss-dev] Mbean package deployment and undeployment Date: Mon, 10 Sep 2001 14:16:17 -0400 (As part of the jbosscx reorganization, all jca related classes are in the jbosscx.sar, which contains the mbean configuration for the ConnectionManagerFactoryLoaders and the RARDeployer. The jbossmq configuration is now in a jbossmq-service.xml file, which depends on the jbosscx.sar ( and causes it to be recursively deployed). The configuration for the Hypersonic-based DefaultDS is in hsql-default-service.xml, which is also autodeployed.) JBossMQ does not depend on jbosscx.sar... The MDB and JMS RA stuff is what depends on jbosscx.sar. the jbossmq-service.xml file needs to get split into two files to show this. Regards, Hiram _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development jbossmq-service.xml jbossmq-ra-service.xml _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Mbean package deployment and undeployment
Whatever happened to Simple is the word... ;-) David -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 11, 2001 9:24 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Mbean package deployment and undeployment Ok, my thinking is coming into focus. Here's what I'd like to implement: We distinguish between explicitly and implicitly (ie due to recursive deployment) deployed packages. deploying a package will recursively (implicitly) deploy all packages it depends on (as determined by looking at the classpath elements) that aren't already deployed. (this happens now) undeploying a package will undeploy (suspend) all packages that depend on it (works now) and will undeploy all implicitly deployed packages it depends on that aren't used by other deployed packages. Undeploying a package A will never undeploy a package B it depends on if B has been explicitly deployed. undeploying and redeploying a package will undeploy and redeploy all packages that depend on it. (works now) If B depends on A, both are deployed, then A is undeployed (undeploying and suspending B), trying to undeploy B will remove the suspension dependency, so that when A is redeployed, B will not be redeployed. To redeploy a package, you must explicitly undeploy it and redeploy it. This changes current behavior where updating a package redeploys it. Any more rules I need? Thanks david jencks On 2001.09.10 16:41:54 -0400 Scott M Stark wrote: On 2001.09.10 15:39:58 -0400 Scott M Stark wrote: For the jbossmq-service.xml example, does reploying jbossmq-service.xml cause jboss-service.xml to be undeployed and redeployed? No, jboss-service.xml is not listed as a dependency of jbossmq-service.xml. But JBossMQ requires that a JNDI naming service be present, so how is that dependency specified? right now, not at all: this is a problem. Also in the future I want to make better use of the JBossSX framework for authentication and authorization in other JBoss services to avoid the passwords spread all over the place configuration issue we now have so this is another future core service dependency. Likewise, would just undeploying jbossmq-service.xml undeploy jboss-service.xml? In the current situation, as just noted, no. Hmmm. If it was listed, I think it would undeploy, which seems like a bad idea. What would be the desirable behavior in these scenarios? 1. B and C both depend on A. B and C are explicitly deployed, causing A to be recursively deployed. B is undeployed. What happens? - A remains deployed, since C is still depending on it. (good, I think) - A is undeployed, causing C to be undeployed. (bad, I think) A should remain deployed. assuming A remains deployed, then undeploy C - A is now undeployed, since nothing depends on it and it was not explicitly deployed. (good, I think) - A remains deployed. (bad, I think) Things are not this black and white. Just because I don't have any services deployed that depend on A does not mean that it should be undeployed. The naming service is a perfect example. Just because I don't have any services deployed that depend on the naming service does not mean that I don't have external clients using the naming service. 2. B depends on A. A and B are explicitly deployed. B is undeployed. No other packages depend on A. - A remaings deployed, since it was explicitly deployed (good, I think) - A is undeployed since nothing depends on it.(bad, I think) A remains deployed, since it was explicitly deployed. This is the naming service example as it will be explictly deployed and many other services will depend on it. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Mbean package deployment and undeployment
Well, after struggling to get a working jboss startup using only the recursive dependencies, I am inclined to agree with you that relying solely on them is not necessarily appropriate. I don't know a good final answer: --recursive deployment is nice because it lets you aggregate chunks of deployment at many levels, and only explicitly deploy the top level. --mbean dependencies are nice because often you don't care where the code /configuration for the service is, you just need to make sure it's there. I'd say, if your stuff doesn't break the current startup, or you have a modified startup that works, and you have (or plan to have) at least some minimal tests, commit it. I'd like to see it and make the explicit/implicit deployment/undeployment on top of it. We can work out the best balance between the actual use of the two schemes by experiment and discussion. Thanks Cant wait! david jencks On 2001.09.10 16:47:32 -0400 David Maplesden wrote: Time for my two cents... I have just finished incorporating my scheme (the use of the depends elements) with David J's and it seems to work for the simple examples I have tested it on. I am a bit unsure whether or not to commit the changes (after more testing) though because the two schemes don't mesh particularly well in the source. Some odd behaviour would be possible if deployments attempt to use both mechanisms at the same time. In my opinion some of the problems or discussion points that are coming up in this thread are because the recursive deployment model is not always suitable, when all you want to do is specify a simple dependency. The naming service (JNDI) is a classic example, where many of the other services need this service to be started before they will successfully start but it is easy to deploy on its own. The recursive deployment mechanism I feel is excellent for deploying and undeploying applications that are spread across multiple sar's and comprise multiple mbean services. I don't think it is so effective at specifying simple dependencies between services, especially the core ones that exist during the startup process. David -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 11, 2001 8:42 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Mbean package deployment and undeployment On 2001.09.10 15:39:58 -0400 Scott M Stark wrote: For the jbossmq-service.xml example, does reploying jbossmq-service.xml cause jboss-service.xml to be undeployed and redeployed? No, jboss-service.xml is not listed as a dependency of jbossmq-service.xml. But JBossMQ requires that a JNDI naming service be present, so how is that dependency specified? Also in the future I want to make better use of the JBossSX framework for authentication and authorization in other JBoss services to avoid the passwords spread all over the place configuration issue we now have so this is another future core service dependency. Likewise, would just undeploying jbossmq-service.xml undeploy jboss-service.xml? In the current situation, as just noted, no. Hmmm. If it was listed, I think it would undeploy, which seems like a bad idea. What would be the desirable behavior in these scenarios? 1. B and C both depend on A. B and C are explicitly deployed, causing A to be recursively deployed. B is undeployed. What happens? - A remains deployed, since C is still depending on it. (good, I think) - A is undeployed, causing C to be undeployed. (bad, I think) A should remain deployed. assuming A remains deployed, then undeploy C - A is now undeployed, since nothing depends on it and it was not explicitly deployed. (good, I think) - A remains deployed. (bad, I think) Things are not this black and white. Just because I don't have any services deployed that depend on A does not mean that it should be undeployed. The naming service is a perfect example. Just because I don't have any services deployed that depend on the naming service does not mean that I don't have external clients using the naming service. 2. B depends on A. A and B are explicitly deployed. B is undeployed. No other packages depend on A. - A remaings deployed, since it was explicitly deployed (good, I think) - A is undeployed since nothing depends on it.(bad, I think) A remains deployed, since it was explicitly deployed. This is the naming service example as it will be explictly deployed and many other services will depend on it. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net
RE: [JBoss-dev] Mbean package deployment and undeployment
OK, thats good, I wanted your nod before committing, which I will do some time today. My stuff doesn't break the current startup and I have made a few changes to the startup configuration so that it all works nicely. However I will need you to look over the changes and check I haven't stuffed up any of your nice recursive deploy/undeployment things. -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 11, 2001 9:35 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Mbean package deployment and undeployment Well, after struggling to get a working jboss startup using only the recursive dependencies, I am inclined to agree with you that relying solely on them is not necessarily appropriate. I don't know a good final answer: --recursive deployment is nice because it lets you aggregate chunks of deployment at many levels, and only explicitly deploy the top level. --mbean dependencies are nice because often you don't care where the code /configuration for the service is, you just need to make sure it's there. I'd say, if your stuff doesn't break the current startup, or you have a modified startup that works, and you have (or plan to have) at least some minimal tests, commit it. I'd like to see it and make the explicit/implicit deployment/undeployment on top of it. We can work out the best balance between the actual use of the two schemes by experiment and discussion. Thanks Cant wait! david jencks On 2001.09.10 16:47:32 -0400 David Maplesden wrote: Time for my two cents... I have just finished incorporating my scheme (the use of the depends elements) with David J's and it seems to work for the simple examples I have tested it on. I am a bit unsure whether or not to commit the changes (after more testing) though because the two schemes don't mesh particularly well in the source. Some odd behaviour would be possible if deployments attempt to use both mechanisms at the same time. In my opinion some of the problems or discussion points that are coming up in this thread are because the recursive deployment model is not always suitable, when all you want to do is specify a simple dependency. The naming service (JNDI) is a classic example, where many of the other services need this service to be started before they will successfully start but it is easy to deploy on its own. The recursive deployment mechanism I feel is excellent for deploying and undeploying applications that are spread across multiple sar's and comprise multiple mbean services. I don't think it is so effective at specifying simple dependencies between services, especially the core ones that exist during the startup process. David -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 11, 2001 8:42 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Mbean package deployment and undeployment On 2001.09.10 15:39:58 -0400 Scott M Stark wrote: For the jbossmq-service.xml example, does reploying jbossmq-service.xml cause jboss-service.xml to be undeployed and redeployed? No, jboss-service.xml is not listed as a dependency of jbossmq-service.xml. But JBossMQ requires that a JNDI naming service be present, so how is that dependency specified? Also in the future I want to make better use of the JBossSX framework for authentication and authorization in other JBoss services to avoid the passwords spread all over the place configuration issue we now have so this is another future core service dependency. Likewise, would just undeploying jbossmq-service.xml undeploy jboss-service.xml? In the current situation, as just noted, no. Hmmm. If it was listed, I think it would undeploy, which seems like a bad idea. What would be the desirable behavior in these scenarios? 1. B and C both depend on A. B and C are explicitly deployed, causing A to be recursively deployed. B is undeployed. What happens? - A remains deployed, since C is still depending on it. (good, I think) - A is undeployed, causing C to be undeployed. (bad, I think) A should remain deployed. assuming A remains deployed, then undeploy C - A is now undeployed, since nothing depends on it and it was not explicitly deployed. (good, I think) - A remains deployed. (bad, I think) Things are not this black and white. Just because I don't have any services deployed that depend on A does not mean that it should be undeployed. The naming service is a perfect example. Just because I don't have any services deployed that depend on the naming service does not mean that I don't have external clients using the naming service. 2. B depends
Re: [JBoss-dev] Mbean package deployment and undeployment
Let's get both approaches working as it remains to be seen if the complexity of the recursive/implicit stuff is worth the trouble. - Original Message - From: David Maplesden [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 10, 2001 2:31 PM Subject: RE: [JBoss-dev] Mbean package deployment and undeployment OK, thats good, I wanted your nod before committing, which I will do some time today. My stuff doesn't break the current startup and I have made a few changes to the startup configuration so that it all works nicely. However I will need you to look over the changes and check I haven't stuffed up any of your nice recursive deploy/undeployment things. -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 11, 2001 9:35 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Mbean package deployment and undeployment Well, after struggling to get a working jboss startup using only the recursive dependencies, I am inclined to agree with you that relying solely on them is not necessarily appropriate. I don't know a good final answer: --recursive deployment is nice because it lets you aggregate chunks of deployment at many levels, and only explicitly deploy the top level. --mbean dependencies are nice because often you don't care where the code /configuration for the service is, you just need to make sure it's there. I'd say, if your stuff doesn't break the current startup, or you have a modified startup that works, and you have (or plan to have) at least some minimal tests, commit it. I'd like to see it and make the explicit/implicit deployment/undeployment on top of it. We can work out the best balance between the actual use of the two schemes by experiment and discussion. Thanks Cant wait! david jencks On 2001.09.10 16:47:32 -0400 David Maplesden wrote: Time for my two cents... I have just finished incorporating my scheme (the use of the depends elements) with David J's and it seems to work for the simple examples I have tested it on. I am a bit unsure whether or not to commit the changes (after more testing) though because the two schemes don't mesh particularly well in the source. Some odd behaviour would be possible if deployments attempt to use both mechanisms at the same time. In my opinion some of the problems or discussion points that are coming up in this thread are because the recursive deployment model is not always suitable, when all you want to do is specify a simple dependency. The naming service (JNDI) is a classic example, where many of the other services need this service to be started before they will successfully start but it is easy to deploy on its own. The recursive deployment mechanism I feel is excellent for deploying and undeploying applications that are spread across multiple sar's and comprise multiple mbean services. I don't think it is so effective at specifying simple dependencies between services, especially the core ones that exist during the startup process. David -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 11, 2001 8:42 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Mbean package deployment and undeployment On 2001.09.10 15:39:58 -0400 Scott M Stark wrote: For the jbossmq-service.xml example, does reploying jbossmq-service.xml cause jboss-service.xml to be undeployed and redeployed? No, jboss-service.xml is not listed as a dependency of jbossmq-service.xml. But JBossMQ requires that a JNDI naming service be present, so how is that dependency specified? Also in the future I want to make better use of the JBossSX framework for authentication and authorization in other JBoss services to avoid the passwords spread all over the place configuration issue we now have so this is another future core service dependency. Likewise, would just undeploying jbossmq-service.xml undeploy jboss-service.xml? In the current situation, as just noted, no. Hmmm. If it was listed, I think it would undeploy, which seems like a bad idea. What would be the desirable behavior in these scenarios? 1. B and C both depend on A. B and C are explicitly deployed, causing A to be recursively deployed. B is undeployed. What happens? - A remains deployed, since C is still depending on it. (good, I think) - A is undeployed, causing C to be undeployed. (bad, I think) A should remain deployed. assuming A remains deployed, then undeploy C - A is now undeployed, since nothing depends on it and it was not explicitly deployed. (good, I think) - A remains
