[jboss-jira] [JBoss JIRA] Updated: (JBAS-3086) MANIFEST Class-Path entires for optional libraries within an EAR have limited scope over the modules within the EAR itself

[Dimitris Andreadis (JIRA)]

     [ http://jira.jboss.com/jira/browse/JBAS-3086?page=all ]

Dimitris Andreadis updated JBAS-3086:
-------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.CR1)

> MANIFEST Class-Path entires for optional libraries within an EAR have limited scope over the modules within the EAR itself
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3086
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3086
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions: JBossAS-4.0.3 SP1
>         Environment: Windows XP Service Pack 2, JDK 1.5.0_06, JBoss is installed in C:\dev\jboss-4.0.3SP1, latest cygwin environment to start and stop JBoss from a shell
>            Reporter: Alexander Sack
>
> I have JBoss 4.0.3SP1 with EAR isolation turned on via the ear.deployer service xml config file.  I have the following EAR format:
> my.ear:
> META-INF/application.xml
> my.jar
> lib/ibatis-common-2.jar
> lib/ibatis-sqlmap-2.jar
> lib/ibatis-dao-2.jar
> In the application.xml, the my.jar is the only defined module.  It is an EJB3 package:
> my.jar:
> META-INF/MANIFEST.MF
> com/blah/blah/ibatis/config/sql-map-config.xml
> com/blah/blah/ibatis/map/Mapfile.xml
> So my.jar needs the iBatis library to function properly (there is a class in there that wraps a DAO).  Therefore, using the current J2EE 1.4 approach, I use the MANIFEST Class-Path attribute to reference my optional library within my.jar::
> MANIFEST.MF:
> Class-Path:  lib/ibatis-common-2.jar lib/ibatis-sqlmap-2.jar lib/ibatis-dao-2.jar
> Deployment works in that now my.jar does indeed have access to the ibatis libraries packaged with the my.ear archive.  However, now any side XML files needed by iBatis are no longer visible by the libraries themselves.  For example, I have a class within my.jar like this:
> public class MyClass {
>    SqlMapClient _sqlMapClient;
>     static {
>          try {
>                   String configFile = "com/blah/blah/blah/ibatis/config/sql-map-config.xml";
>                    Resources resource = Resources.getReousrce(configFile);
>                    SqlMapClient _sqlMapClient = buildSqlMap(resource);
>           }  catch (Exception e) {
>                     etc.
>           }
>     }
> }
> iBatis fails with an IOException claiming it can not find the sql-map-config file packaged withih my.jar module in my.ear.  If I package all of my config files in their own separate jar archive (ibatis-config.jar) and put that on the Class-Path that also doesn't work.  This could be pilot error on my part but I believe this should work.
> Bottom line for me is that libraries as well as my modules should always have some level of scope across the EAR they are packaged in.  I have not started to debug JBoss but I would guess that the MANIFEST entries are not part of the EAR classloader repository but part of the system classloader one.  My understanding of classloading is that with EAR isolation, JBoss should first delegate to the parent classloader of the EAR and if the resource is not found, search the EAR itself (unless java2Paranet delegation is turned off which case the UCL is not checked first for cached resources but instead looks directly at the EAR itself).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira