JBossDeveloper

"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.

 <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)

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 !!!!!!!!!!!!!!!!!!!!!!!!
 }
 }

"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).

"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.

at org.jboss.test.JBossTestServices.undeploy(JBossTestServices.java:352)
 at org.jboss.test.JBossTestCase.undeploy(JBossTestCase.java:276)

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!
 }

 Set<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);
 }

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;
 }

Ok. The fix looks correct to me.

Although, like I said above, this is a strange use case anyway. ;-)