[jboss-dev] Boot problem

[Jason T. Greene]

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