Loading of System Resources Broken in JBoss AS 7 Final but worked in JBoss AS 7 Beta 3 - Workaround?

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Loading of System Resources Broken in JBoss AS 7 Final but worked in JBoss AS 7 Beta 3 - Workaround?

William Louth (JINSPIRED.COM)
JBOSS AS 7 BETA 3 - WORKED WITH SYSTEM.PKGS PROPERTY

./standalone.sh
=========================================================================

  JBoss Bootstrap Environment
  JBOSS_HOME: /Applications/jboss-7.0.0
  JAVA: java
  JAVA_OPTS: -Xms64m -Xmx512m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -agentpath:/OpenCore/bin/os-32/libjxinsight.jnilib=prod -javaagent:/OpenCore/bundle/java/default/opencore-ext-aj-javaagent.jar -Djboss.modules.system.pkgs=com.jinspired,org.jinspired -Djxinsight.server.aspectj.messagehandler.enabled=true

=========================================================================

[jxiagent] build number 1121
[jxiagent] development-only edition
[jxiagent] license key is: 7040D5C572HX37VX2UX107863A5E38T
[jxinsight] JXInsight/OpenCore AspectJ (load-time) Weaver Loaded
[jxinsight] loading configuration file [jxinsight.aspectj.filters.config] from directory /Applications/jboss-7.0.0/bin
loading resources for classloader sun.misc.Launcher$AppClassLoader@8dc8569
 resources for classloader [jar:file:/Applications/OpenCore/bundle/java/default/opencore-ext-aj-javaagent.jar!/com/jinspired/jxinsight/ext/aspectj/aop.xml, jar:file:/Applications/OpenCore/bundle/java/default/opencore-ext-aj-javaagent.jar!/com/jinspired/jxinsight/probes/ext/aspectj/aop.xml]
[jxinsight] loading properties config file [/Applications/jboss-7.0.0/bin/jxinsight.override.config]
[jxinsight] installing console probes provider
[jxinsight] installing strategy probes provider
[jxinsight] failed to open server socket port [1515] because it is already bound.
[jxinsight] will attempt to bind to additional server socket ports.
[jxinsight] probes console reactor-acceptor is listening on william-louths-macbook-pro.local[10.0.1.7]:1516
loading resources for classloader ModuleClassLoader for Module "org.jboss.logmanager:main" from local module loader @1ccb457c (roots: /Applications/jboss-7.0.0/modules)
 resources for classloader [jar:file:/Applications/OpenCore/bundle/java/default/opencore-ext-aj-javaagent.jar!/com/jinspired/jxinsight/ext/aspectj/aop.xml, jar:file:/Applications/OpenCore/bundle/java/default/opencore-ext-aj-javaagent.jar!/com/jinspired/jxinsight/probes/ext/aspectj/aop.xml]
23:29:45,351 INFO  [org.jboss.modules] JBoss Modules version 1.0.0.Beta17
loading resources for classloader ModuleClassLoader for Module "org.codehaus.woodstox:main" from local module loader @1ccb457c (roots: /Applications/jboss-7.0.0/modules)
 resources for classloader [jar:file:/Applications/OpenCore/bundle/java/default/opencore-ext-aj-javaagent.jar!/com/jinspired/jxinsight/ext/aspectj/aop.xml, jar:file:/Applications/OpenCore/bundle/java/default/opencore-ext-aj-javaagent.jar!/com/jinspired/jxinsight/probes/ext/aspectj/aop.xml]
loading resources for classloader ModuleClassLoader for Module "org.apache.xalan:main" from local module loader @1ccb457c (roots: /Applications/jboss-7.0.0/modules)
 resources for classloader [jar:file:/Applications/OpenCore/bundle/java/default/opencore-ext-aj-javaagent.jar!/com/jinspired/jxinsight/ext/aspectj/aop.xml, jar:file:/Applications/OpenCore/bundle/java/default/opencore-ext-aj-javaagent.jar!/com/jinspired/jxinsight/probes/ext/aspectj/aop.xml]
loading resources for classloader ModuleClassLoader for Module "org.jboss.as.server:main" from local module loader @1ccb457c (roots: /Applications/jboss-7.0.0/modules)
 resources for classloader [jar:file:/Applications/OpenCore/bundle/java/default/opencore-ext-aj-javaagent.jar!/com/jinspired/jxinsight/ext/aspectj/aop.xml, jar:file:/Applications/OpenCore/bundle/java/default/opencore-ext-aj-javaagent.jar!/com/jinspired/jxinsight/probes/ext/aspectj/aop.xml]
loading resources for classloader ModuleClassLoader for Module "org.jboss.stdio:main" from local module loader @1ccb457c (roots: /Applications/jboss-7.0.0/modules)
 resources for classloader [jar:file:/Applications/OpenCore/bundle/java/default/opencore-ext-aj-javaagent.jar!/com/jinspired/jxinsight/ext/aspectj/aop.xml, jar:file:/Applications/OpenCore/bundle/java/default/opencore-ext-aj-javaagent.jar!/com/jinspired/jxinsight/probes/ext/aspectj/aop.xml]
loading resources for classloader ModuleClassLoader for Module "org.jboss.logmanager.log4j:main" from local module loader @1ccb457c (roots: /Applications/jboss-7.0.0/modules)
 resources for classloader [jar:file:/Applications/OpenCore/bundle/java/default/opencore-ext-aj-javaagent.jar!/com/jinspired/jxinsight/ext/aspectj/aop.xml, jar:file:/Applications/OpenCore/bundle/java/default/opencore-ext-aj-javaagent.jar!/com/jinspired/jxinsight/probes/ext/aspectj/aop.xml]
loading resources for classloader ModuleClassLoader for Module "org.apache.log4j:main" from local module loader @1ccb457c (roots: /Applications/jboss-7.0.0/modules)
 resources for classloader [jar:file:/Applications/OpenCore/bundle/java/default/opencore-ext-aj-javaagent.jar!/com/jinspired/jxinsight/ext/aspectj/aop.xml, jar:file:/Applications/OpenCore/bundle/java/default/opencore-ext-aj-javaagent.jar!/com/jinspired/jxinsight/probes/ext/aspectj/aop.xml]
....

JBOSS AS 7 FINAL - DOES NOT WORK, SEES NONE OF THE RESOURCES EXCEPT FOR THE LAUNCHER

[jxinsight] probes console reactor-acceptor is listening on william-louths-macbook-pro.local[10.0.1.7]:1515
loading resources for classloader ModuleClassLoader for Module "org.jboss.logmanager:main" from local module loader @6571120a (roots: /Applications/jboss-as-web-7.0.0.Final/modules)
 resources for classloader []
23:59:55,404 INFO  [org.jboss.modules] JBoss Modules version 1.0.1.GA
loading resources for classloader ModuleClassLoader for Module "org.apache.xerces:main" from local module loader @6571120a (roots: /Applications/jboss-as-web-7.0.0.Final/modules)
 resources for classloader []
loading resources for classloader ModuleClassLoader for Module "org.codehaus.woodstox:main" from local module loader @6571120a (roots: /Applications/jboss-as-web-7.0.0.Final/modules)
 resources for classloader []
loading resources for classloader ModuleClassLoader for Module "org.apache.xalan:main" from local module loader @6571120a (roots: /Applications/jboss-as-web-7.0.0.Final/modules)
 resources for classloader []
loading resources for classloader ModuleClassLoader for Module "org.jboss.as.server:main" from local module loader @6571120a (roots: /Applications/jboss-as-web-7.0.0.Final/modules)
 resources for classloader []
loading resources for classloader ModuleClassLoader for Module "org.jboss.stdio:main" from local module loader @6571120a (roots: /Applications/jboss-as-web-7.0.0.Final/modules)
 resources for classloader []
