RE: [JBoss-dev] Expansion of service dependencies to redeployment
classpath and manifest refs only affect the classpath associated with a deployment though, and generally this is incomplete because users rely on the flat type model to not have to explicitly reference every source of class they use. If the class loader associated with a deployed tracked what other deployments it used for classes(I don't see a need to track down to the class level as the deployment has to be redeployed in order for classes to be redeployed), this would form a dynamic usage dependency graph that could be used to pickup type based redeployments. I agree there should be a dependency on a given deployment to is deployer so that we can remove the current logic where by the MainDeployer tries to stop all the deployments of a deployer when the deployer stops. This would be an automatic feature of the deployer/deployee dependency. Likewise I agree that the deployment process needs better definition such as having a complete deployment graph before we start deploying components. I do think dependency should delay component creation in addition to dispatch of lifecycle ops. Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Brock Sent: Monday, February 02, 2004 5:19 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Expansion of service dependencies to redeployment Hi Scott, Our deployments generally boil down to a classpath and a set of mbeans. There is also a contract to define a directed graph across deployments which orders the mbean lifecycle invocations using There are also implicit rules like: 1) deployments wait for their deployer 2) russian doll 3) deployment sorter It appears to me, that what is missing is the ability to define the directed graph for classloading. Changing a parent deployment in this graph would require a redeployment of children because the classloaders need to reconstructed. To make it work, there needs to be enough information available to define the graph. The simplest approach would be to change the meaning of to define the graph/dependencies. The use of manifest.mf would also be included. i.e. each deployment explicity states which jars it uses. More implicit rules could be defined: 1) A deployer could define its implementation jars which all its deployments inherit in case a deployer is restarted. 2) There was an attempt early in 3.0 to define an MBeanClassLoader that recorded which classes were actually used by a deployment. A redeployment of those classes would force a redeployment of the mbean. 3) The MBeanClassLoader misses classes passed by reference across the MBus where the signature is an interface, but this could be added. 4) There are other mechanisms where classes get passed by reference, e.g. jndi. Mechanisms involving serialization would be caught by the MBeanClassLoader. Regards, Adrian --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Expansion of service dependencies to redeployment
Hi Scott, Our deployments generally boil down to a classpath and a set of mbeans. There is also a contract to define a directed graph across deployments which orders the mbean lifecycle invocations using There are also implicit rules like: 1) deployments wait for their deployer 2) russian doll 3) deployment sorter It appears to me, that what is missing is the ability to define the directed graph for classloading. Changing a parent deployment in this graph would require a redeployment of children because the classloaders need to reconstructed. To make it work, there needs to be enough information available to define the graph. The simplest approach would be to change the meaning of to define the graph/dependencies. The use of manifest.mf would also be included. i.e. each deployment explicity states which jars it uses. More implicit rules could be defined: 1) A deployer could define its implementation jars which all its deployments inherit in case a deployer is restarted. 2) There was an attempt early in 3.0 to define an MBeanClassLoader that recorded which classes were actually used by a deployment. A redeployment of those classes would force a redeployment of the mbean. 3) The MBeanClassLoader misses classes passed by reference across the MBus where the signature is an interface, but this could be added. 4) There are other mechanisms where classes get passed by reference, e.g. jndi. Mechanisms involving serialization would be caught by the MBeanClassLoader. Regards, Adrian On Sat, 2004-01-31 at 17:31, Scott M Stark wrote: > So a user has a scenario that could > > M1 <-Pa-> M4 <-Pd-> | > * > M2 <-Pc-> M5 <-Pd-> M7 > * > M3 <-Pb-> M6 <-Pe-> | > > Px = protocol x with seperate contract_x.jar for interfaces > Mn = mbean n that depends on one or more protocols > > whenever a protocol contract jar for which mbeans 1..m depend > on is deployed, mbeans 1..m need to be redeployed. This could > potentially be addressed by extending the current dependency > notion to optionally support redeployment, not just stopping > of the service. > > However, in general when contract_x.jar is redeployed, its > not sufficient to simply redeploy the mbeans using the contract, > since at least one of them also needs to be upgraded to use the > modified contract. It seems as though the behavior needed is > that if the contract_x.jar is redeployed, all mbeans depending > on the contract are undeployed, and are not redeployed until > their deployment jar is updated by actually being changed or > just touched. > > So the model seems to require an alternate hot deployment service > that has the notion of levels and compartments. At a given level > services are generally independent, but can be made dependent > by lifecycle contract as can be done now. The level below has > a deployment level dependency on the level above in that a redeployment > of a higher level compartment causes an undeploy of the services > depending on that compartment. > > New issues this raises: > - The directory structure will not correspond to the levels in general > because a service an mbean can be using multiple protocols, and thus > depend on multiple compartments in the level above. So there has to > be a new dependency description mechanism to say service S1 depends on > compartment level L1a in terms of redeployment. This is going to have > to be a representation of a directed graph describing the inter-level > and intra-level dependencies. > - Updating a contract_x.jar deploys the dependent services and these > remain updeployed until explicitly redeployed or touched. This can't > result in exceptions, but could result in services not being redeployed > if the admin forgets. > - What happens to the upstream services? So in the above diagram, > contract_Pd.jar > is redeployed which affects M4, M5, M7 by type, and M1, M2, and M6 due > to service > availability of M7. M4, M5, and M7 must be redeployed, M1, M2, and M6 > simply have > to wait for M4, M5, and M7 respectively. What support is jboss providing > vs > what do you have to code to make this work is the question. > > In general this issue raises an issue that has come up a few times due > to > the fact that dependency does not have anything to do with redeployment, > even > though dependency may require redeployment if type system involved in > the > dependency changes. Our service dependency needs to expand to support > the > possibility of dependency to the redeployment level. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > > > --- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > ___ > JBoss-Develop
[JBoss-dev] Expansion of service dependencies to redeployment
So a user has a scenario that could M1 <-Pa-> M4 <-Pd-> | * M2 <-Pc-> M5 <-Pd-> M7 * M3 <-Pb-> M6 <-Pe-> | Px = protocol x with seperate contract_x.jar for interfaces Mn = mbean n that depends on one or more protocols whenever a protocol contract jar for which mbeans 1..m depend on is deployed, mbeans 1..m need to be redeployed. This could potentially be addressed by extending the current dependency notion to optionally support redeployment, not just stopping of the service. However, in general when contract_x.jar is redeployed, its not sufficient to simply redeploy the mbeans using the contract, since at least one of them also needs to be upgraded to use the modified contract. It seems as though the behavior needed is that if the contract_x.jar is redeployed, all mbeans depending on the contract are undeployed, and are not redeployed until their deployment jar is updated by actually being changed or just touched. So the model seems to require an alternate hot deployment service that has the notion of levels and compartments. At a given level services are generally independent, but can be made dependent by lifecycle contract as can be done now. The level below has a deployment level dependency on the level above in that a redeployment of a higher level compartment causes an undeploy of the services depending on that compartment. New issues this raises: - The directory structure will not correspond to the levels in general because a service an mbean can be using multiple protocols, and thus depend on multiple compartments in the level above. So there has to be a new dependency description mechanism to say service S1 depends on compartment level L1a in terms of redeployment. This is going to have to be a representation of a directed graph describing the inter-level and intra-level dependencies. - Updating a contract_x.jar deploys the dependent services and these remain updeployed until explicitly redeployed or touched. This can't result in exceptions, but could result in services not being redeployed if the admin forgets. - What happens to the upstream services? So in the above diagram, contract_Pd.jar is redeployed which affects M4, M5, M7 by type, and M1, M2, and M6 due to service availability of M7. M4, M5, and M7 must be redeployed, M1, M2, and M6 simply have to wait for M4, M5, and M7 respectively. What support is jboss providing vs what do you have to code to make this work is the question. In general this issue raises an issue that has come up a few times due to the fact that dependency does not have anything to do with redeployment, even though dependency may require redeployment if type system involved in the dependency changes. Our service dependency needs to expand to support the possibility of dependency to the redeployment level. Scott Stark Chief Technology Officer JBoss Group, LLC --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
