-
15. Re: Scoping of war/jar file embedded in sar service archives
alesj Jul 16, 2008 7:48 AM (in response to adinn)"scott.stark@jboss.org" wrote:
Yes, the issue is JBAS-5773 and the test which shows the behavior using the staticarray.sar with:
staticarray1.jar
staticarray2.jar
staticarray-web1.war referring to staticarray1.jar via a classpath entry
staticarray-web2.war referring staticarray2.jar and staticarray1.jar via a classpath entry
I'll create a deployers issue as well for the WARStructure change.
I get this when running smoke-tests on my Winz machine:<testcase classname="org.jboss.test.classloader.test.ScopingUnitTestCase" name="testNestedWarManifest" time="2.453"> <error message="unknown protocol: c" type="java.net.MalformedURLException">java.net.MalformedURLException: unknown protocol: c at java.net.URL.<init>(URL.java:574) at java.net.URL.<init>(URL.java:464) at java.net.URL.<init>(URL.java:413) at org.jboss.test.JBossTestServices.getDeployURL(JBossTestServices.java:211) at org.jboss.test.JBossTestServices.undeploy(JBossTestServices.java:352) at org.jboss.test.JBossTestCase.undeploy(JBossTestCase.java:276) at org.jboss.test.classloader.test.ScopingUnitTestCase.testNestedWarManifest(ScopingUnitTestCase.java:255)
I doubt it's related to me running trunk/snapshot versions of VFS and Deployers. -
16. Re: Scoping of war/jar file embedded in sar service archives
adrian.brock Jul 16, 2008 9:21 AM (in response to adinn)Looks to me like you didn't build the jar in the testsuite, the line in error
is for when it doesn't find the file.
JBossTestServices is trying to create a url for
c:\foo\bar\jboss-head\testsuite\output\lib\whatever.jar
and obviously getting confused. ;-)
It should be creating the url as
file://c:/foo/bar/jboss-head/testsuite/output/lib/whatever.jar/** * Returns the deployment directory to use. This does it's best to figure out * where you are looking. If you supply a complete url, it returns it. * Otherwise, it looks for jbosstest.deploy.dir or if missing output/lib. Then it * tries to construct a file url or a url. * * @param filename name of the file/url you want * @return A URL * @exception MalformedURLException Description of Exception */ protected URL getDeployURL(final String filename) throws MalformedURLException { // First see if it is already a complete url. try { return new URL(filename); } catch (MalformedURLException e) { log.debug(filename + " is not a valid URL, " + e.getMessage()); } // OK, lets see if we can figure out what it might be. String deployDir = System.getProperty("jbosstest.deploy.dir"); if (deployDir == null) { deployDir = "output/lib"; } String url = deployDir + "/" + filename; log.debug("Testing file: " + url); // try to canonicalize the strings a bit. File file = new File(url); if (file.exists()) { log.debug(file.getAbsolutePath() + " is a valid file"); return file.toURL(); } else { log.debug("File does not exist, creating url: " + url); return new URL(url); // HERE !!!!!!!!!!!!!!!!!!!!!!!! } }
-
17. Re: Scoping of war/jar file embedded in sar service archives
starksm64 Jul 16, 2008 12:39 PM (in response to adinn)"adrian@jboss.org" wrote:
So I think the correct place to put this code would be in the usage of
ClassPathVisitor to "weed out" duplicates in sub-deployment classloader
that are already in one of the parent classloaders (if the parent deployment's classloader
is really a parent of the sub-deployment).
Ok, I see, sounds correct. -
18. Re: Scoping of war/jar file embedded in sar service archives
alesj Jul 18, 2008 6:43 AM (in response to adinn)"adrian@jboss.org" wrote:
Looks to me like you didn't build the jar in the testsuite, the line in error
is for when it doesn't find the file.
Sure, but the funny part is that it's complaining at undeploy time:at org.jboss.test.JBossTestServices.undeploy(JBossTestServices.java:352) at org.jboss.test.JBossTestCase.undeploy(JBossTestCase.java:276)
How did I go over deploy phase? :-) -
19. Re: Scoping of war/jar file embedded in sar service archives
alesj Jul 19, 2008 11:25 AM (in response to adinn)Cause for reopening JBDEPLOY-59.
I commited deployers/build/pom.xml to use the latest Classloading snapshot.
The ManifestClassLoaderUnitTestCase is failing due to ordering issue.
With the new Classloading code that tries to resolve ClassLoadingSpace,
this piece causes child modules to declare its vfs roots before parent modules.
org.jboss.classloading.spi.dependency.Domain:// Skip the classloader space checking when it is import all if (module.isImportAll() == false) { ClassLoadingSpace space = new ClassLoadingSpace(); space.join(module); // starting here! }
In the test top-level.jar is import-all == true,
where top-levelsub.jar is import-all == false.
1) space.join(module) calls module.determinePackageNames
2) module.getCapabilities calls module.determineCapabilities
3) module.determineCapabilities in VFSDeploymentClassLoaderPolicyModule uses determineVFSRoots
And since parent hasn't been yet examined,
this code is never calledSet<VirtualFile> parentClassPath = parent.getAttachment(VFS_CLASS_PATH, Set.class); if (parentClassPath != null) { if (log.isTraceEnabled()) { for (VirtualFile parentFile : parentClassPath) { if (classPath.contains(parentFile)) log.trace(unit + " weeding duplicate entry " + parentFile + " from classpath already in parent " + parent); } } classPath.removeAll(parentClassPath); }
leaving the sub's classpath intact.
Hence it loads class from it's own classloader. -
20. Re: Scoping of war/jar file embedded in sar service archives
alesj Jul 19, 2008 5:14 PM (in response to adinn)I've added a fix for this issue - a recursion in case parent classpath is not yet set:
protected static Set<VirtualFile> determineClassPath(DeploymentUnit unit, Module module) { Set<VirtualFile> classPath = unit.getAttachment(VFS_CLASS_PATH, Set.class); if (classPath != null) return classPath; ClassPathVisitor visitor = new ClassPathVisitor(unit); try { unit.visit(visitor); } catch (DeploymentException e) { throw new RuntimeException("Error visiting deployment: " + e); } classPath = visitor.getClassPath(); // Weed out parent classpaths if (module != null && module.getParentDomainName() == null) { DeploymentUnit parent = unit.getParent(); while (parent != null) { Set<VirtualFile> parentClassPath = determineClassPath(parent, parent.getAttachment(Module.class)); if (parentClassPath != null && parentClassPath.isEmpty() == false) { if (log.isTraceEnabled()) { for (VirtualFile parentFile : parentClassPath) { if (classPath.contains(parentFile)) log.trace(unit + " weeding duplicate entry " + parentFile + " from classpath already in parent " + parent); } } classPath.removeAll(parentClassPath); } parent = parent.getParent(); } } unit.addAttachment(VFS_CLASS_PATH, classPath); return classPath; }
But I'll let you close the JIRA issue if you feel this is a proper fix. -
21. Re: Scoping of war/jar file embedded in sar service archives
adrian.brock Jul 21, 2008 6:03 AM (in response to adinn)Ok. The fix looks correct to me.
Although, like I said above, this is a strange use case anyway. ;-)