ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Butler" <jeffgbut...@gmail.com>
Subject Re: iBatis within EAR files
Date Fri, 07 Apr 2006 20:13:25 GMT
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

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 <pisymbol@gmail.com> 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

View raw message