ons 2003-02-19 klockan 15.09 skrev David Jencks:
> 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?
>
I really do not know if it should be considered a bug; someone must have
the responibility to remove it when its not used; and that can only be
done by tracking dependandices. (Its in EARDeployer)
> >
> > 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.
Bu my experimental code solves that by having a depenant tracking proxy
wich holds the deployment info object for its component and is therefor
capable of redeploying it.
What would be best I guess is to just see to it that the classes
involved is really possible to sublclass in ameaningfull way; so that it
is possible to create your on repository/tracking mechanisms.
//Peter
//Peter
>
> 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
--
------------------------------------------------------------
Peter Antman Technology in Media, Box 34105 100 26 Stockholm
CTO WWW: http://www.tim.se
Email: [EMAIL PROTECTED] WWW: http://www.backsource.org
Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942
------------------------------------------------------------
-------------------------------------------------------
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
