-----Urspr�ngliche Nachricht----- >Von: Rickard �berg [mailto:[EMAIL PROTECTED]] >Gesendet: Freitag, 8. Dezember 2000 12:42 >An: jBoss Developer >Betreff: Re: [jBoss-Dev] Proposed refactoring of ContainerFactory-Ch >ainingDeployment services in general >Yes, absolutely. It would an easy fix too (and easy fixes are nice, >regardless of their use 8-) ). >Basically, we would need an jboss-application.xml file in addition to >the application.xml one, in which one should be able to specify parent >application. On deployment the parent of classloader of the application >would be the CL of the parent application. Also, any beans in child >application should be able to use parent application EJB names in >ejb-link references. Hey, this is getting really really interesting! So, >the only new rule is that EJB-names in child EAR's may not conflict with >EJB-names of beans in the respective parent application. >Sounds ok? >It is easy to do this, but not trivial. If you're interested in coding >this I'd be willing to give you a few pointers on how to make it as >clean as possible. Ok, it�s on my stack for the next two weeks ;-) But I�ll have some questions especially about the ejb-link stuff, since we didn�t use this yet. But if I see it correctly, this would require a link from some of the childrens meta-data to its parent ones with a few recursively-extended accessors ? And if doing it anyway: what about the cyclic dependencies? We could implement it such that the jboss-application.xml rather speaks about dependencies in general, not parentship in particular. Each classloader would then represent a clique of EAR�s (URLClassLoader.addURL() should allow a conveniant implementation of this idea) where parentship follows unidirectional dependencies between the cliques ... Finally, when un-/redeploying some EAR, the deployer could un/redeploy all the applications located in the same and subordinate classloaders ... Opinions, anyone? Best, CGJ
