7 Replies Latest reply on Feb 6, 2009 6:27 AM by adrian.brock

    Too strict pattern matching in PackageClassFilter

    alesj

      While fixing this issue:
      - https://jira.jboss.org/jira/browse/JBCL-32
      I came across package matching issue with the following config:

      Part of my path:
      ClassLoaderUtils.packageNameToPath(A.class.getName()) --> org/jboss/test/classloading/dependency/support/a

      My include filter:
      new PackageClassFilter(new String[]{A.class.getPackage().getName()}) --> org/jboss/test/classloading/dependency/support/a/[^/]+

      Result: filter on package doesn't pick up package itself.

      There are two issues:
      1) the last / in pattern --> should be made optional
      2) + in pattern --> should be *

        • 1. Re: Too strict pattern matching in PackageClassFilter
          alesj

           

          "alesj" wrote:
          Result: filter on package doesn't pick up package itself.

          Or is this intentional?

          Since I see class name matching behave this way:
           public void testJavaLang() throws Exception
           {
           ClassFilter filter = PackageClassFilter.createPackageClassFilter("java.lang");
           assertFilterMatchesClassName("java.lang.Object", filter);
           assertFilterMatchesClassName("java.lang.X", filter);
           assertFilterNoMatchClassName("java.lang", filter);
           assertFilterNoMatchClassName("java.lang.", filter);
          


          • 2. Re: Too strict pattern matching in PackageClassFilter
            alesj

             

            "alesj" wrote:

            Or is this intentional?

            I put back previous behavior
            and fixed the test to work accordingly.


            • 3. Re: Too strict pattern matching in PackageClassFilter
              jaikiran

              Posting here in continuation to this thread in the user forum http://www.jboss.com/index.html?module=bb&op=viewtopic&t=149468#4207208. Other than this there are some more users (of JBossAS5.0 GA) who have reported that the package filtering isn't working as expected.

              A bit of background:

              * The WAR deployer allows (and used to allow in JBossAS4.x) a "filteredPackages".

              <property name="filteredPackages">javax.servlet,org.apache.commons.logging</property>
              


              This configuration would ensure that if the user had packaged a jar containing any classes belonging to javax.servlet.* package (and child packages), then those classes would be filtered/ignored.

              * In 5.0 GA, users have reported that this doesn't work anymore. The forum thread has more details. As explained in that thread, the PackageClassFilter is not filtering child packages. For ex: If the user had filteredPackages = javax.servlet then the PackageClassFilter filters only classes belonging to javax.servlet but not the ones in javax.servlet.http. In my opinion, the PackageClassFilter regex needs to be changed to allow this (there's a patch in the other forum thread). This would allow users to add a filter on the top most package and not worry about any child packages.

              * The comments on the original version of that class made me believe that the current behaviour was intended (though i don't know the reason).



              • 4. Re: Too strict pattern matching in PackageClassFilter
                starksm64

                That looks to be by design. We should have a RecursivePackageClassFilter or allow package wildcards like javax.servlet.* to indicate the javax.servlet package or any of its subpackages.

                I think the single package interpretation is consistent with the osgi bundle class loader behavior, so we would have to have an extension to that.

                I'll have to look at how the filteredPackages information is incorporated into the class loader model because it could simply be that is where the behavior could be extended.

                • 5. Re: Too strict pattern matching in PackageClassFilter

                   

                  "scott.stark@jboss.org" wrote:
                  That looks to be by design. We should have a RecursivePackageClassFilter or allow package wildcards like javax.servlet.* to indicate the javax.servlet package or any of its subpackages.


                  Yes. Obviously the semantics of filteredPackages on the WarClassLoaderDeployer
                  is different to ClassLoadingMetaData's excludedPackages.
                  i.e. it is recursive rather than an explicit list of packages


                  I'll have to look at how the filteredPackages information is incorporated into the class loader model because it could simply be that is where the behavior could be extended.


                  The WarClassLoaderDeployer simply sets the list of explicit packages to exclude.
                  classLoadingMetaData.setExcludedPackages(filteredPackages);

                  A simple fix would be to use the option to set the filter directly.
                  classLoadingMetaData.setExcluded(new RecursivePackageFilter(filteredPackages));

                  except that no such ClassFilter implementation currently exists.

                  It should be easy to create one by copying the PackageClassFilter
                  but change it to use the regular expressions like those in the JavaOnlyClassFilter.

                  • 6. Re: Too strict pattern matching in PackageClassFilter
                    • 7. Re: Too strict pattern matching in PackageClassFilter

                      I also created this feature request since we discussed how this should really work
                      before:

                      https://jira.jboss.org/jira/browse/JBCL-84