relative class-path entry resolution

[emuckenhuber]

There seem to be some issues resolving relative Class-Path entries outside of a deployment.
Basically the problem is that the resolution of the name is just based on the top-level deployment unit. Which means that there can't be a reference to a lib outside this.

So if you e.g. have a lib (server/libs/test.jar) and .ear with a ejb.jar and a Class-Path entry like: ../../../libs/test.jar
The AbstractStructureDeployer.getRelativePath(...) resolves this as server/libs/test.jar - but when applying the structure it fails, because it can't find 'server/libs/test.jar' within the .ear.

The spec basically does not require this, but it does not say that it should not be allowed. It looks like that referencing libraries outside of the deployment was possible with AS4.
So i'm wondering if there are any other reasons against allowing the same in AS5?

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.
Adding a parent directory as permanent-root as well, automatically resolves deploy/ as a child and the resolution could work - although i'm not really sure if this would conflict with the VFS temp/caching in any way?

[jason.greene]

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.

[starksm64]

"emuckenhuber" wrote:

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.