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 Wed, 18 Oct 2006 17:38:39 GMT
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
>>>> (MultiParentClassLoader.java:249)
>>>> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
>>>>
>>>> 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: http://www.nabble.com/Multiple- 
> Applications-within-one-Ear---Co-dependent-classes- 
> tf2424151.html#a6878030
> Sent from the Apache Geronimo - Users mailing list archive at  
> Nabble.com.
>


Mime
View raw message