I filed a JIRA issue under JBoss with permission from one of the members to hopefully address this behavior (at least EAR deployments under JBoss will be more iBatis friendly in the future). I really believe one should not be conscious of the current classloader at runtime in order to load iBatis resource files within an EAR (maybe its pilot error on my part but I haven't found a way to do it with EAR isolation turned on and some folks seem to see more forgiving classloading behavior udner BEA and Websphere).
-aps
On 4/8/06, Alexander Sack <[EMAIL PROTECTED]> wrote:
Hans,
That feature of WebSphere is outside the J2EE realm. See here:
http://java.sun.com/j2ee/verified/packaging.html
The way Sun, i.e J2EE supports optional libs in an EAR is through either the Class-Path or Extension-List manifest attributes. Minimally, EVERY app server should support this. The idea of using a shared lib is not portable across J2EE enivronments. Of course with J2EE 5 coming eventually, there is suppose to be a default directory for modules under an EAR (/lib, and you can change this via the now optional application.xml, I believe Glassfish supports these primitives).
My issue is that there is a requirement that iBatis's classloader needs to be able to see its resource files either the classloader itself or its parent (i.e. the classloader has to have scope of both the library and the XML map files, yet another reason why I'm not a big fan of side XML files).
Another attempt this morning is to put the resource files themselves in the Class-Path attribute.
-apsOn 4/8/06, Beemsterboer Software < [EMAIL PROTECTED]> wrote:Hi Alexander,
Your 'my-ibatis-lib.jar' solution is not exactly what I meant with
'shared library'.
In WebSphere, a shared library resides outside your application.
It seems that JBoss doesn't support shared libraries. You can read more
about this on:
http://www.jroller.com/page/srinivas?entry=websphere_shared_library_why_tomcat
In the comments on that page, some workaround is described that forces
jars to be put into the classpath.
Good luck,
Hans.
Alexander Sack wrote:
> Hi Hans,
>
> I did this:
>
> my.ear:
> my.jar
> lib/my-ibatis-lib.jar
> lib/ibatis- common-2.jar
> lib/ibatis-sqlmap-2.jar
> lib/ibatis-dao-2.jar
>
> my.jar/MANIFEST.MF
> Class-Path: lib/my-ibatis-lib.jar lib/ibatis-common-2.jar etc.
>
> my-ibatis-lib.jar
> blah/blah/blah/sqlMapConfig.xml
>
> >From within EJB3 my.jar, I'm doing
> getResourceAsReader("blah/blah/blah/sqlMapConfig.xml") and I still get
> IOException, it can't find it. OMG...I'm gong to pull out all of my
> hair and I'm already bald!. If iBatis is added to the system
> classloader due to the MANIFEST entry then I maybe screwed no matter
> what. My only last resort is to see if java2Parent delegation will
> have an effect on this.
>
> This is such a basic configuration and I cna't believe I'm the only
> one who has ran into this. Has anyone used iBatis from an EAR under
> JBoss? If so, can you please just give me your package layout?
>
> -aps
>
> On 4/7/06, *Beemsterboer Software* <[EMAIL PROTECTED]
> <mailto: [EMAIL PROTECTED]>> wrote:
>
> Alexander,
>
> When I understand it correctly, you have the iBatis jar files in
> the EAR
> project and
> the iBatis configuration in the EJB project.
>
> Can you try to extract these configuration files and add them as a
> 'shared library' to your application?
> This is a 'good practice':
> - You can configure your application without changing the EAR file.
>
> Also, it may solve your classloading problem.
>
> Greetings,
> Hans.
>
>
>
>
>
> --
> "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
