5 Replies Latest reply on Nov 27, 2009 12:09 PM by null null

    Classloader bug with java2parentdelegation in JBoss 5.x?

    null null Newbie

      Hi,
      I tested the following using JBoss 4.2.2.GA. I deployed some utility classes in server/default/lib and also in my application configured with java2parentdelegation=true. The application has a scoped loader repository. In fact, the classes stored in lib are only used, if they were loaded to the default UnifiedLoaderRepository before. This behaviour is exactly as described in the classloader wiki. BUT! If I test the same szenario with JBoss 5.1.0.GA, there is a strage thing happening: If the class was not loaded to the standard UnifiedLoaderRepository before, it is loaded into it now and used.
      If I understood the class loading model right, this is a contradiction to the java2parentdelegation flag, wich means that classes from the standard repository are only used in scoped applications, if they were loaded to the standard repository before. In any other case the scoped application has to load the classes itself.

      What do you experts think?

        • 1. Re: Classloader bug with java2parentdelegation in JBoss 5.x?
          jaikiran pai Master

          Please post your exact config files.

          While posting logs or xml content or code, please remember to wrap it in a code block by using the Code button in the message editor window. Please use the Preview button to ensure that your post is correctly formatted.

          • 2. Re: Classloader bug with java2parentdelegation in JBoss 5.x?
            null null Newbie

            Well, there isn't much to post. :-) I tested this scenario with a simple 1-annotation session bean, that loads a customer from its jar file. There is no ejb-jar.xml, just a jboss.xml to configure the scoping and the parent delegation:

            <jboss>
             <loader-repository>loaderrep:loader=Apploader
             <loader-repository-config>java2ParentDelegation=true</loader-repository-config>
             </loader-repository>
            </jboss>
            


            I placed a second version of the customer in server/default/lib. Both customers simply log a version number to the console to distinguish them...

            Thats all...

            • 3. Re: Classloader bug with java2parentdelegation in JBoss 5.x?
              jaikiran pai Master

              My understanding of java2ParentDelegation is to control the parent-first or parent-last behaviour. So if you have set java2ParentDelegation=true, then if the class is not already loaded, then it will always ask the parent first to load the class. And since in your case, the parent is capable of loading that class (from server/default/lib), it will always be loaded from the jars there.

              • 4. Re: Classloader bug with java2parentdelegation in JBoss 5.x?
                null null Newbie

                Yes, but if this wiki http://www.jboss.org/community/wiki/JbossClassLoadingUseCases is correct, then ehe "parent" meant in this setting is the loader repository, not the loader itself. The article shows that in a scoped repository the java2ParentDelegation is off by default, wich means that the parent loader repository is never asked for the class. So the scoped repository has to load it by itself or - if this fails - has to ask the parent class loader (NoAnnotationURLClassLoader). If you switch java2ParentDelegation on, the parent repository is asked first if it has the class already loaded but does NOT load it itself. And that`s exactly how JBoss 4.2.2.GA behaves. In my opinion, the parent repository is never allowed to load classes for a scoped repository. Did I get anything wrong?[/url]

                • 5. Re: Classloader bug with java2parentdelegation in JBoss 5.x?
                  null null Newbie

                  Sorry for the trashy posting. Once again:
                  Yes, but if this wiki http://www.jboss.org/community/wiki/JbossClassLoadingUseCases is correct, then ehe "parent" meant in this setting is the loader repository, not the loader itself. The article shows that in a scoped repository the java2ParentDelegation is off by default, wich means that the parent loader repository is never asked for the class. So the scoped repository has to load it by itself or - if this fails - has to ask the parent class loader (NoAnnotationURLClassLoader). If you switch java2ParentDelegation on, the parent repository is asked first if it has the class already loaded but does NOT load it itself. And that`s exactly how JBoss 4.2.2.GA behaves. In my opinion, the parent repository is never allowed to load classes for a scoped repository. Did I get anything wrong?