classloading problem for WARs in an EAR file share classpath

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

classloading problem for WARs in an EAR file share classpath

Jack Cai
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
Reply | Threaded
Open this post in threaded view
|

Re: classloading problem for WARs in an EAR file share classpath

David Jencks
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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: classloading problem for WARs in an EAR file share classpath

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 <[hidden email]> 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 <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: classloading problem for WARs in an EAR file share classpath

Ivan Xu
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 <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: classloading problem for WARs in an EAR file share classpath

David Jencks
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 <[hidden email]> 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 <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: classloading problem for WARs in an EAR file share classpath

Ivan Xu
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 <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> 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