You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by Jack Cai <ca...@us.chanjet.com> on 2013/09/04 00:01:04 UTC
classloading problem for WARs in an EAR file share classpath
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
Re: classloading problem for WARs in an EAR file share classpath
Posted by Ivan <xh...@gmail.com>.
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 <da...@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 <xh...@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 <ca...@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 <da...@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 <ca...@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
Re: classloading problem for WARs in an EAR file share classpath
Posted by David Jencks <da...@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 <xh...@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 <ca...@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 <da...@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 <ca...@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
Re: classloading problem for WARs in an EAR file share classpath
Posted by Ivan <xh...@gmail.com>.
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 <ca...@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 <da...@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 <ca...@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
Re: classloading problem for WARs in an EAR file share classpath
Posted by Jack Cai <ca...@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 <da...@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 <ca...@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
>
>
Re: classloading problem for WARs in an EAR file share classpath
Posted by David Jencks <da...@yahoo.com>.
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 <ca...@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