Well, I'm thinking that there is some misunderstanding on one of our parts. The "bottom line" restriction is not a problem in most cases (certainly I've never found it to be a problem). It only spells doom if the iBATIS classes are actually loaded by the parent classloader - which is why I thought that the iBATIS jars must be on some global classpath in addition to being in your EAR. This is the same reason the Struts folks do not support putting
struts.jar in the EAR - it must be in web-inf\lib. Certain libraries (like commons-digester) can be made to work differently, but they are the rare ones.
J2EE classloading is a mysterious and not very well understood issue. And there is enough ambiguity in the spec that the different app servers do things differently too. At this point, I would suggest looking in the JBoss documentation regarding any settings for classloader configuration in JBoss. There should be a way to set it up so that the classes loaded by the EAR classloader can see each other.
I can't imagine that you are the only person in the world using iBATIS in an EAR on JBoss - so there's got to be a way to make it work. But I'm not a JBoss user, so I'm probably at the end of what I can offer.
Jeff Butler
On 4/7/06, Alexander Sack <[EMAIL PROTECTED]> wrote:
Yea no. iBatis is in the EAR and only in the EAR. Without the MANIFEST file, I get com/ibatis/blah not found which I expect.
Your last statement ("Bottom Line") though is interesting. That could spell doom for me (and many others) using iBatis under an EAR where the classloader maybe the parent from where the actual resource files are located (unless I'm doing something or setting something incorrectly).
At this point, I'm not sure what to do. I can play with the context classloader to get it to load but that doesn't seem right to me and there are other issues with that if a resource file references a shared callback from ane xternal library.
-aps
