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
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 (
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
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev