We deploy our application as a non-exploded ear archive.
Within our application, we need to compile a java source string into a class at runtime within the application and depend on other classes contained in a jar within the ear.

We are attempting to use either javac or JavaCompiler to perform the task. Both require you to specify additional classes or jars on the classpath for dependent classes. I am taking a sample class and get a URL to the class using:

ClassLoader loader = Thread.currentThread().getContextClassLoader();
Class referenceClass = this.getClass();
String classRelPath = referenceClass.getName().replace('.', '/') + ".class";
URL url = loader.getResource(classRelPath);

However, the class file is loaded using VFS so the URL is specified with the vfszip protocol like this:'

vfszip:/C:/Apps/jboss/jboss-5.1.0.GA/server/node1/farm/myApp.ear/lib/svrbase.jar/com/myApp/javacode/JavaCodeSourceCompiler.class

Notice that the class is being referenced relative to the actual ear file which is in non-exploded archive format.

Jboss copies the library jars from the ear to a tmp directory and I need to find a way to get a path reference to the actual jars that are classloaded by jboss in the tmp directory, not within the ear.

I have been able to force JBoss to create a new tmp file to the jar I need to add to the classpath using the following code:

String path = url.toExternalForm().substring(0, url.toExternalForm().indexOf(classRelPath) - 1);

URL resourceURL = new URL(path);

VFSUtils vfsUtils = new VFSUtils();
//Get the root location/archive whre the class is located
VirtualFile vFile = VFS.getRoot(resourceURL);
//Create a temporary file where so we can get a handle to the exact tmp location
vFile = vfsUtils.temp(vFile);
//Get the URI to the temp file location
URI tmpURI = vfsUtils.getCompatibleURI(vFile);
//Finally clean the result uri path
classFilePath = vfsUtils.stripProtocol(tmpURI);

The big drawback is that it takes a second or two to process because jboss literally creates a new tmp copy of the jar. Also, unless I use the VFS API to cleanup, JBoss does not delete the tmp file for me. That in itself is not a large problem, because JBoss routinely leaves behind a lot of files in the tmp folder and we are customarily purging the folder by deleting all files in tmp in the startup script for JBoss

I don't consider this a great workaround, but maybe it sheds some light on what I am trying to achieve and maybe someone can point me to a better solution...even if the solution lies within using the VFS API.

If there isn't currently a method using VFSUtils or a method on VIrtualFile to get the actual 'real' file location to the jar, it would be helpful if a public method could be provided to allow access to the file location.
Is there an option to force VFS or the ClassLoaders to use the real jar file paths or are there any code samples/methods within VFS to get access to the real path of the jar containing the class?