geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <>
Subject Re: classloading problem for WARs in an EAR file share classpath
Date Wed, 04 Sep 2013 02:20:32 GMT

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 <>

> 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 <>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 <> 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


View raw message