On 2003.02.19 03:43 Peter Antman wrote:
> 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.
OK, but thats a bug in the implementation. Where is this code?
>
> 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.
You can't do that with standard mbeans, the classs--mbean dependency is
tracked and used to undeploy/redeploy the mbean instance as the classloader
is cycled. Maybe we can extend this to modelmbeans and ejbs.
thanks
david
>
> //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
>
>
-------------------------------------------------------
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
