On Tue, 2003-02-18 at 20:08, David Jencks wrote:
> I don't yet understand what problem you are trying to solve. The problem I
> know of with the current deployment set up and LoaderRepositories is that
> the only package type you can specify a LoaderRepsository in is an .ear.
> This however is easy to fix without more kinds of LoaderRepositories. You
> can already add several .ears to the same named LoaderRespository and (if
> there are no bugs) redeploy each independently.
Could have been working but is not:
if(
di.repositoryName.equals(DeploymentInfo.DEFAULT_LOADER_REPOSITORY) ==
false )
{
log.debug("Destroying ear loader
repository:"+di.repositoryName);
try
{
this.server.unregisterMBean(di.repositoryName);
}
catch(Exception e)
{
log.warn("Failed to unregister ear loader repository", e);
}
}
The first ear to get redeployed will destroy the repository! And will
make the other ear:s *very* confused.
My experience is also that a component that gets its classloader swaped
under the hood without beeing properly redeployed will behave very
eratic. Thats why.
//Peter
> I don't know if all
> dependencies between .ears are properly taken care of.
>
> What will having a deeper hierarchy of LoaderRepositories get you? I don't
> understand the situation in which this would be useful.
>
> Also, I am planning on moving the dependency computatations out of
> ServiceController and into an mbean interceptor (with some global
> supporting objects).
>
> thanks
> david jencks
>
>
>
> On 2003.02.18 13:51 Peter Antman wrote:
> >
> >
> > 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
> >
> >
>
>
> -------------------------------------------------------
> 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
--
------------------------------------------------------------
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: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
