geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Multiple Applications within one Ear - Co-dependent classes
Date Fri, 11 Apr 2008 21:56:42 GMT
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  
> <david_jencks@yahoo.com> 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.
>
>
>


Mime
View raw message