2 Replies Latest reply on Mar 23, 2011 2:40 PM by zecas zecas

    EAR+WAR+EJB ... cannot find resource ... classloader problem on my side?

    zecas zecas Newbie

      I'm having a serious problem putting a project to work. It really is hold back my advance in the project, and I'm getting very frustrated with this.

       

       

      Maybe someone can help me here ... I hope so.

       

       

      I have the following structure:

       

       

      project.ear

      +- load-api.jar

      +- webapp.war

         +- WEB-INF

            +- classes

                     +- config.properties

      +- myejb.jar

       

       

       

       

      Components:

       

       

      load-api.jar - jar package that loads stuff, including "config.properties" from classpath.

      Uses something like:

      OneClass.class.getClassLoader().getResourceAsStream( "config.properties" );

       

       

      webapp.war - simple war module, the only one that depends on "load-api.jar"

      Executes a servlet context listener on startup, that will load "config.properties" through "load-api.jar".

       

       

      myejb.jar - simple EJB3 project, that has a simple EJB component that does nothing at this time.

       

       

       

       

      Now I need to use from within the EJB project a class that is defined on "load-api.jar". What I did was just to add a dependency to "load-api.jar", and nothing more (manifest.mf gets updated with jar info). Before I even add a line of code, my project stops working.

       

       

      What happens: the listener executed from within "webapp.war" fails to find the "config.properties" resource.

       

       

      The "config.properties" resource is still defined inside the "WEB-INF->classes" folder of the "webapp.war", like before. But seems that the classloader fails to find it, as if it searches for it inside the EJB ...

       

       

      I believe this should be normal ... but why is it? Can I change this behaviour? Is it a manifest.mf classpath problem?

       

       

      This seems to be a matter of classloading-hell, as I've heard of it. The solution is to pull everything to the EJB? And if it is, will it work the same way in other application server JavaEE compliant?

       

       

       

       

      Thanks

        • 1. EAR+WAR+EJB ... cannot find resource ... classloader problem on my side?
          Peter Johnson Master

          Per the spec, load-api.jar does not have any visibility into classes within webapp.war.  So the correct solution is to place the properties file outside of the WAR file. You can place it into its own JAR file, or into load-api.jar or myejb.jar, whichever works best.

           

          There are some settings that can change this. In 5.1.0, in server/xxx/deployers/jbossweb.deployer/META-INF/war-deployers-jboss-beans.xml look for useJBossWebLoader and java2ClassLoadingCompliance within the WarDeployer bean. Of course, employing this solution is JBoss AS-sepcific and will not apply to other app servers (though they might have alternate mechanisms to do this).

           

          You never said which version of JBoss AS you are using so if it is not 5.1.0 I'll leave it to you to find the file containing the settings. Grep is your friend...

          • 2. EAR+WAR+EJB ... cannot find resource ... classloader problem on my side?
            zecas zecas Newbie

            Hi,

             

            Thank you for your reply.

             

            I believe what I found is part of something bigger.

             

            I've opened a new thread message with more detailed info and some source code included ... I really need to get over the situation, could you at least take a look at it?

             

            I know the message is long ... but it would be nice if you could take a look.

             

            http://community.jboss.org/thread/164417

             

            I'm really needing to get over the situation, as the main project is holding back because of this logging failed situation, which I believe may have something to do with classloaders, classpaths, common libs in JBoss, or something else ...

             

             

            Thank you.