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. > > > > >
