You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Alexander Sack <pi...@gmail.com> on 2006/04/07 18:15:48 UTC
iBatis within EAR files
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
Re: iBatis within EAR files
Posted by Alexander Sack <pi...@gmail.com>.
Hans,
You are correct and I think I will try that since I have a feeling it will
work. It turns out that if you put classes in the MANIFEST.MF file (based
on several posts from Googling) that Jboss puts these classes in the System
classloader outside the scoped EAR. That's why I can't see anything from
iBatis (i.e. getResourceAsReader() which just gets its class loader or the
current threads context class loader).
If I put iBatis and the new resource file jar file as you suggested in the
MANIFEST file I'm trying to load so they are both loaded in the same
classloader repository, then iBatis should find them.
The other possibility is to go back to unscoped EARs but I want to try to
avoid this. All I can say is that this has been a horrifing two
days...thanks folks for the help...and I wil let you know...
-aps
On 4/7/06, Beemsterboer Software <ha...@beemsterboer-software.nl> 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
Re: iBatis within EAR files
Posted by Alexander Sack <pi...@gmail.com>.
In case anyone is wondering, I had to set the contextclass loader manually (
Thread.currentThread().setContextClassLoader(getClass().getClassLoader()) to
be able to read my files. I then had to move any classes that my mapfiles
need to within in the EAR (remember its isolatation is turned on).
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 <pi...@gmail.com> 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.
>
> -aps
>
>
> On 4/8/06, Beemsterboer Software <ha...@beemsterboer-software.nl> 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* <hans@beemsterboer-software.nl
> > > <mailto: hans@beemsterboer-software.nl>> 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
Re: iBatis within EAR files
Posted by Alexander Sack <pi...@gmail.com>.
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.
-aps
On 4/8/06, Beemsterboer Software <ha...@beemsterboer-software.nl> 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* <hans@beemsterboer-software.nl
> > <ma...@beemsterboer-software.nl>> 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
Re: iBatis within EAR files
Posted by Beemsterboer Software <ha...@beemsterboer-software.nl>.
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* <hans@beemsterboer-software.nl
> <ma...@beemsterboer-software.nl>> 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
Re: iBatis within EAR files
Posted by Joe Wolf <jo...@compsciresources.com>.
Unfortunately, I haven't tried it without Spring. I forgot to mention that the Spring jar was also directly underneath my ear and included in the Class-Path of both my ear file's and war file's manifests. It looks like Spring gets the SQLMap with the ContextClassLoader, too.
-Joe
----- Original Message -----
From: Alexander Sack
To: user-java@ibatis.apache.org
Sent: Wednesday, April 12, 2006 12:16 AM
Subject: Re: iBatis within EAR files
Hey Joe, thanks a lot for the response!
To be honest, I have another group within the project who also uses Spring in this exact manner to get iBatis working within a JBoss EAR. However, I'm trying to avoid the use of yet another IoC technology in my project unless I really really have too. Currently I have everything working by playing with the context classloader at sqlMap load time which does the trick.
If I had time, I would probably convert the DAO facade layer to something that use the Persistence API which is annotation based (and less side XML files which I don't like in general).
All I can say is that the UCL3 in JBoss is very strange in regards to EAR scope and optional libraries via the Class-Path manifest entries (like I said, I filed a bug report on it since I really believe its not right.
I'm assuming you haven't tried it without Spring?
-aps
On 4/11/06, Joe Wolf <jo...@compsciresources.com> wrote:
I'm using iBATIS within a JBoss EAR. I'm using Spring, though, which helps a lot. Anyways, here's how everything's set up:
my.ear:
* my-daos.jar - contains my DAOs, all of which extend org.springframework.orm.ibatis.SqlMapClientDaoSupport
* my.war - contains Spring XML config
* ibatis-common-2.jar
* ibatis-dao-2.jar
* ibatis-sqlmap-2.jar
my.ear/META-INF/MANIFEST.MF:
Class-Path: ibatis-common-2.jar ibatis-dao-2.jar ibatis-sqlmap-2.jar
my-daos.jar: contains all my sqlmaps underneath an sqlmaps subdirectory and my DAOS
* sqlmaps/____SQLMap.xml
* com/mycompany/myapp/dao/___DAO.class
* SQLMapConfig.xml - the master configuration for iBATIS
my.war:
* WEB-INF/spring-context.xml
* WEB-INF/web.xml
my.war/META-INF/MANIFEST.MF:
Class-Path: ibatis-common-2.jar ibatis-dao-2.jar ibatis-sqlmap-2.jar
my.war/WEB-INF/spring-context.xml:
<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="java:/DataSource"/>
</bean>
<bean id="sqlMapClient" class="org.springframework.orm.ibatis.SqlMapClientFactoryBean" singleton="true">
<property name="configLocation" value="classpath:SQLMapConfig.xml"/>
<property name="dataSource" ref="dataSource"/>
<!-- I know, I'm not using Spring's transaction management...I wasn't quite sure how to, but this ibatis class gave me all the transaction support I needed -->
<property name="transactionConfigClass" value="com.ibatis.sqlmap.engine.transaction.jdbc.JdbcTransactionConfig"/>
</bean>
<bean id="myPersonDAO" class="com.mycompany.myapp.dao.PersonDAO" signleton="true">
<property name="sqlMapClient" ref="sqlMapClient"/>
</bean>
my.war/WEB-INF/web.xml:
<context-param>
<param-name>contextConfiguration</param-name>
<param-value>/WEB-INF/spring-context.xml</param-name>
</context-param>
<servlet>
<servlet-name>context</servlet-name>
<servlet-class>org.springframework.web.context.ContextLoaderServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
Now, to get to a DAO, I just do this more or less (actually, I never retrieve the DAOs directly, they're injected by Spring into my Manager classes). These are all Spring classes, except for the DAO:
ConfigurableWebApplicationContext context = (ConfigurableWebApplicationContext)WebApplicationContextUtils.getRequiredWebApplicationContext(session.getServletContext());
ConfigurableBeanFactory factory = (ConfigurableBeanFactory)context.getBeanFactory();
PersonDAO dao = (PersonDAO)factory.getBean("myPersonDAO");
Everything's working fine, including transactions, although I am curious how I could set it up to use the external transaction config and Spring's transaction stuff. Hope this helps.
-Joe
----- Original Message -----
From:
To: user-java@ibatis.apache.org
Sent: Friday, April 07, 2006 5:44 PM
Subject: Re: iBatis within EAR files
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 <ha...@beemsterboer-software.nl> 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
Re: iBatis within EAR files
Posted by Alexander Sack <pi...@gmail.com>.
Hey Joe, thanks a lot for the response!
To be honest, I have another group within the project who also uses Spring
in this exact manner to get iBatis working within a JBoss EAR. However, I'm
trying to avoid the use of yet another IoC technology in my project unless I
really really have too. Currently I have everything working by playing with
the context classloader at sqlMap load time which does the trick.
If I had time, I would probably convert the DAO facade layer to something
that use the Persistence API which is annotation based (and less side XML
files which I don't like in general).
All I can say is that the UCL3 in JBoss is very strange in regards to EAR
scope and optional libraries via the Class-Path manifest entries (like I
said, I filed a bug report on it since I really believe its not right.
I'm assuming you haven't tried it without Spring?
-aps
On 4/11/06, Joe Wolf <jo...@compsciresources.com> wrote:
>
> I'm using iBATIS within a JBoss EAR. I'm using Spring, though, which
> helps a lot. Anyways, here's how everything's set up:
>
> my.ear:
> * my-daos.jar - contains my DAOs, all of which extend
> org.springframework.orm.ibatis.SqlMapClientDaoSupport
> * my.war - contains Spring XML config
> * ibatis-common-2.jar
> * ibatis-dao-2.jar
> * ibatis-sqlmap-2.jar
>
> my.ear/META-INF/MANIFEST.MF:
> Class-Path: ibatis-common-2.jar ibatis-dao-2.jar ibatis-sqlmap-2.jar
>
> my-daos.jar: contains all my sqlmaps underneath an sqlmaps subdirectory
> and my DAOS
> * sqlmaps/____SQLMap.xml
> * com/mycompany/myapp/dao/___DAO.class
> * SQLMapConfig.xml - the master configuration for iBATIS
>
> my.war:
> * WEB-INF/spring-context.xml
> * WEB-INF/web.xml
>
> my.war/META-INF/MANIFEST.MF:
> Class-Path: ibatis-common-2.jar ibatis-dao-2.jar ibatis-sqlmap-2.jar
>
> my.war/WEB-INF/spring-context.xml:
> <bean id="dataSource" class="
> org.springframework.jndi.JndiObjectFactoryBean">
> <property name="jndiName" value="java:/DataSource"/>
> </bean>
>
> <bean id="sqlMapClient" class="
> org.springframework.orm.ibatis.SqlMapClientFactoryBean" singleton="true">
> <property name="configLocation" value="classpath:SQLMapConfig.xml"/>
> <property name="dataSource" ref="dataSource"/>
> <!-- I know, I'm not using Spring's transaction management...I wasn't
> quite sure how to, but this ibatis class gave me all the transaction support
> I needed -->
> <property name="transactionConfigClass" value="
> com.ibatis.sqlmap.engine.transaction.jdbc.JdbcTransactionConfig"/>
> </bean>
>
> <bean id="myPersonDAO" class="com.mycompany.myapp.dao.PersonDAO"
> signleton="true">
> <property name="sqlMapClient" ref="sqlMapClient"/>
> </bean>
>
> my.war/WEB-INF/web.xml:
>
> <context-param>
> <param-name>contextConfiguration</param-name>
> <param-value>/WEB-INF/spring-context.xml</param-name>
> </context-param>
>
> <servlet>
> <servlet-name>context</servlet-name>
> <servlet-class>org.springframework.web.context.ContextLoaderServlet
> </servlet-class>
> <load-on-startup>1</load-on-startup>
> </servlet>
>
> Now, to get to a DAO, I just do this more or less (actually, I never
> retrieve the DAOs directly, they're injected by Spring into my Manager
> classes). These are all Spring classes, except for the DAO:
>
> ConfigurableWebApplicationContext context =
> (ConfigurableWebApplicationContext)WebApplicationContextUtils.getRequiredWebApplicationContext(
> session.getServletContext());
> ConfigurableBeanFactory factory =
> (ConfigurableBeanFactory)context.getBeanFactory();
> PersonDAO dao = (PersonDAO)factory.getBean("myPersonDAO");
>
> Everything's working fine, including transactions, although I am curious
> how I could set it up to use the external transaction config and Spring's
> transaction stuff. Hope this helps.
>
> -Joe
>
> ----- Original Message -----
> *From:*
> *To:* user-java@ibatis.apache.org
> *Sent:* Friday, April 07, 2006 5:44 PM
> *Subject:* Re: iBatis within EAR files
>
> 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 <ha...@beemsterboer-software.nl> 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
Re: iBatis within EAR files
Posted by Joe Wolf <jo...@compsciresources.com>.
I'm using iBATIS within a JBoss EAR. I'm using Spring, though, which helps a lot. Anyways, here's how everything's set up:
my.ear:
* my-daos.jar - contains my DAOs, all of which extend org.springframework.orm.ibatis.SqlMapClientDaoSupport
* my.war - contains Spring XML config
* ibatis-common-2.jar
* ibatis-dao-2.jar
* ibatis-sqlmap-2.jar
my.ear/META-INF/MANIFEST.MF:
Class-Path: ibatis-common-2.jar ibatis-dao-2.jar ibatis-sqlmap-2.jar
my-daos.jar: contains all my sqlmaps underneath an sqlmaps subdirectory and my DAOS
* sqlmaps/____SQLMap.xml
* com/mycompany/myapp/dao/___DAO.class
* SQLMapConfig.xml - the master configuration for iBATIS
my.war:
* WEB-INF/spring-context.xml
* WEB-INF/web.xml
my.war/META-INF/MANIFEST.MF:
Class-Path: ibatis-common-2.jar ibatis-dao-2.jar ibatis-sqlmap-2.jar
my.war/WEB-INF/spring-context.xml:
<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="java:/DataSource"/>
</bean>
<bean id="sqlMapClient" class="org.springframework.orm.ibatis.SqlMapClientFactoryBean" singleton="true">
<property name="configLocation" value="classpath:SQLMapConfig.xml"/>
<property name="dataSource" ref="dataSource"/>
<!-- I know, I'm not using Spring's transaction management...I wasn't quite sure how to, but this ibatis class gave me all the transaction support I needed -->
<property name="transactionConfigClass" value="com.ibatis.sqlmap.engine.transaction.jdbc.JdbcTransactionConfig"/>
</bean>
<bean id="myPersonDAO" class="com.mycompany.myapp.dao.PersonDAO" signleton="true">
<property name="sqlMapClient" ref="sqlMapClient"/>
</bean>
my.war/WEB-INF/web.xml:
<context-param>
<param-name>contextConfiguration</param-name>
<param-value>/WEB-INF/spring-context.xml</param-name>
</context-param>
<servlet>
<servlet-name>context</servlet-name>
<servlet-class>org.springframework.web.context.ContextLoaderServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
Now, to get to a DAO, I just do this more or less (actually, I never retrieve the DAOs directly, they're injected by Spring into my Manager classes). These are all Spring classes, except for the DAO:
ConfigurableWebApplicationContext context = (ConfigurableWebApplicationContext)WebApplicationContextUtils.getRequiredWebApplicationContext(session.getServletContext());
ConfigurableBeanFactory factory = (ConfigurableBeanFactory)context.getBeanFactory();
PersonDAO dao = (PersonDAO)factory.getBean("myPersonDAO");
Everything's working fine, including transactions, although I am curious how I could set it up to use the external transaction config and Spring's transaction stuff. Hope this helps.
-Joe
----- Original Message -----
From:
To: user-java@ibatis.apache.org
Sent: Friday, April 07, 2006 5:44 PM
Subject: Re: iBatis within EAR files
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 <ha...@beemsterboer-software.nl> 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
Re: iBatis within EAR files
Posted by Alexander Sack <pi...@gmail.com>.
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 <ha...@beemsterboer-software.nl> 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
Re: iBatis within EAR files
Posted by Beemsterboer Software <ha...@beemsterboer-software.nl>.
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.
Re: iBatis within EAR files
Posted by Alexander Sack <pi...@gmail.com>.
Thanks Jeff a lot. Yea, your absolutely correct about J2EE classloading
which IMO is a wreck in the specification (it should be well understood and
analgous across app servers).
Yeah, this all started when I turned on EAR isolation on. I'm going to
explore EAR isoloation and java2Parent delegation in JBoss. There are
Twiki's that explain it but I'm finding it still mysterious.
You know all the examples of iBatis and J2EE involve WARs where WEB-INF/lib
and classloading is alittle bit more understood.
The fact that I understand the issue makes me feel a little better...
-aps
On 4/7/06, Jeff Butler <je...@gmail.com> wrote:
>
> 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 <pi...@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
> >
>
>
--
"What lies behind us and what lies in front of us is of little concern to
what lies within us." -Ralph Waldo Emerson
Re: iBatis within EAR files
Posted by Jeff Butler <je...@gmail.com>.
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 <pi...@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
>
Re: iBatis within EAR files
Posted by Alexander Sack <pi...@gmail.com>.
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 <je...@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 <pi...@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
Re: iBatis within EAR files
Posted by Jeff Butler <je...@gmail.com>.
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 <pi...@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 <je...@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
>
Re: iBatis within EAR files
Posted by Alexander Sack <pi...@gmail.com>.
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 <je...@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 <pi...@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
Re: iBatis within EAR files
Posted by Jeff Butler <je...@gmail.com>.
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 <pi...@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 <je...@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
>
Re: iBatis within EAR files
Posted by Alexander Sack <pi...@gmail.com>.
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 <je...@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 <pi...@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
Re: iBatis within EAR files
Posted by Jeff Butler <je...@gmail.com>.
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 <pi...@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
>