0 Replies Latest reply on Mar 8, 2010 10:34 AM by adrian.brock

    ClassLoader ease-of-use again

      There were a couple of tests in deployers-vfs that were using the export-all flag wrongly.

       

      They had something like:

       

      <classloading xmlns="urn:jboss:classloading:1.0" export-all="NON_EMPTY">
         <capabilities>
            <module name="test3"/>
         </capabilities>
      </classloading>

       

      Since the capabilities have been explicitly declared, the export-all should have been ignored,

      but apparently it was not.

       

      This was actually due to the Module asking the ClassLoaderPolicy for its exported()

      delegate which does know about the capabilities filtering.

       

      I've just changed this code so that it correctly uses the Module.determinePackages()

      to decide what should be in the exported classes filter.

       

      Accordingly, I had to fix the tests to declare they had the package capability:

       

      <classloading xmlns="urn:jboss:classloading:1.0">
          <capabilities>
             <module name="test3"/>
             <package name="a.b.c"/>
          </capabilities>
      </classloading>

       

      When I first did this, I suggested that we might be able to support

      the export-all flag even if capabilities are specified, e.g. if there

      are no explicit packages then we use the export-all rule.

       

      But if we are going to support it, it should be done properly, not

      leaking in because of a bug. ;-)