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

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?

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?

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

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/2046885497316d66ca0682b4a... 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.

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/jb... 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/2046885497316d66ca0682b4a... >>> >> 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 > >

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/jb... >> >> >> 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/2046885497316d66ca0682b4a... >>>>> >>>> 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 >>> >>> >

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/2046885497316d66ca0682b4a... > This patch is wrong, it shouldn't have been merged. I'll revert that portion.