This sounds like a classloader issue - it wouldn't be tiles by any chance ?
I have seen the same, moving from war to ear. For clues, may I suggest the Wrox Java Sever Programming 1.3 book chapter 24. It is a useful guide.
Alternatively, try extracting the classes that fail to load (and all their dependancies) out into a separate jar, that is inside the EAR. Then put in the manifset.mf a reference to the jar in the classpath line.
Hope this helps
OK, I think I read about this approach before.
BUT what I just don't understand is the fact that the main servlet class (and those that it extends/implements) DO GET loaded alright from the very same jar file that contains the others. So it looks to me as if this were a different behaviour between servlet initialization and execution.
Anyway, I'm gonna try this and see if it works that way.
BTW, If I need more than one jar, can I set the classpath in Manifest.mf to a set of those?
OK, got it working, following yet another approach described elsewhere in the forums.
What I did was to move the jars from the war's
to the ear's ROOT and include them as
into the application.xml file.
Still, as also described in the appropriate entry, this seems to be some kind of bug with the visibility of the jars inside the war which in turn is inside an ear. It is said that it works with the war standalone, but then you cannot easily set up another webcontext, can you?
Still, this is a whole lot better than copying all the jars into server/default/lib.
I didn't know about that way of doing things. Useful to know, any ideas on best practice here ?
But as you said at least it's better that default/lib!!
PS: yes you could specify a set of jars in the manifest.mf