"jason.greene(a)jboss.com" wrote : Any reason to use it over the first construct? It should be more reliable. Does the above regression occur with it as well? The first construct doesn't work if the deployment unit base is the VFS root. Then there is no parent. I could do the following to eliminate the no parent problem: -URL url = di.getFile("").toURL(); | -return new URL(url, jar); | +VirtualFile deploymentUnitFile = di.getFile(""); | +VirtualFile parent = deploymentUnitFile.getParent(); | +VirtualFile baseDir = (parent != null ? parent : deploymentUnitFile); | +VirtualFile jarFile = baseDir.getChild(jar); | +if(jarFile == null) | + throw new RuntimeException("could not find child '" + jar + "' on '" + baseDir + "'"); | +return jarFile.toURL(); But depending on how you read the specification it could be interpreted as a violation. Because jar files are no longer relative to the physical location, if the VFS is rooted at the deployment unit. If the formal definition of 'a directory containing an exploded jar' is: a directory with the same name as the jar in question containing the extracted contents of said jar (which is how we define it). Then you've eliminated the output directory use case because you must root at the parent of the '.jar' directory and you're good to go. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4211346#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...