I thought I'd write a note explaining what my recent changes to the mbean
deployment in rh do.
1. Recursive deployment. The classpath elements in a *service.xml file may
be used to specify dependencies on jar and zip archives, sar archives
(containing a jboss-service.xml file), or *-service.xml files. Each listed
dependency is loaded before the mbeans in the current *service.xml file are
created and started. There's a test case for this in jmx. This
functionality is actually used in the current jboss: jbossmq-service.xml is
in the deploy/lib directory, and is autodeployed after the core
jboss-service.xml. jbossmq-service.xml depends on jbosscx.sar (due to the
jmsra resource adapter), so jbosscx.sar is recursively deployed.
2. Recursive undeployment based on package dependencies. If C depends on B
which in turn depends on A, as just noted deploying C will deploy A, then
B, then C. Recursive undeployment means undeploying A will undeploy B and
C. Redeploying A will redeploy B and C automatically.
3. Undeploying a package actually works. Mbeans specified in the package
are removed, and the classes from the codebase are removed from the
classloader system (if they are not also deployed by another package not
dependent on the one you are undeploying). There are test for this in jmx.
(As part of the jbosscx reorganization, all jca related classes are in the
jbosscx.sar, which contains the mbean configuration for the
ConnectionManagerFactoryLoaders and the RARDeployer. The jbossmq
configuration is now in a jbossmq-service.xml file, which depends on the
jbosscx.sar ( and causes it to be recursively deployed). The configuration
for the Hypersonic-based DefaultDS is in hsql-default-service.xml, which is
also autodeployed.)
The classpath element in a *service.xml file works like this:
attribute codebase
-- if missing, specifies the jboss.system.libraryDirectory set on startup
-- if . specifies the same directory as the current file is in (not
tested with http)
-- if a url, specifies the url.
attribute archives is a comma delimited list of jar, zip, sar, and
*service.xml packages the current package depends on.
If the archives attribute is missing and the codebase is a file url, all
jar and zip files in the directory are added.
There can now be multiple classpath elements.
Known problems:
Currently, deploying an already deployed package undeploys and (re) deploys
it. This can cause churn if you are autodeploying a set of interdependent
packages. Say C depends on B which depends on A. If the autodeployed
picks C to deploy first, when it deploys B C will be undeployed and
redeployed, and when it deploys A B and C will be undeployed and
redeployed. I can think of 2 solutions:
a. deploying an already deployed packaged does nothing. To refresh,
undeploy and redeploy. I like this one, but it changes current behavior.
b. The autodeployer keeps track of a "autodeployment session" and recieves
notifications of deployed packages. It doesn't try to deploy anything it
received a deploy notification for in the current session.
All comments appreciated.
thanks
david jencks
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
