This content has been marked as final. Show 2 replies
I don't think we should bend over backwards to support this usage. It is asking for trouble. There are other mechanisms to add global jars to the classpath that are much more sensible.
In general this also seems limited how VFS resolves files, as it can't resolve files outside it's root context.
At the moment the bootstrap/vfs.xml is defining a permanent-root for the deploy/ directory. So resolving files outside of deploy/ would not work by default anyway.
I don't think it makes sense to allow resolution outside of the root context because in general this is an unknown type of VFS. For the case of a given deployment root context being a child of another VFS context, we should be able to resolve up the tree.
For the case of a server setup where the libs were on one type of VFS and the profile deploy contents on another, we can build the correct URI to pass to the VFS.getRoot(URI) or getFile(URI) call because we don't know the vfs protocol to use. There can be multiple VFS roots associated with the absolute path "/x/server/libs/test.jar" that differ only by the VFS procotol.
However, for the case where "/x/server/default/deploy" and "/x/server/libs" are both vfsfile protocol contexts, we should be able to navigate across the contexts via their comment root.