4 Replies Latest reply on Aug 7, 2007 10:17 AM by alesj

    ContextSingletonBeanFactoryLocator and classloaders

    lucdew

      Hi,

      I have problems using SingletonBeanFactoryLocator and classloader issues.
      Actually,

      My application is packaged like this:

      myapp.ear
      --> spring.jar
      --> mysar.sar
      --> myjar.jar

      My sar performs initialization tasks and one of them is to initialize spring contexts with the following code:

      BeanFactoryLocator sbf = ContextSingletonBeanFactoryLocator.getInstance();
      BeanFactoryReference bf = sbf.useBeanFactory("common.context");


      The problems is that Spring the common.context bean is not found and i figured out why it's because Spring can not find the beanRefContext.xml file which holds the bean definition because it uses a wrong classloader

      I declared spring.jar and myjar.jar in application.xml as Java modules (ex: spring.jar)

      In mysar.sar i displayed information of the current classloader and here's what i get:


      11:58:54,765 INFO [DeployerListenerService] Current classloader = org.jboss.mx.
      loading.UnifiedClassLoader3@10d16b{ url=file:/D:/applications/jboss-4.0.
      5.GA/server/default/deploy/myapp.ear/ ,addedOrder=40}




      and if i execute the following code:

      Enumeration<URL> resourcesEnum = this.getClass().getClassLoader().getResources("beanRefContext.xml");




      the classloader find the resource beanRefContext.xml which is packaged in myjar.jar. It works as expected.

      The problem is Spring library executes almost the same code in the PathMatchingResourcePatternResolver class it executes:
      Code:

      Enumeration resourceUrls = getClassLoader().getResources(path);



      where path is "beanRefContext.xml"
      and the getClassLoader() returned in debug mode has a path attribute of:

      /D:/applications/jboss-4.0.5.GA/server/default/conf/



      and therefore is unable to see the beanRefContext.xml file packaged in my ear.

      Note that i configured in my ear a loader repository :
      Code:

      <loader-repository>
       test.com:loader=myapp
      </loader-repository>
      



      I don't understand why the classloader retrieved in Spring is the one associated with the universalrepository3 ? and not the HeirarchicalLoaderRepository3 of my ear???

      I checked the CLASSPATH and my Jboss installation to see if there were Spring classes elsewhere and no the only Spring classes are in the spring.jar of myapp.ear.

      Please i need help.

        • 1. Re: ContextSingletonBeanFactoryLocator and classloaders
          lucdew

          I have just found out that Spring uses the following code to retrieve the classloader:

          Thread.currentThread().getContextClassLoader()


          and the classloader returned by this piece of code is a UCL (/D:/applications/jboss-4.0.5.GA/server/default/conf/) tied to the universalrepository3 and not the HeirarchicalLoaderRepository3 of my ear.

          Of course, since Jboss created the threads i guess that it's normal that the classloader associated to the thread can not be a classloader that will use the HeirarchicalLoaderRepository3.

          But i still don't have any solution on this problem. Is it possible to configure the threads created by Jboss to make them return the classloader of the ear ?

          • 2. Re: ContextSingletonBeanFactoryLocator and classloaders
            alesj

            This issue isn't tied to actual JBoss/Spring integration project (see Sticky post), so it will be eventually removed (or moved to some appropriate forum ... if I find one).

            • 3. Re: ContextSingletonBeanFactoryLocator and classloaders
              lucdew

              Sorry for that i thought the forum dealt with general Spring and jboss integration issue and not only to Spring jboss deployer.

              • 4. Re: ContextSingletonBeanFactoryLocator and classloaders
                alesj

                 

                "lucdew" wrote:
                Sorry for that i thought the forum dealt with general Spring and jboss integration issue and not only to Spring jboss deployer.

                NP.
                This is Spring's issue, since they should adapt to JBoss specific features, and not the other way around.
                After all, it is Spring who gets deployed into JBoss. ;-)

                Perhaps they should also introduce a new vendor specific hook there - like they do it for JNDI, Transactions, ...?