loading resources for classloader ModuleClassLoader for Module "org.jboss.logmanager.log4j:main" from local module loader @6571120a (roots: /Applications/jboss-as-web-7.0.0.Final/modules)
 resources for classloader []
loading resources for classloader ModuleClassLoader for Module "org.apache.log4j:main" from local module loader @6571120a (roots: /Applications/jboss-as-web-7.0.0.Final/modules)
 resources for classloader []
23:59:55,902 INFO  [stdout] loading resources for classloader ModuleClassLoader for Module "org.jboss.logging:main" from local module loader @6571120a (roots: /Applications/jboss-as-web-7.0.0.Final/modules)
23:59:55,903 INFO  [stdout]  resources for classloader []
23:59:55,910 INFO  [stdout] loading resources for classloader ModuleClassLoader for Module "org.jboss.as.controller:main" from local module loader





_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Loading of System Resources Broken in JBoss AS 7 Final but worked in JBoss AS 7 Beta 3 - Workaround?

David Lloyd-2
On 07/13/2011 05:01 PM, William Louth (JINSPIRED.COM) wrote:
> JBOSS AS 7 FINAL - DOES NOT WORK, SEES NONE OF THE RESOURCES EXCEPT FOR
> THE LAUNCHER

What resources is it not finding?  Do you have any log messages which
illustrates the problem?

--
- DML
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Loading of System Resources Broken in JBoss AS 7 Final but worked in JBoss AS 7 Beta 3 - Workaround?

William Louth (JINSPIRED.COM)
Hi David,

It was actually listed in my original email posted (truncated?). Here is a snippet.

JBoss AS7 Beta 3

loading resources for classloader ModuleClassLoader for Module "org.apache.xalan:main" from local module loader @1ccb457c (roots: /Applications/jboss-7.0.0/modules)
 resources for classloader [jar:file:/Applications/OpenCore/bundle/java/default/opencore-ext-aj-javaagent.jar!/com/jinspired/jxinsight/ext/aspectj/aop.xml, jar:file:/Applications/OpenCore/bundle/java/default/opencore-ext-aj-javaagent.jar!/com/jinspired/jxinsight/probes/ext/aspectj/aop.xml]

JBoss AS7 Final

loading resources for classloader ModuleClassLoader for Module "org.apache.xalan:main" from local module loader @6571120a (roots: /Applications/jboss-as-web-7.0.0.Final/modules)
 resources for classloader []

The jar /Applications/OpenCore/bundle/java/default/opencore-ext-aj-javaagent.jar is appended the classpath by way of the standard -javaagent VM argument.

Inside this jar are the following files:
 
com/jinspired/jxinsight/ext/aspectj/aop.xml
com/jinspired/jxinsight/probes/ext/aspectj/aop.xml

These are not found in Final though are present.

On 14/07/2011 00:13, David M. Lloyd wrote:
On 07/13/2011 05:01 PM, William Louth (JINSPIRED.COM) wrote:
JBOSS AS 7 FINAL - DOES NOT WORK, SEES NONE OF THE RESOURCES EXCEPT FOR
THE LAUNCHER
What resources is it not finding?  Do you have any log messages which 
illustrates the problem?


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Loading of System Resources Broken in JBoss AS 7 Final but worked in JBoss AS 7 Beta 3 - Workaround?

William Louth (JINSPIRED.COM)
In reply to this post by David Lloyd-2
Hi David,

It was actually listed in my original email posted (truncated?). Here is
a snippet.

JBoss AS7 Beta 3

loading resources for classloader ModuleClassLoader for Module
"org.apache.xalan:main" from local module loader @1ccb457c (roots:
/Applications/jboss-7.0.0/modules)
  resources for classloader
[jar:file:/Applications/OpenCore/bundle/java/default/opencore-ext-aj-javaagent.jar!/com/jinspired/jxinsight/ext/aspectj/aop.xml,
jar:file:/Applications/OpenCore/bundle/java/default/opencore-ext-aj-javaagent.jar!/com/jinspired/jxinsight/probes/ext/aspectj/aop.xml]

