[jboss-as7-dev] Loading of System Resources Broken in JBoss AS 7 Final but worked in JBoss AS 7 Beta 3 - Workaround?

[William Louth (JINSPIRED.COM)]

Carlo,

The code did already handle this before the change was committed.

I know because in Beta3 we could not get classes or resources to load 
from the classpath unless the system.pkgs was set correctly.

Not sure what triggered the change when it was correct the first time in 
terms of behavior though maybe not obvious the inheritance construct.

https://github.com/jbossas/jboss-modules/blob/master/src/main/java/org/jboss/modules/ConcurrentClassLoader.java

public final URL getResource(final String name) {
         for (String s : Module.systemPaths) {
             if (name.startsWith(s)) {
                 return super.getResource(name); // this uses the parent 
if it is set
             }
         }
         return findResource(name, false); // this returns null unless 
overridden by extension
     }

public final Enumeration<URL> getResources(final String name) throws 
IOException {
         for (String s : Module.systemPaths) {
             if (name.startsWith(s)) {
                 return super.getResources(name); // this uses the 
parent if it is set
             }
         }
         return findResources(name, false);
     }

On 14/07/2011 23:47, Carlo de Wolf wrote:
> On 07/14/2011 10:16 PM, Jason T. Greene wrote:
>> On 7/14/11 1:37 PM, William Louth (JINSPIRED.COM) wrote:
>>> The label associated with this change which broke things is ominous 
>>> enough:
>>>
>>> MODULES-89: make sure ModuleClassLoader lives in complete isolation and
>>> use package name to load package spec
>>> https://github.com/jbossas/jboss-modules/commit/2046885497316d66ca0682b4a83fe8fad4cb0ccc#src/main/java/org/jboss/modules/ModuleClassLoader.java 
>>>
>> This patch is wrong, it shouldn't have been merged. I'll revert that
>> portion.
>>
>>> If you are going to do it like this then at least change the
>>> ModuleClassLoader or ConcurrentClassLoader to properly implement 
>>> support
>>> for loading resources from Module.systemPaths though I would question
>>> this default and non-configurable behavior. Pain lies this way for sure
>>> and any benefit (fast start-up)&   goodwill (hey you are modular) you
>>> think you have achieved with this will evaporate in seconds when things
>>> just don't work. I know from experience.
>> We only want one configuration, the one that works :)
>>
>> Note that this issue is limited to resource loading with elements on
>> systemPaths. Reverting that patch will have no effect on performance or
>> modularity, it will just fix the bug.
>>
> The patch is correct. The contents of a module must not be polluted by 
> anything on the class path, only stuff from jboss.modules.system.pkgs 
> may creep in. So somewhere therein lies the problem.
>
> How do you load those resources from the class loader?
> Do you have a code snippet?
>
> Carlo
>
>