ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Sack" <pisym...@gmail.com>
Subject Re: iBatis within EAR files
Date Fri, 07 Apr 2006 19:45:52 GMT
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

On 4/7/06, Jeff Butler <jeffgbutler@gmail.com> wrote:
>
> If I understand you correctly, you have ibatis JARs in default/lib.  If
> so, that is EXACTLY the problem - they cannot be in that directory.  Most
> Java classloaders delagate to their parents, so even though you have the
> ibatis JARs in your EAR, they are NEVER USED - because the classloader is
> loading the classes from the parent first and the parent classloader is
> pulling them from default/lib (even if you have seemingly stated otherwise
> in your MANIFEST.MF).
>
> So the problem is that the iBATIS classes are loaded by the parent to the
> EAR classloader.  That classloader cannot see resources inside the EAR (this
> is as is should be - and no amount of MANIFEST.MF magic will change that).
>
>
> The answer is to remove the iBATIS JARs from your default/lib directory.
>
> Bottom line - iBATIS does not support it's JAR files being in a parent
> classloader to the resource files.  Most libraries like iBATIS have this
> same restriction.  So never put them in a place like default/lib.  We would
> have the same issue on WebSphere - so we never put iBATIS JARs (or any of
> our other third party JARs) on the global classpath.
>
> Jeff Butler
>
>
> On 4/7/06, Alexander Sack <pisymbol@gmail.com> wrote:
> >
> > Jeff, bingo.  Yea already had it that way where iBatis and some of the
> > commons libraries I'm using were in default/lib (think commons/lib, etc.).
> > But that doesn't really solve my issue.  I can't see resources witihin my
> > jar.   What's odd is that I can't even see resources within my EAR, i.e.
> > if I move the mapfile to outside of the jar file and then try to do
> > getResourceAsReader("mapfile.xml", it still claims it can't find it.
> >
> > The MANIFEST magic is working in terms of keeping iBAtis out of the
> > common lib directory.  After I change the context classLoader and find the
> > resource file that way, everything is good until it tries to find a callback
> > typehandler outside of the EAR in a common library.  SOOO, after more
> > research into the matter, I have tried to setup a MANFIEST file for my EAR
> > with an Extension-List attribute referencing the external library that gets
> > deployed before my EAR under JBoss.  That seems to still not work.  I don't
> > understand why I need to know about my context's classloader of the running
> > thread anyway.  This is ridiculous!!!!  :-)!
> >
> > Opps, yea Jeff, I suspect as well that the EAR is indeed being loaded by
> > the parent classloader causing my grief.  I can't believe though I'm the
> > only one who has ran into this...I'm assuming on Websphere you don't have
> > this problem?
> >
> >
> > -aps
> >
> > On 4/7/06, Jeff Butler <jeffgbutler@gmail.com > wrote:
> > >
> > >  Ah - you didn't say that my.jar was an EJB jar, so I wondered.
> > >
> > > It looks like the iBATIS classes CAN be found, but that the iBATIS
> > > classes cannot find the resources in my.jar.  So it's not an issue of
> > > the MANIFIEST.MF being setup improperly.  This probably means that the
> > > iBATIS classes are not really being loaded by the EAR classloader as you
> > > want them to be - probably they are being loaded by some parent to the EAR
> > > classloader.  Maybe the iBATIS JARs are in some global classpath?  An
> > > interesting experiment would be to remove the iBATIS jar files from the EAR
> > > and see if you get the same error ( i.e. IBATIS can be found, but the
> > > resources can't be found).  This would confirm the problem.
> > >
> > > In WebSphere we would have this same issue if the iBATIS JAR files
> > > were added to the application server's classpath - something we would never
> > > do on purpose.  Maybe you've got a similar problem?
> > >
> > > Sorry I can't be more help with JBoss.  But you shouldn't have to
> > > fiddle with the context classloader.
> > >
> > > Jeff Butler
> > >
> > >
> > > On 4/7/06, Alexander Sack <pisymbol@gmail.com > wrote:
> > > >
> > > > The client?  The client is in my.jar which is a bunch of EJBs plus a
> > > > class wrapping a DAO.  The war file is in a separate deployment.  It looks
> > > > up an EJB interface, calls it.  The interfaces are shared in a common
> > > > library outside both WAR and EAR (global scope).
> > > >
> > > > That eventually gets me inside my.jar.  my.jar DAO wrapper classes
> > > > calles getResourceAsReader()"com/blah/blah)."
> > > >
> > > > The ibatis libraries are part of the my.jar MANIFEST within the
> > > > EAR.  The ibatis libraries are in the EAR under a lib directory (MANIFEST
> > > > has Class-Path entres lib/ibatis.jar ,etc.)..
> > > >
> > > > The only way for me to get this to work is to use
> > > > Thread.currentThread().setContextClassLoader(
> > > > myDAO.class.getClassLoader()) before calling the
> > > > getResourceAsReader() but then for a common typeHandler callback defined
in
> > > > an external library (with global scope) is not found.  I'm not even sure
if
> > > > I really should have to do this.
> > > >
> > > > Thanks for the feedback,
> > > >
> > > > -aps
> > > >
> > > >
> > > > On 4/7/06, Jeff Butler <jeffgbutler@gmail.com > wrote:
> > > > >
> > > > >  What's the client?  my.war?  myejb.jar?  Make sure that my.jar is
> > > > > in the manifest classpath of the client.
> > > > >
> > > > > I have the ibatis*.jar files in the EAR on WebSphere and have no
> > > > > troubles - but the different module's classpaths do need to be setup
> > > > > properly.
> > > > >
> > > > > Jeff Butler
> > > > >
> > > > >
> > > > >  On 4/7/06, Alexander Sack <pisymbol@gmail.com > wrote:
> > > > > >
> > > > > > Hello iBatis Folks,
> > > > > >
> > > > > > I have this problem when using iBatis within in an EAR (I posted
> > > > > > this in the JBoss Forum but so far no solution):
> > > > > >
> > > > > > my.ear
> > > > > > my.jar
> > > > > > my.jar/META-INF/MANIFEST.MF
> > > > > > lib/ibatis*.jar
> > > > > > my.jar/com/blah/blah/mapfile.xml
> > > > > >
> > > > > > The MANIFEST.MF file has Class-Path: lib/ibatis*.jar etc.  When
> > > > > > the EAR gets deployed, the getResourceReader() can not find
the map files
> > > > > > within the my.jar file!  It seems that
> > > > > > getResourceReader("com/blah /balh") can't find it in the current
> > > > > > classpath.  I noticed that the iBatis Resource object is using
the current
> > > > > > thread's context classloader which I'm not sure seems right
to me for this
> > > > > > scenario.
> > > > > >
> > > > > > If I set the currentThread.setContextClassLoader() to my objects
> > > > > > class loader, it can then find the map files witin the JAR but
then can't
> > > > > > find a typeHandler class in a common library outside the EAR
(EARs are
> > > > > > scoped).  So this isn't going to work for me.
> > > > > >
> > > > > > Any clue on how to solve this or how I should load map files
> > > > > > witin a module in an EAR deployment?  What's the best practices
regarding
> > > > > > iBatis and EAR files?
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > -aps
> > > > > >
> > > > > >
> > > > > > --
> > > > > > "What lies behind us and what lies in front of us is of little
> > > > > > concern to what lies within us." -Ralph Waldo Emerson
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > "What lies behind us and what lies in front of us is of little
> > > > concern to what lies within us." -Ralph Waldo Emerson
> > > >
> > >
> > >
> >
> >
> > --
> > "What lies behind us and what lies in front of us is of little concern
> > to what lies within us." -Ralph Waldo Emerson
> >
>
>


--
"What lies behind us and what lies in front of us is of little concern to
what lies within us." -Ralph Waldo Emerson

Mime
View raw message