1 2 Previous Next 18 Replies Latest reply on Sep 29, 2008 11:57 AM by Ales Justin

    JBAS-5895; Processing too many classes

    Ales Justin Master

      https://jira.jboss.org/jira/browse/JBAS-5895

      This looks like a problem of EARStructure
      not explicitly excluding ear's lib directory?

      I cannot find library-directory element as part of EarMetaData:
      - http://anonsvn.jboss.org/repos/jbossas/projects/metadata/trunk/src/main/java/org/jboss/metadata/ear/spec/EarMetaData.java
      So this might be a reason why it wasn't excluded - you put the element in spec file.
      But on the other hand I see this in EARStructure:

       // Add the ear lib contents to the classpath
       String libDir = appMetaData.getLibraryDirectory() == null ? "lib" : appMetaData.getLibraryDirectory();
      

      Hence if emtpy library-directory is parsed as null,
      then we would always get lib as default.


        • 1. Re: JBAS-5895; Processing too many classes
          Emanuel Muckenhuber Master

           

          "alesj" wrote:

          I cannot find library-directory element as part of EarMetaData:
          - http://anonsvn.jboss.org/repos/jbossas/projects/metadata/trunk/src/main/java/org/jboss/metadata/ear/spec/EarMetaData.java
          So this might be a reason why it wasn't excluded - you put the element in spec file.

          Well it's in the Ear5xMetaData:
          http://anonsvn.jboss.org/repos/jbossas/projects/metadata/trunk/src/main/java/org/jboss/metadata/ear/spec/Ear5xMetaData.java

          "alesj" wrote:

          Hence if emtpy library-directory is parsed as null,
          then we would always get lib as default.


          From what i've seen it should be parsed to an empty String. So libDir in this case would be "". If that helps you a bit :)

          • 2. Re: JBAS-5895; Processing too many classes
            Ales Justin Master

             

            "emuckenhuber" wrote:

            From what i've seen it should be parsed to an empty String. So libDir in this case would be "". If that helps you a bit :)

            How does this play with ear's lib?
            Afaik in this case it would pick up every jar that's in ear's root?
            Which is definitely wrong. ;-)

            • 3. Re: JBAS-5895; Processing too many classes
              Scott Stark Master

              Right, I believe this is what is happening. Classes end up not being found from the lib directory because the package name is wrong, but there should not be any root content in the classpath of the ear if the lib dir is empty as opposed to null. We need to check for an empty lib and skip it.

              • 4. Re: JBAS-5895; Processing too many classes
                Ales Justin Master

                OK, this is the actual cause of the problem.

                In EARStructure we have by default includeEarRootInClasspath = true.
                Hence the root is added to classpath.
                Skipping lib in classpath doesn't help here.

                It's the VFSDeploymentClassLoaderPolicyModule::visit that picks up
                classes in EAR-ROOT/lib/shared.jar since root is in the classpath.
                While visiting root as part of classpath it finds com.sun.ts.tests.ejb30.assembly.librarydirectory.disable.AssemblyBean as a resource: lib.shared.jar.com.sun.ts.tests.ejb30.assembly.librarydirectory.disable.AssemblyBean
                But I use javassist to give me classname, hence the name is real classname, not full resource name (including prefix lib.shared.jar).
                So, when it tries to load the class, it cannot find it - as it should be - since lib/shared.jar is not part of the classpath.

                What should be a proper/good fix for this?

                We have bunch of filters we could use.
                We need to allow only visibility of plain resource files from ear's root,
                e.g. some old .properties or legacy .xml,
                but definitely not directories.

                • 5. Re: JBAS-5895; Processing too many classes
                  Ales Justin Master

                   

                  "alesj" wrote:

                  We have bunch of filters we could use.
                  We need to allow only visibility of plain resource files from ear's root,
                  e.g. some old .properties or legacy .xml,
                  but definitely not directories.

                  This should be applied to ear's Module somehow.

                  • 6. Re: JBAS-5895; Processing too many classes
                    Scott Stark Master

                     

                    "alesj" wrote:

                    What should be a proper/good fix for this?

                    We have bunch of filters we could use.
                    We need to allow only visibility of plain resource files from ear's root,
                    e.g. some old .properties or legacy .xml,
                    but definitely not directories.

                    The only reasonable filter is to exclude the "lib" child contents as that is the default ear lib directory name. If someone has a custom ear libx child, but excludes the directory via metadata, then would also have to disable the include root option as well.


                    • 7. Re: JBAS-5895; Processing too many classes
                      Ales Justin Master

                       

                      "scott.stark@jboss.org" wrote:
                      If someone has a custom ear libx child, but excludes the directory via metadata, then would also have to disable the include root option as well.

                      Why?
                      Or why is this different from if (s)he has plain lib child?

                      e.g. you don't want lib to be part of classpath,
                      but you still want to find xyz.properties file in ear's root as part of classpath

                      The problem I see for me is that in the deployers that are Module aware
                      don't know if underlying deployment unit is top ear deployment unit,
                      since it's only structure deployers that understand ear (war, jar, ...),
                      but they don't have a clue about Module.

                      • 8. Re: JBAS-5895; Processing too many classes
                        Ales Justin Master

                         

                        "alesj" wrote:

                        The problem I see for me is that in the deployers that are Module aware
                        don't know if underlying deployment unit is top ear deployment unit,
                        since it's only structure deployers that understand ear (war, jar, ...),
                        but they don't have a clue about Module.

                        What about if I add a predetermined attachment to ear's top
                        deployment context and then grab it out in one of the deployers
                        that's just in between from Module-creating-deployer and AnnotationScanningDeployer?
                        e.g. if the attachment is there, then it means this deployment unit
                        is ear top deployment unit, hence apply root Module filter
                        Or too much of a hack? :-)

                        • 9. Re: JBAS-5895; Processing too many classes
                          Scott Stark Master

                           

                          "alesj" wrote:
                          "scott.stark@jboss.org" wrote:
                          If someone has a custom ear libx child, but excludes the directory via metadata, then would also have to disable the include root option as well.

                          Why?
                          Or why is this different from if (s)he has plain lib child?

                          Because there is no basis to identify libx as a lib directory that was excluded. In the metadata you either specify the lib directory or an empty name to indicate there is no lib directory. If there is no directory name, its assumed to be "lib". There is no way to say exclude libx as a lib directory other than reverting to jboss structure metadata.

                          "alesj" wrote:

                          The problem I see for me is that in the deployers that are Module aware
                          don't know if underlying deployment unit is top ear deployment unit,
                          since it's only structure deployers that understand ear (war, jar, ...),
                          but they don't have a clue about Module.

                          What about if I add a predetermined attachment to ear's top
                          deployment context and then grab it out in one of the deployers
                          that's just in between from Module-creating-deployer and AnnotationScanningDeployer?
                          e.g. if the attachment is there, then it means this deployment unit
                          is ear top deployment unit, hence apply root Module filter
                          Or too much of a hack? :-)

                          This is too much of a hack, and what I'm saying is that if someone wants an ear to include the root, but exclude non-standard lib directory, they have to use jboss specific metadata to do so. The only child location we can exclude when an empty library-directory is specific is "lib".


                          • 10. Re: JBAS-5895; Processing too many classes
                            Ales Justin Master

                             

                            "scott.stark@jboss.org" wrote:
                            The only child location we can exclude when an empty library-directory is specific is "lib".

                            Makes sense.
                            But, like I said, we have parts of info in different places,
                            empty-dir lib in EarStructure and Module filter in some real deployer.
                            The only thing that I can think of, that binds them, is my hack. :-)

                            • 11. Re: JBAS-5895; Processing too many classes
                              Scott Stark Master

                              I'll have to look into why that is. I thought there was an excluded notion added to the classpath so you have have a number of roots, and exclusions to further restrict what gets added. What we need out of the structure phase are the classpath roots + inclusion/exclusion filters.

                              • 12. Re: JBAS-5895; Processing too many classes
                                Adrian Brock Master

                                I'm not understanding this issue.

                                The VFSResourceVisitor should already exclude other roots
                                if they are nested within another root.

                                See VFSResourceVisitor.accepts()

                                 // This is our current root
                                 if (file.equals(root))
                                 return true;
                                
                                 // Some other root, it will be handled later
                                 for (VirtualFile other : roots)
                                 {
                                 if (file.equals(other))
                                 return false;
                                 }
                                


                                • 13. Re: JBAS-5895; Processing too many classes
                                  Ales Justin Master

                                   

                                  "adrian@jboss.org" wrote:

                                  The VFSResourceVisitor should already exclude other roots
                                  if they are nested within another root.

                                  It does.

                                  It's an issue when lib is not part of classpath / roots,
                                  e.g. explicitly excluded with library-directory application.xml element.

                                  Then VRVisitor still visits lib directory, picking up annotated classes,
                                  although when we declared ear's root as classpath entry,
                                  we probably only wanted to do that to pick some .properties / .xml resources,
                                  not excluded lib's jars.

                                  • 14. Re: JBAS-5895; Processing too many classes
                                    Adrian Brock Master

                                    Ok. so the solutions seems obvious to me.
                                    I don't see the point of trying to fix a hack with another hack.

                                    The original problem comes about because the old UCL added the root of
                                    the ear to the classpath. This was a mistake, and was only done for debugging
                                    purposes, i.e. to print the ear url in the toString() of the classloader.

                                    We still do it for backwards compatiblity purposes, but now it is causing problems
                                    for the annotation scanning.

                                    So why don't we just turn it off?

                                    If somebody really wants the old behaviour they can enable it.
                                    But since it is not portable behaviour, it would be better for them to fix the packaging
                                    anyway.

                                    1 2 Previous Next