geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fran Varin <>
Subject Re: Multiple Applications within one Ear - Co-dependent classes
Date Wed, 18 Oct 2006 18:47:09 GMT

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

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

David Jencks wrote:
> You left out some details such as whether the objects instantiated by  
> the factory are accessed through an interface available to everyone  
> or through reflection.  I'm also not too clear on whether the wars  
> are all in one ear or deployed separately.
> I suspect we could add a flag that would cause a war to use the ear  
> classloader rather than having a separate classloader.  If everything  
> is in one ear this might work for you.  I don't think we are going to  
> make it so several separately deployed apps have the same classloader.
> In terms of what's in g 1.1.1, there are several things you can try.   
> I'm going to assume that the factory class and a bunch of interfaces  
> need to be accessible to every part of your application.  Recall that  
> the g. classloaders form a directed acyclic graph.  So, you need to  
> get the factory + interfaces into an ancestor of all the war  
> classloaders.  You can do this by:
> - constructing a geronimo module/configuration with a gbean plan that  
> lists the jars containing these classes as a dependency (put the jars  
> in the geronimo repo)
> - constructing a j2ee artifact such as a war or ejb jar with no  
> servlets/ejbs that contians the classes
> - if all wars are in an ear, either
> -- using a geronimo-application.xml plan to pull the jars (in the  
> geronimo repo) into the ear classloader
> -- having an ejb-jar with no ejbs that either contains the classes or  
> uses manifest-classpath to include the jars that are inside the ear
> - putting the jars in shared/lib and using the sharedlib  
> configuration as a parent
> Now, you need to get the actual classes accessible to the factory.   
> You can do this be either
> - putting all these classes in jars that get into the same  
> classloader as the factory, using one of the techniques already  
> described
> - registering all the child classloaders with  the factory, and it  
> can try each in turn (or do something like constructing a geronimo  
> multi-parent classloader that includes all of them as parents and  
> using it)
> The second would let you expand the system at runtime without  
> redeploying the factory.
> hope this helps
> david jencks
> On Oct 18, 2006, at 7:52 AM, Fran Varin wrote:
>> Hi,
>> I work with Mark and maybe I can shed a little more light on the  
>> problem
>> that he is describing. We have classes that are typically  
>> instantiated from
>> a factory class. This factory uses reflection to perform the  
>> instantiation.
>> We register the fully qualified name of the class along with a  
>> String that
>> is used as a key to cause the later instantiation.
>> We have been using WebSphere for years and have configured WAS to  
>> be able to
>> share resources (like classes) across the various Web Applications.  
>> This
>> allows us to maintain the Factory in one context and be able to see  
>> the
>> other class at runtime when an application requests an object  
>> instance of a
>> given class. To the best of my knowledge, the ability for an app.  
>> server to
>> see across the web appications is not unique to WAS. In fact, it makes
>> configuring complex Java EE applications much easier.
>> So, our question really boils down to, how can we achieve a similar  
>> behavior
>> in Geronimo. We would like to use Geronimo for a production  
>> deployment but,
>> feel that the behavior above is a huge advantage where configuration,
>> maintenance, and system resource utilization is concerned. Without the
>> ability we would be required to introduce unnecessary redundancy  
>> across the
>> entire application. Keep in mind that the Web applications we are  
>> describing
>> are an integral part of a larger applications, they are not separate
>> applications running withing the context of one Java EE EAR. Each  
>> WAR is a
>> logical division of business function that directly contributes to the
>> application's functionality. As such, they are not atomic  
>> applications by
>> any definition. So, this strengthens the case above for using resource
>> sharing.
>> Since IBM is very involved with Geronimo (WAS-CE) and is moving to  
>> bring
>> Geronimo and WAS closer together, it is would make sense that the
>> functionality of each would be complementary. Even if we use  
>> Geronimo (or
>> WAS-CE) for testing purposes it is not a desirable situation to be  
>> testing
>> using two servers that have radically different behavior. So, with  
>> that in
>> mind, it does not seem to make sense for Geronimo to dis-allow such a
>> valuable capability.
>> Fran Varin
>> Sr. Architect
>> Amica Insurance
>> Mark L. wrote:
>>> Thanks for the response.  I am not sure i gave enough information the
>>> first time as to what our problem truly is.  We are using a  
>>> factory to
>>> instanciate a list of classes.  This factory lives at the EAR  
>>> level; the
>>> list of classes are spread thru-out the multiple web modules.   
>>> This means
>>> that the factory needs to instantiate some classes in WebA and some
>>> classes in WebB.  It appears the way we have configured out  
>>> application,
>>> the factory itself is loaded in WebA's classloader (WebA is the  
>>> first to
>>> load).  Because of this, when the factory tries to instantiate  
>>> classes in
>>> the list that reside in WebB, they are not visible and we get the
>>> classNotFound exception.  I think putting the classes into jars  
>>> and adding
>>> them as dependencies might be overkill since there is no real
>>> co-dependency upon the classes as i inferred in my original post.   
>>> It is
>>> simply to be able to instantiate them.
>>> Or is there a way to load our factory in the EAR at startup, which i
>>> assume would have visibility to all classes in all web modules?  This
>>> would allow all classes to be instantiated.
>>> We have another application running on Websphere where we have a  
>>> similar
>>> setup.  We use the same factory living at the EAR level, with  
>>> multiple web
>>> modules.  When the first module loads, it loads the factory, which  
>>> is then
>>> able to instantiate all classes listed, regardless of the modules  
>>> they
>>> reside in.
>>> David Jencks wrote:
>>>> On Oct 11, 2006, at 10:18 AM, Mark L. wrote:
>>>>> Hello,
>>>>> I am using Geronimo 1.1.1.  I have created an EAR,
>>>>> ApplicationIntgrations,
>>>>> that contains two web modules, WebA and WebB.  Both web modules
>>>>> require
>>>>> access to each others classes to be able to run.  WebA depends on
>>>>> classes in
>>>>> WebB, and vice versa.  When i deploy the EAR and start the server,
>>>>> i get
>>>>> classNotFound errors.  See below.  Class 'test' is a class in WebB,
>>>>> but
>>>>> WebA's classloader cannot find him.
>>>>> 1:08:49,334 ERROR [[/WebA]] Servlet /WebA threw load() exception
>>>>> java.lang.ClassNotFoundException: test in classloader
>>>>> Applications/ApplicationIntegrations_WebA.war/EAR/car
>>>>> 	at
>>>>> org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass
>>>>> (
>>>>> 	at java.lang.ClassLoader.loadClass(
>>>>> How can i make both web modules' classes visible to each other?  I
>>>>> have
>>>>> tried using dependencies and imports, but i am new to Gernoimo and
>>>>> have not
>>>>> been able to get either to work.
>>>> Since all the classes need to be in the same classloader, you won't
>>>> be able to use dependencies to make this work, as that would lead to
>>>> circular classloader dependencies.  You have to get the classes into
>>>> the ear's classloader: each web app classloader is a child of the  
>>>> ear
>>>> classloader.
>>>> I can think of 3 solutions:
>>>> 1. Put your classes in jars in appropriate places in the geronimo
>>>> repository and add dependencies to them to the geronimo application
>>>> plan.
>>>> 2. Put the jars in the shared/lib directory and add a dependency to
>>>> the shared lib configuration either in the  geronimo application  
>>>> plan
>>>> or in each web app geronimo plan
>>>> 3. Include a fake ejb jar (i.e. a jar with an ejb deployment
>>>> descriptor but no ejbs declared) that either contains all the  
>>>> classes
>>>> or uses the manifest classpath to include the jars with the classes.
>>>> If you only need a one-way dependency then it would be much easier,
>>>> you could just have one web app depend on the other.
>>>> thanks
>>>> david jencks
>> -- 
>> View this message in context: 
>> Applications-within-one-Ear---Co-dependent-classes- 
>> tf2424151.html#a6878030
>> Sent from the Apache Geronimo - Users mailing list archive at  

View this message in context:
Sent from the Apache Geronimo - Users mailing list archive at

View raw message