Hi,
I would like to share some ideas about extensions to the current
classloader to see if I am totally on the wrong track and if it
perhaps would be a welcome addition to JBoss.
First I have to say that I still find the "new" classloader
architecture somewhat limiting. If you have the following two
conditions:
1. You do not want components/classes globally available in the
repository because this stops from implementation/interface
versioning.
2. You want to be able to partition your stuff in several deployable
components (locally/remote), but which uses each other (EJB:s
calling EJB:s, MBeans calling MBeans (locally and through RMI),
MBeans calling EJB:s and EJB:s calling MBeans).
The you basically have to do a couple of things:
1. Be very paranoid about what classes get stuffed into your
components.
2. Up to the last classloader change stuff almost every class at the
global
level anyhow, through lib or a dynamic classloader deployer, and
after
the latest changes at least place all interfaces statically
available in the global classloader repository.
To me this hinders one of the aspects that has always was dear to
me: hot redeploy.
Here is an idea (with a working test implementation) to make these
obstacles possible to overcome:
Create a repository which may delegate to other repositories (not just
a parent repository) and make this configurable in jboss-app.xml
Create dependency checks so that lifecykling a component with a
repository which have dependent repositories will make also these
components "lifecyking".
Here is the basic steps I took to create this:
1. Create a DelegatingLoaderRepository which extends
HeirarchicalLoaderRepository3. The delegating repository takes a
list of repositories to delegate to if the normal loading fails.
2. Factor out repository handling in EARDeployer, extends EARDeployer
with a DependantEARDeployer.
EAR:s deployed through this new deployer may set up dependencies
between its own repository and the repositories of other
components. These other repositories must however also have been
created through the dependent deployer; because the repository must
be installed in the ServiceController.
For a repository created through the DependantEARDeployer a
RepositoryProxy is created which will work as a proxy to track
dependency events from the ServiceController. The proxy also takes
the DeploymentInfo of the components; which makes it possible for
the proxy to redeploy its component!
server.createMBean( "org.jboss.deployment.RepositoryProxy",
proxy);
serviceController.create(proxy,depends);
serviceController.start(proxy);
server.setAttribute( proxy, new
Attribute("DeploymentInfo",di));
The repository is then added to ServiceController in the start face
of the deployment (so that all its subcomponents is available and
added to the repository).
So, how can this be used?
Say we have component A and B. B needs to call A.
jboss-app of A:
<jboss-app>
<loader-repository>:loader=compA</loader-repository>
jboss-app of B:
<jboss-app>
<loader-repository
loaderRepositoryClass="org.jboss.mx.loading.DelegatingLoaderRepository"
objectName=":loader=compB"
><depends><depends>:loader=compA</depends></loader-repository>
When both components are deployed it is possible to:
- redeploy B as ordinary
- redeploy A with new classes -> B will be redeployed automatically
Extended example: component C is dependent of B:
<jboss-app>
<loader-repository
loaderRepositoryClass="org.jboss.mx.loading.DelegatingLoaderRepository"
objectName=":loader=compC"
><depends><depends>:loader=compB</depends></loader-repository>
- Redeploying B will lead to C being redeployed:
- Redeploying A will leas to B and C being redeployed.
Circular example:
B depends on A, C depends on B and A:
<loader-repository
loaderRepositoryClass="org.jboss.mx.loading.DelegatingLoaderRepository"
objectName=":loader=compC"
><depends><depends>:loader=compA</depends><depends>:loader=compB</depends></loader-repository>
This works nice to (but is actually not needed since C will see A
through B).
What do you say: is there any hidden pitfalls you immediately see with
this approach? Would it perhaps be something that should be integrated
into JBoss?
//Peter
--
------------------------------------------------------------
Peter Antman Chief Technology Officer, Development
Technology in Media, Box 34105 100 26 Stockholm
WWW: http://www.tim.se WWW: http://www.backsource.org
Email: [EMAIL PROTECTED]
Phone: +46-(0)8-506 381 11 Mobile: +46-(0)704 20 58 11
------------------------------------------------------------
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
