3 Replies Latest reply on Feb 22, 2009 2:43 AM by jaikiran

    ejb3.deployer does not have access to ear scoped loader repo

    barakka
    barakka Feb 18, 2009 4:45 PM

      Hello,

      I'm using JBoss 4.2.3 and I would like to update one single ear application to the latest version Hibernate. To do that, I've placed all the needed libraries in the ear lib and used the jboss-app.xml to declare a scoped loader repository, such that the lib in my ear override the one in the default jboss lib dir.

      The theory is fine, but then, in practice, I've discovered that the ejb3.deployer that is deploying my ejb (and most importantly the persistence unit) is still accessing the default lib, resulting in a classcast exception later on.

      To further prove this, I've removed the hibernate libs from the jboss lib directory (after all they are in my ear lib, right?) and in turns our that I get a class not found exception for one of the classes in the hibernate lib (actually for any class in the hibernate lib). After debugging the jboss classloader, i discovered that the classes in question are looked for and cannot be found in the ejb3.deployer loader repository, that is of course different from the ear loader repository.

      So, does any one have any idea on how I can tell the ejb3.deployer to use the ear loader repository? (I've seen something in case of a remoting connector, https://jira.jboss.org/jira/browse/JBREM-962, but i believe is not related to what i need).

      Thanks,
      Riccardo.

      • 1692 Views
      • Tags:
        • 1. Re: ejb3.deployer does not have access to ear scoped loader
          jaikiran
          jaikiran Feb 19, 2009 1:45 AM (in response to barakka)

          The ejb3.deployer should not use the jars that your application(s) package. They will use the ones that have been shipped in the AS.


          "barakka" wrote:


          I'm using JBoss 4.2.3 and I would like to update one single ear application to the latest version Hibernate.


          You can do this as explained here http://www.jboss.org/index.html?module=bb&op=viewtopic&t=133202



            • Actions
          • 2. Re: ejb3.deployer does not have access to ear scoped loader
            barakka
            barakka Feb 19, 2009 9:54 AM (in response to barakka)

            Hi!

            thanks for the replay. I've read the post you suggested and the one that was pointed by that one. I had already explored this topics and read everything I could find on the internet about the jboss classloader, loader repository, etc.

            The problem, however, is not related to hibernate search being moved. The class cast exception that I get are basic hibernate classes, like Session, etc.

            What I've been able to dig out is that the ejb3.deployer and my ear use two separate classloader, with the one used by the ejb3.deployer loading the lib from the the server folder and the one for my app reading the lib from my ear.

            In fact, if you take the issue to its extreme and suppose that the server does not provide any hibernate lib, the ejb3.deployer will not work at all, as it can't find the hibernate classes needed to create the persistence manager factory (declared in my ear persistence.xml). And I believe this behaviour is not the correct one: the deployer should use the ear classloader.

            I'm now wondering if I can define the ejb.deployer service within my ear directly, so it will use its classloader.

            Thanks,
            Riccardo.

              • Actions
            • 3. Re: ejb3.deployer does not have access to ear scoped loader
              jaikiran
              jaikiran Feb 22, 2009 2:43 AM (in response to barakka)

               

              "barakka" wrote:

              The problem, however, is not related to hibernate search being moved. The class cast exception that I get are basic hibernate classes, like Session, etc.

              That can happen if your application is not scoped correctly or you do not have the right set (or a complete set) of hibernate jars.

              "barakka" wrote:

              What I've been able to dig out is that the ejb3.deployer and my ear use two separate classloader, with the one used by the ejb3.deployer loading the lib from the the server folder and the one for my app reading the lib from my ear.

              That's the correct behaviour.

              "barakka" wrote:

              In fact, if you take the issue to its extreme and suppose that the server does not provide any hibernate lib, the ejb3.deployer will not work at all, as it can't find the hibernate classes needed to create the persistence manager factory

              That's the very reason why the hibernate libraries are provided by the AS.

              "barakka" wrote:

              And I believe this behaviour is not the correct one: the deployer should use the ear classloader.
              I'm now wondering if I can define the ejb.deployer service within my ear directly, so it will use its classloader.


              From your description, i would again say that the application is not correctly scoped :) So the best way to debug this is to provide more details about your application including logs and your application packaging.

              Post the output of 

              jar -tf yourapp.ear


              Also post the contents of application.xml and jboss-app.xml (in which the classloader configuration is done).
              The other important part would be the TRACE level logs from the org.jboss.classloading package. But let's first check the other details that i asked for before looking at the those TRACE logs (which will be too long to post here).


                • Actions