JBoss AS7 Final

loading resources for classloader ModuleClassLoader for Module
"org.apache.xalan:main" from local module loader @6571120a (roots:
/Applications/jboss-as-web-7.0.0.Final/modules)
  resources for classloader []

The jar
/Applications/OpenCore/bundle/java/default/opencore-ext-aj-javaagent.jar
is appended the classpath by way of the standard -javaagent VM argument.

Inside this jar are the following files:

com/jinspired/jxinsight/ext/aspectj/aop.xml
com/jinspired/jxinsight/probes/ext/aspectj/aop.xml

These are not found in Final though are present.

On 14/07/2011 00:13, David M. Lloyd wrote:
> On 07/13/2011 05:01 PM, William Louth (JINSPIRED.COM) wrote:
>> JBOSS AS 7 FINAL - DOES NOT WORK, SEES NONE OF THE RESOURCES EXCEPT FOR
>> THE LAUNCHER
> What resources is it not finding?  Do you have any log messages which
> illustrates the problem?
>
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Loading of System Resources Broken in JBoss AS 7 Final but worked in JBoss AS 7 Beta 3 - Workaround?

William Louth (JINSPIRED.COM)
In reply to this post by David Lloyd-2
*Here are the VM arguments added to the standalone.conf

-agentpath:/OpenCore/bin/os-32/libjxinsight.jnilib=prod
-javaagent:/OpenCore/bundle/java/default/opencore-ext-aj-javaagent.jar*
*-Djboss.modules.system.pkgs=com.jinspired,org.jinspired***

On 14/07/2011 00:13, David M. Lloyd wrote:
> On 07/13/2011 05:01 PM, William Louth (JINSPIRED.COM) wrote:
>> JBOSS AS 7 FINAL - DOES NOT WORK, SEES NONE OF THE RESOURCES EXCEPT FOR
>> THE LAUNCHER
> What resources is it not finding?  Do you have any log messages which
> illustrates the problem?
>
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Loading of System Resources Broken in JBoss AS 7 Final but worked in JBoss AS 7 Beta 3 - Workaround?

William Louth (JINSPIRED.COM)
In reply to this post by David Lloyd-2
-agentpath:/OpenCore/bin/os-32/libjxinsight.jnilib=prod
-javaagent:/OpenCore/bundle/java/default/opencore-ext-aj-javaagent.jar
-Djboss.modules.system.pkgs=com.jinspired,org.jinspired

without the *** funniness

On 14/07/2011 00:13, David M. Lloyd wrote:
> On 07/13/2011 05:01 PM, William Louth (JINSPIRED.COM) wrote:
>> JBOSS AS 7 FINAL - DOES NOT WORK, SEES NONE OF THE RESOURCES EXCEPT FOR
>> THE LAUNCHER
> What resources is it not finding?  Do you have any log messages which
> illustrates the problem?
>
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Loading of System Resources Broken in JBoss AS 7 Final but worked in JBoss AS 7 Beta 3 - Workaround?

William Louth (JINSPIRED.COM)
I believe I have identified the change which has broke CR1 and Final.

The ModuleClassLoader/ConcurrentClassLoader instances in CR1/Beta have
no parent classloader so resources are loaded from the bootstrap
classloader. Whereas in Beta3 which did work when using the system.pkgs
property the parent classloader for a ConcurrentClassLoader was the
launcher classloader (sun.misc.Launcher$AppClassLoader) which is the
classloader for JVMTI javaagents.

On 14/07/2011 00:29, William Louth (JINSPIRED.COM) wrote:

