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.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.
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.
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.
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.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?
You cannot redeploy an ejb jar that a war depends on because of class loading issues. Touching a deployment descriptor correlates to a change of deployment metadata. I think this needs to trigger a redeploy event that goes through the entire deployment chain with the deployers looking for changes. If the redeploy is seen as an event across the deployment context there is a better chance to deal correctly with it.
- 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.
-- xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx
------------------------------------------------------- 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/bulletproofapps1 _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
