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