> -agentpath:/OpenCore/bin/os-32/libjxinsight.jnilib=prod
> -javaagent:/OpenCore/bundle/java/default/opencore-ext-aj-javaagent.jar
> -Djboss.modules.system.pkgs=com.jinspired,org.jinspired
>
> without the *** funniness
>
> On 14/07/2011 00:13, David M. Lloyd wrote:
>> On 07/13/2011 05:01 PM, William Louth (JINSPIRED.COM) wrote:
>>> JBOSS AS 7 FINAL - DOES NOT WORK, SEES NONE OF THE RESOURCES EXCEPT FOR
>>> THE LAUNCHER
>> What resources is it not finding?  Do you have any log messages which
>> illustrates the problem?
>>
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Loading of System Resources Broken in JBoss AS 7 Final but worked in JBoss AS 7 Beta 3 - Workaround?

William Louth (JINSPIRED.COM)
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

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.

On 14/07/2011 20:25, William Louth (JINSPIRED.COM) wrote:

> I believe I have identified the change which has broke CR1 and Final.
>
> The ModuleClassLoader/ConcurrentClassLoader instances in CR1/Beta have
> no parent classloader so resources are loaded from the bootstrap
> classloader. Whereas in Beta3 which did work when using the system.pkgs
> property the parent classloader for a ConcurrentClassLoader was the
> launcher classloader (sun.misc.Launcher$AppClassLoader) which is the
> classloader for JVMTI javaagents.
>
> On 14/07/2011 00:29, William Louth (JINSPIRED.COM) wrote:
>> -agentpath:/OpenCore/bin/os-32/libjxinsight.jnilib=prod
>> -javaagent:/OpenCore/bundle/java/default/opencore-ext-aj-javaagent.jar
>> -Djboss.modules.system.pkgs=com.jinspired,org.jinspired
>>
>> without the *** funniness
>>
>> On 14/07/2011 00:13, David M. Lloyd wrote:
>>> On 07/13/2011 05:01 PM, William Louth (JINSPIRED.COM) wrote:
>>>> JBOSS AS 7 FINAL - DOES NOT WORK, SEES NONE OF THE RESOURCES EXCEPT FOR
>>>> THE LAUNCHER
>>> What resources is it not finding?  Do you have any log messages which
>>> illustrates the problem?
>>>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Loading of System Resources Broken in JBoss AS 7 Final but worked in JBoss AS 7 Beta 3 - Workaround?

jtgreene
Administrator
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.

--
Jason T. Greene
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Loading of System Resources Broken in JBoss AS 7 Final but worked in JBoss AS 7 Beta 3 - Workaround?

Carlo de Wolf
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
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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
>
>
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Loading of System Resources Broken in JBoss AS 7 Final but worked in JBoss AS 7 Beta 3 - Workaround?

jtgreene
Administrator
In reply to this post by jtgreene
On 7/14/11 3: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.

It turns out there is actually a good reason for why it does this, I'll
have a fix with a release shortly.


--
Jason T. Greene
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Loading of System Resources Broken in JBoss AS 7 Final but worked in JBoss AS 7 Beta 3 - Workaround?

Carlo de Wolf
In reply to this post by William Louth (JINSPIRED.COM)
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
>>
>>

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Loading of System Resources Broken in JBoss AS 7 Final but worked in JBoss AS 7 Beta 3 - Workaround?

Carlo de Wolf
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
>>>
>>>
>

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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@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
>>>>
>>>>
>>
>
>
>
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Loading of System Resources Broken in JBoss AS 7 Final but worked in JBoss AS 7 Beta 3 - Workaround?

William Louth (JINSPIRED.COM)
In reply to this post by Carlo de Wolf
Just checked again and the patch does indeed fix the problem.

I had been trying various things with the system.pkgs property including
changing it to com/jinspired instead or com.jinspired. With the
following everything is back to normal.

JAVA_OPTS="${JAVA_OPTS}
-agentpath:/OpenCore/bin/os-32/libjxinsight.jnilib=prod
-javaagent:/OpenCore/bundle/java/default/opencore-ext-aj-javaagent.jar
-Djboss.modules.system.pkgs=com.jinspired,org.jinspired"

Sorry for that last slip in concentration.

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
>>>>
>>>>
>>
>
>
>
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev