simplify :)
marcf > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On > Behalf Of Peter Antman > Sent: Wednesday, February 19, 2003 12:32 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Dependant classloader repository > > > 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.DelegatingLoaderRe > pository" > > > > > 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.DelegatingLoaderRe > pository" > > > > > 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.DelegatingLoaderRe > pository" > > > > > 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 > ------------------------------------------------------- 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
