You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by lsalotto <ls...@gmail.com> on 2008/04/08 23:30:18 UTC

Re: Multiple Applications within one Ear - Co-dependent classes

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.


Re: Multiple Applications within one Ear - Co-dependent classes

Posted by Luciano Salotto <ls...@gmail.com>.
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 <da...@yahoo.com>
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 <da...@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.
> > >
> > >
> >
>
>

Re: Multiple Applications within one Ear - Co-dependent classes

Posted by David Jencks <da...@yahoo.com>.
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  
> <da...@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.
>
>
>


Re: Multiple Applications within one Ear - Co-dependent classes

Posted by Luciano Salotto <ls...@gmail.com>.
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 <da...@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.
> >
> >
>

Re: Multiple Applications within one Ear - Co-dependent classes

Posted by David Jencks <da...@yahoo.com>.
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.
>