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: [EMAIL PROTECTED] - cell#: +45 23 38 95 81 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
