David, First of all: Thanks again for such a quick replay!!. I completely forgot to say I'm using Geronimo 1.2, so I'm more screwed that what I thought. I'll have to rethink application porting and if I have any doubts will write to the list again.
If you think the temp solution of using a system property could benefit the community, I'm glad to be part of the triggering of that :), otherwise don't bother in going on such effort. Again, thanks for your quick replay, now will start thinking on how to migrate this :) Luciano Salotto On Fri, Apr 11, 2008 at 6:56 PM, David Jencks <[EMAIL PROTECTED]> wrote: > I don't think there's any way to do what you want right now. IIRC the > problem is that the Configuration objects for the web apps don't have names > that can be used in the dependency graph. I'm not sure how difficult it > would be to make them available: I suspect rather difficult. > It would be pretty easy to introduce a flag or switch to make an ear have > only one classloader including all the wars, ejb,s and rars. 90% of the > coding effort would be to expose such a flag in the geronimo plan. I'd > rather not introduce such a change until 2.2. Alternatively as a temporary > solution we could use a system property to turn on this behavior: I think > I'd be OK with making this change in 2.1.1 as long as we agreed that it > would be removed in 2.2. > > Thoughts? > > thanks > david jencks > > On Apr 11, 2008, at 1:35 PM, Luciano Salotto wrote: > > David > Thanks for your quick replay. This could be a viable solution, however my > point was that, as same as Fran, we've been using this design with WebSphere > for long time and I thought this could be done in same way in Geronimo. > I tried adding a dependecy from web module A to module B (A depends on B) > in order to get it in the same classloader, however it is failing since > couldn't resolve WebModuleB. How may I state dependency between both > modules? I have both modules declared in geronimo-application.xml which I > paste here, > > <?xml version="1.0" encoding="UTF-8"?> > <application xmlns="http://geronimo.apache.org/xml/ns/j2ee/application-1.1"; > xmlns:sec="http://geronimo.apache.org/xml/ns/security-1.1"; xmlns:sys=" > http://geronimo.apache.org/xml/ns/deployment-1.1"; > application-name="MyApp"> > <sys:environment> > <sys:moduleId> > <sys:groupId>default</sys:groupId> > <sys:artifactId>MyApp</sys:artifactId> > <sys:version>1.0</sys:version> > <sys:type>car</sys:type> > </sys:moduleId> > <sys:dependencies/> > <sys:inverse-classloading/> > </sys:environment> > <module> > <connector>tranql-connector-derby-embed-xa-1.1.rar</connector> > <alt-dd>PartsPoolXA.xml</alt-dd> > </module> > <module> > <web>WebModuleB.war</web> > <web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.1"; > xmlns:nam="http://geronimo.apache.org/xml/ns/naming-1.1"; xmlns:sec=" > http://geronimo.apache.org/xml/ns/security-1.1"; xmlns:sys=" > http://geronimo.apache.org/xml/ns/deployment-1.1";> > <sys:environment> > <sys:moduleId> > <sys:groupId>default</sys:groupId> > <sys:artifactId>WebModuleB</sys:artifactId> > <sys:version>1.0</sys:version> > <sys:type>war</sys:type> > </sys:moduleId> > <sys:dependencies> > <sys:dependency> > <sys:groupId>console.dbpool</sys:groupId> > <sys:artifactId>PartsPoolXA</sys:artifactId> > <sys:version>1.0</sys:version> > <sys:type>rar</sys:type> > </sys:dependency> > </sys:dependencies> > <sys:inverse-classloading/> > </sys:environment> > <context-root>/WebModuleB</context-root> > <nam:resource-ref> > <nam:ref-name>jdbc/parts</nam:ref-name> > <nam:resource-link>PartsPoolXA</nam:resource-link> > </nam:resource-ref> > </web-app> > </module> > <module> > <web>WebModuleA.war</web> > <web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.1"; > xmlns:nam="http://geronimo.apache.org/xml/ns/naming-1.1"; xmlns:sec=" > http://geronimo.apache.org/xml/ns/security-1.1"; xmlns:sys=" > http://geronimo.apache.org/xml/ns/deployment-1.1";> > <sys:environment> > <sys:moduleId> > <sys:groupId>default</sys:groupId> > <sys:artifactId>WebModuleA</sys:artifactId> > <sys:version>1.0</sys:version> > <sys:type>war</sys:type> > </sys:moduleId> > <sys:dependencies> > <sys:dependency> > <sys:groupId>console.dbpool</sys:groupId> > <sys:artifactId>PartsPoolXA</sys:artifactId> > <sys:version>1.0</sys:version> > <sys:type>rar</sys:type> > </sys:dependency> > ****************************** <!--<sys:dependency> > *Added this dependency but, had <sys:groupId>default</sys:groupId> > *to remove it since was failing on > <sys:artifactId>WebModuleB</sys:artifactId> > *deploy: "Unable to resolve dependency <sys:version>1.0</sys:version> > *default/WebModuleB/1.0/war" <sys:type>war</sys:type> > ****************************** </sys:dependency> --> > </sys:dependencies> > <sys:inverse-classloading/> > </sys:environment> > <context-root>/WebModuleA</context-root> > <nam:resource-ref> > <nam:ref-name>jdbc/parts</nam:ref-name> > <nam:resource-link>PartsPoolXA</nam:resource-link> > </nam:resource-ref> > </web-app> > </module> > </application> > > > > > > On Tue, Apr 8, 2008 at 7:09 PM, David Jencks <[EMAIL PROTECTED]> > wrote: > > > I assume you are using an ee 5 ear with a lib directory so A and B get > > the same copy of the common jar. > > > > Assuming you can't just move all the classes into common.... > > > > I would have a factory interface and a provider in common: > > > > public interface Factory { > > ... > > } > > > > public class FactoryProvider { > > static Factory factory; > > > > public static void setFactory(Factory factory) { > > this.factory = factory; > > } > > > > public static Factory getFactoryInstance() { > > return factory; > > } > > > > Then B can register a suitable Factory implementation with the > > FactoryProvider when it starts up. > > > > Hope this helps > > david jencks > > > > On Apr 8, 2008, at 2:30 PM, lsalotto wrote: > > > > > > > Hey Fran, > > > I've been struggling two days for similar issue, have you ever solved > > > the > > > situation? would you mind to share the way you did it? > > > My problem is very similar, have to Web (name them A and B) modules, a > > > jar > > > (named common since both web modules uses them), they are all within > > > the > > > same EAR. Web module A will call have the Factory to create objects in > > > Web > > > module B. Application get up to the Factory, when via reflection it > > > tries to > > > create object in w m B, then I get same exception Mark mentioned. As > > > you > > > we've been working with WAS and this works perfectly, however can't > > > make it > > > work in WAS-CE/Geronimo. > > > > > > You may already forgot about this, but if possible, could you try to > > > search > > > for what you did that time to solve this? > > > > > > Thanks in advance. > > > Luciano Salotto > > > > > > > > > Fran Varin wrote: > > > > > > > > > > > Hi David, > > > > > > > > Thank you for your reply...I'll work with Mark to see if we can work > > > > with > > > > your suggestions. > > > > In terms of your questions regarding my explanation, I'll elaborate > > > > below. > > > > > > > > The factory simply instantiates a concrete class at the request of > > > > an > > > > object that is using the factory. The factory is in fact a singleton > > > > instance. Once the Object is instantiated and returned to the > > > > requester, > > > > the requesting object simply access the public interface on the > > > > object. > > > > The factory returns a type java.lang.Object and the requester > > > > typically > > > > casts the Object to an Interface (polymorphism). > > > > > > > > All of the WARs in question belong to a single Java EE EAR, we are > > > > not > > > > trying to have resources cross the "EAR" boundary. In our WAS > > > > implementation we actually have the factory exposed as part of the > > > > EAR. In > > > > turn, the factory is able to see the classes in each WAR defined to > > > > the > > > > EAR. It sounds like your idea about a switch would be just what the > > > > doctor > > > > ordered in this case, it is a great feature for all of the reasons I > > > > mentioned in my last post. > > > > > > > > We'll give your suggestions a try and post back if we have any > > > > questions/problems and again thanks for your time. > > > > > > > > Fran Varin > > > > Sr. Architect > > > > Amica Insurance > > > > > > > > > > > > > > > > > > > -- > > > View this message in context: http://www.nabble.com/Multiple- > > > Applications-within-one-Ear---Co-dependent-classes-tp6758567s134p16574104.html > > > Sent from the Apache Geronimo - Users mailing list archive at > > > Nabble.com. > > > > > > > > > >
