Uploaded image for project: 'Application Server 3 4 5 and 6'
  1. Application Server 3 4 5 and 6
  2. JBAS-3086

MANIFEST Class-Path entires for optional libraries within an EAR have limited scope over the modules within the EAR itself

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Obsolete
    • Icon: Major Major
    • No Release
    • JBossAS-4.0.3 SP1
    • Deployers
    • None

    • 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

    • High
    • Workaround Exists
    • Hide

      Well you can do the following to give iBatis scope across the EAR:

      ClassLoader cl = Thread.currentThread().getContextClassLoader();
      Thread.currentThread().setContextClassLoader(getClass().getClassLoader();
      ...load iBatis...
      Thread.setContextClassLoader(cl);

      This has the side effect of not seeing any globally defined objects across all EARs, i.e. if I have a callbackHandler defined in a common library in deploy (global scope across all deployments) its not visibile to iBatis using this method. I suppose I could include that handler for each EAR to work around this but again, it seems wrong to me.

      Show
      Well you can do the following to give iBatis scope across the EAR: ClassLoader cl = Thread.currentThread().getContextClassLoader(); Thread.currentThread().setContextClassLoader(getClass().getClassLoader(); ...load iBatis... Thread.setContextClassLoader(cl); This has the side effect of not seeing any globally defined objects across all EARs, i.e. if I have a callbackHandler defined in a common library in deploy (global scope across all deployments) its not visibile to iBatis using this method. I suppose I could include that handler for each EAR to work around this but again, it seems wrong to me.

      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).

              Unassigned Unassigned
              asack Alexander Sack (Inactive)
              Votes:
              4 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: