Submit it as a patch so I can take a look at it. Alternate class loading
strategies should certainly be available. Basically you want to deploy
components that are dependent on each other based on type without
having to aggregate them into the same deployment unit which is what
is required now.
xxxxxxxxxxxxxxxxxxxxxxxx
Scott Stark
Chief Technology Officer
JBoss Group, LLC
xxxxxxxxxxxxxxxxxxxxxxxx
----- Original Message -----
From: "Peter Antman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, February 18, 2003 10:51 AM
Subject: [JBoss-dev] Dependant classloader repository
>
>
> 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
