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 <depends> 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 <classpath> 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. > > xxxxxxxxxxxxxxxxxxxxxxxx > Scott Stark > Chief Technology Officer > JBoss Group, LLC > xxxxxxxxxxxxxxxxxxxxxxxx > > > > ------------------------------------------------------- > 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 -- xxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Director of Support Back Office JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ------------------------------------------------------- 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
