jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Per Olesen <pole...@nordija.com>
Subject Re: Cactus and weblogic
Date Thu, 23 Oct 2003 20:14:49 GMT
Hi Mark and others,

Thought I ought to come back here and document the solution we found. Even 
though I do not think it is an optimal solution, it might be able to help 

> I haven't used the FilterTestRedirector that I'm aware of, but I've seen
> NoClassDefFoundError's in the wl logs when trying to deploy an ear which
> contained an ejb and some helper jars.  wls couldn't find the helper jars
> due to issues with the manifest file in the ejb. the specific error message
> was very misleading.

Maybe you are thinking of the StringIndexOutOfBoundsException we've seen :-) 
When deploying an app in wls, it unpacks ears and wars to resolve class-path 
refs and then packs it all together again. In this proces, if a .jar includes 
a Class-Path manifest, where none of the referenced paths can be resolved, it 
throws a StringIndexOutOfBounds.

Well, that was not the problem for us.

> > We are aware, that wls uses a three-level classloader
> > hierarchy, with the
> > system classloader at top, the ejb-classloader in the middle and the
> > webapp classloader in the bottom. ....
> My impression is that the ejb classloader is separate from the webapp
> classloader, and not a parent of.

Nope, the ejbclassloader is *not* separate from the war classloaders. Each 
war-file deployed in a ear in wls will have their own classloader, but the 
classloader will be a child of a classloader which contains all the ejbs of 
the same ear. BEA documents this to be a feature, so webapps automagically 
can ref beans, without specificly classpath ref'ing the public interfaces of 
the beans. Do not know what I should think about this.

Anyways, I think this classloader hierarchy was our problem. As I'm working as 
a consultant on a project at a customer, there are limits to how long time we 
could spend solving this :-( so we did not ever find the class which was 
placed up in the hierarchy (if this was the problem). What we did instead was 

We just kept generating the ear as we were used to, with wars inside it, at 
WEB-INF/lib filled with libs, just as it should be.

As the very last thing in the build, we have incorporated into the ant script, 
that we perform a restructure like this:

1. the ear is unpacked
2. each war in the ear is unpacked
3. libs from WEB-INF/lib is moved to ear root level
4. classes from WEB-INF/classes is packed into a webappname-classes.jar and 
jar is moved to ear root level
5. webappname-classes.jar has a generated manifest with a Class-Path ref, 
which references all the libs which was moved from the WEB-INF/lib of the 
6. An ejb.jar of the ear is made to Class-Path ref the webappname-classes.jar

Yikes! Yes, but it works! This way, no wars contain classes/libs anymore, they 
are all placed in the ejb-classloader, one level up.

And better yet, when we upgrade to a newer wls, we can just stop restructuring 
the ear, and see if it works (or gives a better error message).

All this was on wls 6.1. They might have changed their classloaders since :-)

Regards, Per

Per Olesen @ Nordija A/S - www.nordija.com - main#: +45 70 20 25 10
email: polesen@nordija.com - cell#: +45 23 38 95 81

View raw message