geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <xhh...@gmail.com>
Subject Re: classloading problem for WARs in an EAR file share classpath
Date Tue, 10 Sep 2013 14:02:34 GMT
Yeah, the option a looks fancy in OSGi environment, while it does bring
many compatible issues.

So, it looks like the option b is the way we should go, while it means lots
of changes ...


2013/9/9 David Jencks <david_jencks@yahoo.com>

> I don't think (a) will work since it's entirely possible in an ee
> situation to have packages split between a module (e.g. war) and an
> application library, and we can't reproduce this with bundles.
>
> One reason I originally liked using a bundle for an ee application is that
> you can export classes and then import them into other bundles or ee
> applications.  However with the increasing support for individual ee
> standards directly in osgi bundles this is seeming less important: if you
> want to do something like this you can make your application use the osgi
> versions of the specs directly instead of using ee packaging.
>
> thanks
> david jencks
>
>
>
> On Sep 3, 2013, at 7:20 PM, Ivan <xhhsld@gmail.com> wrote:
>
> Hi,
>
> EE specification leaves this classloader visibility scenario to container,
> while considering that most developers have this kind of isolation in their
> mind, as it is commonly used by most EE application severs, including
> Geronimo 2.*. In my opinion, we should fix this, actually, this is one
> thing left while Geronimo turned to use OSGi to manage different modules. I
> could see the following solutions :
>
> a. Our original idea is to use N+1 bundles for EAR, we will create each
> bundle for each web applications, and create one bundle containing EAR
> libraries and EJB libraries. One difficult thing is to build export
> packages for the later bundle, and generate the according import-packages
> for those web application bundles. Another temporary solution is to use
> Equonix classloader hook, with that, we could not do the export/import
> packages generation now.
>
> b. Copy the Geronimo 2.* classloader codes back to Geronimo 3.*, then only
> use one bundle as the parent of EAR classloader, which could be used to
> load those must classes from server container.
>
>
> 2013/9/4 Jack Cai <cai_jack@us.chanjet.com>
>
>> Yes. The separate wars can be deployed to Geronimo without any problem.
>>
>> Each war uses hibernate, which is the basis of the DAOs. Since the
>> hibernate library in each war uses identical package and class names, EAR
>> classloader loads one hibernate library and one dao from one war, when it
>> comes to load the second dao, it tries to use the first hibernate, that
>> results in CCE.
>>
>> We were hoping to use the classloader isolation of EAR and WAR to manage
>> class loading, so that one EAR app with multiple wars can be deployed
>> multiple times on the same Geronimo instance.
>>
>> Is there a work-around for this? Thanks.
>>
>> -Jack
>>
>>
>>
>> On Tue, Sep 3, 2013 at 5:11 PM, David Jencks <david_jencks@yahoo.com>wrote:
>>
>>> Hi,
>>>
>>> As far as I can tell, the ee spec doesn't specify that wars in an ear
>>> each need their own classloader.  Geronimo passes the tck, so if I missed
>>> any part of the spec that says this so did the tck writers.
>>>
>>> I probably just haven't looked at an application like this recently, but
>>> I'm having trouble understanding exactly how the CCE arises, especially
>>> since the classes appear to be different.
>>>
>>> Can you deploy the wars separately?
>>>
>>> thanks
>>> david jencks
>>> On Sep 3, 2013, at 3:01 PM, Jack Cai <cai_jack@us.chanjet.com> wrote:
>>>
>>> > Hi,
>>> >
>>> >   I package two wars in an ear, web1, and web2. nothing else, and
>>> deployed to geronimo (3.0.1)
>>> >
>>> > When I tried to access web1, web2's classes are loaded instead. What I
>>> found in the MANIFFEST.MF of the EAR package:
>>> >
>>> > Bundle-ClassPath: ...,webdemo-jsp.war/WEB-INF/classes,webdemo2-js
>>> >  p.war/WEB-INF/classes
>>> >
>>> >  after the EAR file is deployed to Geronimo.
>>> >
>>> >   This effectively makes all wars visible to all, and causes the type
>>> cast error:
>>> >
>>> > java.lang.ClassCastException: com.webapp2.dao.Customer cannot be cast
>>> to com.webapp.dao.Customer
>>> >
>>> >   I thought J2EE app is supposed to isolate classloader of each war to
>>> prevent similar problems. Is there a way to config around this in geronimo?
>>> Thanks
>>> >
>>> >   BTW, the ear application is created using Eclipse EAR for Geronimo.
>>> >
>>> > Thanks.
>>> >
>>> > -Jack
>>>
>>>
>>
>
>
> --
> Ivan
>
>
>


-- 
Ivan

Mime
View raw message