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