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