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. xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx -----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 <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 ------------------------------------------------------- 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
