On Friday, July 11, 2003, at 01:29 PM, Scott M Stark wrote:
The whole service life-cycle, deployer, dependency management layer needs to
be rethought to come up with a more coherent behavior. Right now there are too
many ways a collection of components can be brought into the server and insufficient
knowledge of how this was done to allow startup/shutdown to be service based. There
is too much reliance on the deployment as a first class thing rather than just a packaging
of code and metadata.
I don't know what you mean. Can you give a specific example?
Some issues that need to be cleared up include:
- Removing the metadata from the deployers to allow them to be useful across
deployment versions as well as minimizing the importance of the deployment
package. A current issue related to this is that a given deployment package is
only assigned to a single deployer as dictated by the primary deployment descriptor.
This is too limiting and J2EE centric a view of a deployment package.
Again, I don't have any idea what you mean and an example would be very helpful.
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.
- Coming up with a well defined service life-cycle diagram that is honored under
all use cases. One simple problem that exists now is that the life-cycle operations
exposed by a service do not integrate with the dependency management service.
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?
- 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.
- Better automation of choosing the appropriate deployment class loading model taking
into account duplicate/conflicting classes, missing classes, etc. The issue is being able to
go from minimal canonical packages that need a flat shared class loading model to
heavy weight packages that include redundant and conflicting classes with respect to
the server and/or other deployments.
I agree this is still a problem. Do you think a good start would be to list a bunch of use cases?
So let's fix it.
Agreed.
Thanks
/********************************** * David Jencks * Partner * Core Developers Network * http://www.coredevelopers.net **********************************/
xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx
On Thursday, July 10, 2003, at 06:24 AM, Rod Burgett wrote:
I noticed that removeDeployer does a first-to-last traversal of deploymentList. I wondered if that was an oversight or part of some strategy that wasn't obvious to me.
But, it gets uglier. Commenting MainDeployer.shutdown() produces a batch of
warnings from ServiceController.shutdown(), it complains about ignoring a
request to stop/destroy/remove nonexistent services. Here's the scenario,
as I understand it.
startup: - xxx.jar is detected and deployed - service (EjbModule) is created to represent xxx.jar, - jboss.j2ee:service=EjbModule,url=...xxx.jar - xxx.jar contains ejb ABC - EjbModule.createService() creates a container for ABC - EjbModule.createService() creates a service to represent ABC bean container - jboss.j2ee:jndiName=ABC,service=EJB
shutdown:
- service controller shutdown finds ABC container service and
stops/destroys/removes it
- since containerServiceContext.dependsOnMe is empty, svc controller
removes this context from nameToServiceMap
- service controller shutdown finds xxx.jar service and tries to stop it
- EjbModule.stopService() tries to stop the ABC container service, again
- when svc controller.stop can't find the container context in
nameToServiceMap, it whines about a nonexistent service
- service controller shutdown tries to destroy xxx.jar service
- EjbModule.stopService() tries to destroy the ABC container service, again
- when svc controller.destroy still can't find the container context, it
whines, again
- service controller shutdown tries to remove xxx.jar service
- EjbModule.stopService() tries to remove the ABC container service, again
- when svc controller.remove still can't find the container context, it
whines, again
I'm guessing that this issue is masked by MainDeployer.shutdown's
undeployment of everything. Since the containers aren't deployed, they
aren't explicitly handled by MainDeployer.shutdown. Their jar file is
undeployed and takes them along. It will probably show up in a scenario
where a container is stopped, then it's jar service is stopped.
It looks like declaring the xxx.jar to depend on the containers it creates
would prevent the containers from being removed from nameToServiceMap.
Though I don't see how - yet - to do that without either exposing
ServiceContext in the controller mbean, or changing the bean deployment
sequence so that the jars containers are known when its service is created.
Reversing the order of service controller shutdown would solve this, but
cause other problems. Changing the whine message level (WARN->INFO) would
make the message less worrisome, but that addresses the symptom, not the
problem. Putting the MainDeployer.shutdown() back with a removeDeployer
loop will get rid of all the warnings, but breaks the service life cycle
symmetry.
Is there a good solution? Or only the lesser of evils? What am I missing?
Rod Burgett Senior Software Engineer
webMethods, Inc. 3930 Pender Drive Fairfax, VA 22030 USA Ph: 703.460.5819 (tty only)
"It's all just 0s & 1s - the trick is getting them lined up in the proper order"
------------------------------------------------------- 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
------------------------------------------------------- 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
