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 
others.

> 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 
this:

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 
war.
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


Mime
View raw message