-
1. Re: Remaing classLoader changes
adrian.brock Jan 22, 2008 10:07 AM (in response to adrian.brock)Setting the context classloader in the Microcontainer
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122221#4122221
Setting the deployer context classloader
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122224#4122224
Bootstrap and module style classloader outside deployment layer
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122233#4122233
Finishing the OSGI style classloader rules - META-INF/jboss-classloader.xml
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122245#4122245 -
2. Re: Remaing classLoader changes
starksm64 Jan 22, 2008 11:03 AM (in response to adrian.brock)One difference in behavior I'm seeing that we don't appear to have control over is duplicate resource ordering. The org.jboss.test.deployers.vfs.classloader.test.FilteredExportUnitTestCase.testEar1 test I just added shows a users.properties resource being loaded from the testear1/lib/jar1.jar rather than the testear1.ear/ejb1.jar as is the case for the ULR. In the ULR we give preference to exact matches on latter ordered classes loaders. If I turn off the import all flag, the ejb1.jar resource is found, but this is too restrictive a policy. We need a import-all-exact-match-first type of behavior it seems.
-
3. Re: Remaing classLoader changes
adrian.brock Jan 22, 2008 11:21 AM (in response to adrian.brock)"scott.stark@jboss.org" wrote:
One difference in behavior I'm seeing that we don't appear to have control over is duplicate resource ordering. The org.jboss.test.deployers.vfs.classloader.test.FilteredExportUnitTestCase.testEar1 test I just added shows a users.properties resource being loaded from the testear1/lib/jar1.jar rather than the testear1.ear/ejb1.jar as is the case for the ULR. In the ULR we give preference to exact matches on latter ordered classes loaders. If I turn off the import all flag, the ejb1.jar resource is found, but this is too restrictive a policy. We need a import-all-exact-match-first type of behavior it seems.
I don't see what you are describing in the UnifiedClassLoader, but I do see a difference
in the logic between the UnifiedLoaderRepository.getResource()public URL getResource(String name, ClassLoader cl) { ... // Not found in cache, ask the calling classloader resource = getResourceFromClassLoader(name, cl); ... // Not visible in global cache, iterate on all classloaders resource = getResourceFromRepository(name, cl);
and BaseClassLoaderDomain.getResource()URL getResource(BaseClassLoader classLoader, String name, boolean allExports) { boolean trace = log.isTraceEnabled(); if (getClassLoaderSystem() == null) throw new IllegalStateException("Domain is not registered with a classloader system: " + toLongString()); // Try the before attempt URL result = beforeGetResource(name); if (result != null) return result; // Work out the rules ClassLoaderInformation info = null; BaseClassLoaderPolicy policy; if (classLoader != null) { policy = classLoader.getPolicy(); info = infos.get(classLoader); if (policy.isImportAll()) allExports = true; } // Next we try the old "big ball of mud" model if (allExports) { result = getResourceFromExports(classLoader, name, trace); if (result != null) return result; } else if (trace) log.trace(this + " not getting resource " + name + " from all exports"); // Next we try the imports if (info != null) { result = getResourceFromImports(info, name, trace); if (result != null) return result; } // Finally use any requesting classloader if (classLoader != null) { if (trace) log.trace(this + " trying to get resource " + name + " from requesting " + classLoader); result = classLoader.getResourceLocally(name); if (result != null) { if (trace) log.trace(this + " got resource from requesting " + classLoader + " " + result); return result; } } // Try the after attempt result = afterGetResource(name); if (result != null) return result; // Didn't find it return null; }
i..e. it doesn't do the look locally first before asking the parent or searching the
repository. -
4. Re: Remaing classLoader changes
adrian.brock Jan 22, 2008 11:24 AM (in response to adrian.brock)"adrian@jboss.org" wrote:
"scott.stark@jboss.org" wrote:
One difference in behavior I'm seeing that we don't appear to have control over is duplicate resource ordering. The org.jboss.test.deployers.vfs.classloader.test.FilteredExportUnitTestCase.testEar1 test I just added shows a users.properties resource being loaded from the testear1/lib/jar1.jar rather than the testear1.ear/ejb1.jar as is the case for the ULR. In the ULR we give preference to exact matches on latter ordered classes loaders. If I turn off the import all flag, the ejb1.jar resource is found, but this is too restrictive a policy. We need a import-all-exact-match-first type of behavior it seems.
I don't see what you are describing in the UnifiedClassLoader
Or is this something in the URLClassLoader code? -
5. Re: Remaing classLoader changes
starksm64 Jan 22, 2008 11:27 AM (in response to adrian.brock)Ok, so do the current matching extension points/rules allow for ordering of bundles for resources/classes?
-
6. Re: Remaing classLoader changes
adrian.brock Jan 22, 2008 11:33 AM (in response to adrian.brock)"scott.stark@jboss.org" wrote:
Ok, so do the current matching extension points/rules allow for ordering of bundles for resources/classes?
For importAll, they are matched in the old way. i.e. the order the classloader
was added to the domain/repository. This is achieved by storing them in a list by
package name they export.
BaseClassLoaderDomain:/** The classloaders by package name */ private Map<String, List<ClassLoaderInformation>> classLoadersByPackageName = new ConcurrentHashMap<String, List<ClassLoaderInformation>>();
For specific imports (delegation model)
that are matched in the order the imports are "declared"
(and depending upon the parent policy, i.e. before/after). -
7. Re: Remaing classLoader changes
starksm64 Jan 22, 2008 11:37 AM (in response to adrian.brock)"adrian@jboss.org" wrote:
...
I don't see what you are describing in the UnifiedClassLoader
...
Or is this something in the URLClassLoader code?
No, I'm thinking of the LoadMgr3 behavior for ordering resources for classes. The resource behavior difference is just what you described. -
8. Re: Remaing classLoader changes
alesj Jan 22, 2008 11:55 AM (in response to adrian.brock)"scott.stark@jboss.org" wrote:
One difference in behavior I'm seeing that we don't appear to have control over is duplicate resource ordering.
OK, I must admit I'm not entirely following the discussion. :-)
But has this got to do something with this:2008-01-22 17:37:32,796 TRACE [org.jboss.seam.as5.vfs.VFSScanner] Root url: vfsfile:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.Beta4/server/default/deploy/jboss-seam-booking.ear/jboss-seam-booking.war/WEB-INF/lib/jboss-seam-debug.jar/seam.properties 2008-01-22 17:37:32,796 TRACE [org.jboss.seam.as5.vfs.VFSScanner] File: C:\projects\jboss5\trunk\build\output\jboss-5.0.0.Beta4\server\default\deploy\jboss-seam-booking.ear\jboss-seam-booking.war\WEB-INF\lib\jboss-seam-debug.jar\seam.properties 2008-01-22 17:37:32,796 TRACE [org.jboss.seam.as5.vfs.VFSScanner] URL: file:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.Beta4/server/default/deploy/jboss-seam-booking.ear, relative: jboss-seam-booking.war/WEB-INF/lib/jboss-seam-debug.jar/seam.properties 2008-01-22 17:37:33,687 TRACE [org.jboss.seam.as5.vfs.VFSScanner] Root url: jar:file:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.Beta4/server/default/tmp/deploy/jboss-seam-booking19541-exp.war/WEB-INF/lib/jboss-seam-debug.jar!/seam.properties 2008-01-22 17:37:33,687 TRACE [org.jboss.seam.as5.vfs.VFSScanner] File: file:\C:\projects\jboss5\trunk\build\output\jboss-5.0.0.Beta4\server\default\tmp\deploy\jboss-seam-booking19541-exp.war\WEB-INF\lib\jboss-seam-debug.jar!\seam.properties 2008-01-22 17:37:33,687 TRACE [org.jboss.seam.as5.vfs.VFSScanner] URL: null, relative: file:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.Beta4/server/default/tmp/deploy/jboss-seam-booking19541-exp.war/WEB-INF/lib/jboss-seam-debug.jar!/seam.properties
I do a ClassLoader.getResources("seam.properties") inside Seam app, and I'm not expecting any non vfs URLs.
Where does that 'jar:file' come from? -
9. Re: Remaing classLoader changes
adrian.brock Jan 22, 2008 12:01 PM (in response to adrian.brock)"scott.stark@jboss.org" wrote:
"adrian@jboss.org" wrote:
...
I don't see what you are describing in the UnifiedClassLoader
...
Or is this something in the URLClassLoader code?
No, I'm thinking of the LoadMgr3 behavior for ordering resources for classes. The resource behavior difference is just what you described.
This has been fixed:
http://jira.jboss.com/jira/browse/JBMICROCONT-227 -
10. Re: Remaing classLoader changes
adrian.brock Jan 22, 2008 12:05 PM (in response to adrian.brock)"alesj" wrote:
"scott.stark@jboss.org" wrote:
One difference in behavior I'm seeing that we don't appear to have control over is duplicate resource ordering.
OK, I must admit I'm not entirely following the discussion. :-)
But has this got to do something with this:2008-01-22 17:37:32,796 TRACE [org.jboss.seam.as5.vfs.VFSScanner] Root url: vfsfile:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.Beta4/server/default/deploy/jboss-seam-booking.ear/jboss-seam-booking.war/WEB-INF/lib/jboss-seam-debug.jar/seam.properties 2008-01-22 17:37:32,796 TRACE [org.jboss.seam.as5.vfs.VFSScanner] File: C:\projects\jboss5\trunk\build\output\jboss-5.0.0.Beta4\server\default\deploy\jboss-seam-booking.ear\jboss-seam-booking.war\WEB-INF\lib\jboss-seam-debug.jar\seam.properties 2008-01-22 17:37:32,796 TRACE [org.jboss.seam.as5.vfs.VFSScanner] URL: file:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.Beta4/server/default/deploy/jboss-seam-booking.ear, relative: jboss-seam-booking.war/WEB-INF/lib/jboss-seam-debug.jar/seam.properties 2008-01-22 17:37:33,687 TRACE [org.jboss.seam.as5.vfs.VFSScanner] Root url: jar:file:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.Beta4/server/default/tmp/deploy/jboss-seam-booking19541-exp.war/WEB-INF/lib/jboss-seam-debug.jar!/seam.properties 2008-01-22 17:37:33,687 TRACE [org.jboss.seam.as5.vfs.VFSScanner] File: file:\C:\projects\jboss5\trunk\build\output\jboss-5.0.0.Beta4\server\default\tmp\deploy\jboss-seam-booking19541-exp.war\WEB-INF\lib\jboss-seam-debug.jar!\seam.properties 2008-01-22 17:37:33,687 TRACE [org.jboss.seam.as5.vfs.VFSScanner] URL: null, relative: file:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.Beta4/server/default/tmp/deploy/jboss-seam-booking19541-exp.war/WEB-INF/lib/jboss-seam-debug.jar!/seam.properties
I do a ClassLoader.getResources("seam.properties") inside Seam app, and I'm not expecting any non vfs URLs.
Where does that 'jar:file' come from?
No. As I told you last week, this is showing that both the original and the tmp jar are being added
to the list of VFS files/urls in the classpath. You need to determine what is doing this. -
11. Re: Remaing classLoader changes
alesj Jan 22, 2008 12:13 PM (in response to adrian.brock)"adrian@jboss.org" wrote:
No. As I told you last week, this is showing that both the original and the tmp jar are being added
to the list of VFS files/urls in the classpath.
Eh, forgot about it, but I remember it now - the discussion. :-)
Just working on Seam scanner, stumbled on this problem. Seeing the word 'duplicate', thinking I was saved. ;-)"adrian@jboss.org" wrote:
You need to determine what is doing this.
Any usual suspects?
WarDeployer? -
12. Re: Remaing classLoader changes
adrian.brock Jan 22, 2008 12:17 PM (in response to adrian.brock)"alesj" wrote:
"adrian@jboss.org" wrote:
You need to determine what is doing this.
Any usual suspects?
WarDeployer?
I'd guess since it is a war :-)
I'd start with finding out what adds -exp to the name and copies it to tmpURL: null, relative: file:/C:/proj ects/jboss5/trunk/build/output/jboss-5.0.0.Beta4/server/default/tmp/deploy/jboss-seam-booking19541-e xp.war/WEB-INF/lib/jboss-seam-debug.jar!/seam.properties
And then sees who references that copy of the information. -
13. Re: Remaing classLoader changes
alesj Jan 22, 2008 1:31 PM (in response to adrian.brock)"adrian@jboss.org" wrote:
I'd start with finding out what adds -exp to the name and copies it to tmpURL: null, relative: file:/C:/proj ects/jboss5/trunk/build/output/jboss-5.0.0.Beta4/server/default/tmp/deploy/jboss-seam-booking19541-e xp.war/WEB-INF/lib/jboss-seam-debug.jar!/seam.properties
And then sees who references that copy of the information.
It's AbstractWarDeployer, AbstractWarDeployment and TomcatDeployment.unit.addAttachment("org.jboss.web.expandedWarClasspath", classpath); } // Indicate that an expanded URL exists unit.addAttachment("org.jboss.web.expandedWarURL", expWarUrl, URL.class); ... // Get the war URL // FIXME: JBAS-3812 - TomcatDeployment should use modified WebMetaData URL warURL = unit.getAttachment("org.jboss.web.expandedWarURL", URL.class); ... ArrayList<URL> classpath = (ArrayList<URL>)unit.getAttachment("org.jboss.web.expandedWarClasspath");
But I have no idea what's done right and what wrong, to know what causes that duplicate. :-) -
14. Re: Remaing classLoader changes
starksm64 Jan 22, 2008 5:44 PM (in response to adrian.brock)"alesj" wrote:
2008-01-22 17:37:33,687 TRACE [org.jboss.seam.as5.vfs.VFSScanner] Root url: jar:file:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.Beta4/server/default/tmp/deploy/jboss-seam-booking19541-exp.war/WEB-INF/lib/jboss-seam-debug.jar!/seam.properties 2008-01-22 17:37:33,687 TRACE [org.jboss.seam.as5.vfs.VFSScanner] File: file:\C:\projects\jboss5\trunk\build\output\jboss-5.0.0.Beta4\server\default\tmp\deploy\jboss-seam-booking19541-exp.war\WEB-INF\lib\jboss-seam-debug.jar!\seam.properties 2008-01-22 17:37:33,687 TRACE [org.jboss.seam.as5.vfs.VFSScanner] URL: null, relative: file:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.Beta4/server/default/tmp/deploy/jboss-seam-booking19541-exp.war/WEB-INF/lib/jboss-seam-debug.jar!/seam.properties
I do a ClassLoader.getResources("seam.properties") inside Seam app, and I'm not expecting any non vfs URLs.
Where does that 'jar:file' come from?
With the current mc code FilteredExportUnitTestCase.testEar1 its only showing vfs urls. I created a version that used a packed ear, and this also only shows vfsurls.
For the war I assume its because a different class loader is being used. I'm still working on getting the war class loader to be based on the WarClassLoaderDeployer.