Re: [jboss-dev] Boot problem
Ales Justin wrote:
> I finally had a chance to look into this. The problem is in VFS3,
which
> has an incorrect path assumption on Windows in certain cases. I should
> have a fix for this shortly.
While we're on the path subject.
I just noticed slightly different behavior wrt '/' usage after protocol string.
Afair we used to get two '//' after 'file' protocol in vfs, now we only
get one.
How is this defined?
Good question.
The portion of a URL that follows '//' is the optional authority. The
next slash signals the start of a path, So if you do file://blah/foo,
then that is actually supposed to mean /foo on the filesystem.
Java File URLs omit the authority, unless they have the wierd ftp hack,
Since it looks like it changes some of the behavior we use.
e.g.
URL root = unit.getAttachment(InMemoryClassesDeployer.DYNAMIC_CLASS_URL_KEY,
URL.class);
assertNotNull(root);
String aPackage = A.class.getPackage().getName();
aPackage = aPackage.replace(".", "/");
String resourceName = aPackage + "/TestInMemory";
URL testResource = new URL(root + "/" + resourceName); // <-- HERE
At HERE I expect an url where root is parent of the testResource.
Previously we used "new URL(root, resourceName)" ctor which gave this
hierarchy,
now we get the resourceName on the same 'level' as root - hence a diff ctor is
used.
Take a look at the javadoc on that constructor, and the RFC it
references. If resourceName starts with a slash, it replaces the path on
root. Otherwise it is treated as relative, however, root must have a
trailing slash in that case for the append to work.
--
Jason T. Greene
JBoss, a division of Red Hat