[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)]

Its picking up the resources but now classes within the javaagent 
library are being hidden from the module.

java.lang.ClassNotFoundException: 
com.jinspired.jxinsight.server.ext.aspectj.MessageHandler from [Module 
"org.jboss.logmanager:main" from local module loader @463620de (roots: 
/Applications/jboss-as-web-7.0.0.Final/modules)]
     at 
org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
     at 
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:359)
     at 
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:331)
     at 
org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:308)
     at 
org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:102)
     at java.lang.Class.forName0(Native Method)
     at java.lang.Class.forName(Class.java:247)
     ......
    at 
sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:365)
     at java.lang.ClassLoader.defineClass1(Native Method)
     at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
     at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
     at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
     at 
org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:397)
     at 
org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261)
     at 
org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76)
     at org.jboss.modules.Module.loadModuleClass(Module.java:588)
     at 
org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:183)
     at 
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:359)
     at 
org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:308)
     at 
org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:102)
     at java.util.logging.LogManager$1.run(LogManager.java:166)
     at java.security.AccessController.doPrivileged(Native Method)
     at java.util.logging.LogManager.<clinit>(LogManager.java:156)
     at org.jboss.modules.Main.main(Main.java:274)

[ModuleClassLoader at 2324279c] warning define generated class failed -- 
(NoClassDefFoundError) 
com/jinspired/jxinsight/probes/ext/aspectj/DynamicProbeAspect
com/jinspired/jxinsight/probes/ext/aspectj/DynamicProbeAspect
java.lang.NoClassDefFoundError: 
com/jinspired/jxinsight/probes/ext/aspectj/DynamicProbeAspect
     at java.lang.ClassLoader.defineClass1(Native Method)


On 15/07/2011 00:25, Carlo de Wolf wrote:
> https://issues.jboss.org/browse/MODULES-93
> and https://github.com/wolfc/jboss-modules/tree/MODULES-93
>
> Can you give it a pin with jxinsight?
>
> Carlo
>
> On 07/15/2011 12:07 AM, Carlo de Wolf wrote:
>> I was actually hoping from a code snippet from your end. :-)
>>
>> But yes, now that I see those two methods, those appear to be wrong. 
>> They should delegate to getSystemResource(s).
>>
>> Carlo
>>
>> On 07/14/2011 11:58 PM, William Louth (JINSPIRED.COM) wrote:
>>> 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
>>>>
>>>>
>>
>
>
>