VFS and ClassLoader interaction
After looking at some existing VFS libraries and thinking about how class loading should be interacting with the VFS, I'm thinking a much simplified VFS api and URI based class loader that uses the VFS is what is needed. The two basic constructs are simply:
package io;
import java.net.URI;
import java.util.List;
import java.io.FileNotFoundException;
/** Prototype for a read-only VFS where virtual files are represented by URIs.
* A VFS is a tree of URIs segmented into paths by URI protocol.
*
* @author Scott.Stark@jboss.org
* @version $Revision: 1.2 $
*/
public interface ReadOnlyVFS
{
/**
* Locate a file in the VFS given its URI path.
*
* @param path - the absolute path to the virtual file (file:/root/deploy/x.ear)
* @return the matching VirtualFile
* @throws FileNotFoundException throw if the path could not be resolved
*/
public VirtualFile resolveFile(URI path)
throws FileNotFoundException;
/**
* Locate a file in the VFS given a relative URI path and contexts in
* the VFS to search from.
*
* @param path - a relative URI path (x.ear)
* @param searchContexts - the absolute paths in the VFS of the contexts to search from
* @return the matching VirtualFile
* @throws FileNotFoundException throw if the path could not be resolved
*/
public VirtualFile resolveFile(String path, List<URI> searchContexts)
throws FileNotFoundException;
/**
* Find all files in the VFS matching the relative URI path.
* @param path - a relative URI path (x.ear)
* @return A possibly empty list of matching files
*/
public List<VirtualFile> resolveFiles(String path);
/**
* Locate all files in the VFS given a relative URI path and contexts in
* the VFS to search from.
*
* @param path - a relative URI path (x.ear)
* @param searchContexts - the absolute paths in the VFS of the contexts to search from
* @return A possibly empty list of matching files
* @return A possibly empty list of matching files
*/
public List<VirtualFile> resolveFiles(String path, List<URI> searchContexts);
}
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package io;
import java.security.SecureClassLoader;
import java.net.URL;
import java.net.URI;
import java.net.MalformedURLException;
import java.util.Enumeration;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.Vector;
import java.util.jar.JarFile;
import java.util.jar.JarEntry;
import java.io.IOException;
import java.io.ByteArrayOutputStream;
import java.io.InputStream;
/** A class loader that obtains classes and resources from a VFS.
*
* @author Scott.Stark@jboss.org
* @version $Revision:$
*/
public class VFSClassLoader extends SecureClassLoader
{
/**
* Create a class loader given a search path and VFS
* @param uris - the paths from the VFS that make up the class loader path
* @param vfs - the VFS used to resolve and load classes and resources
*/
public VFSClassLoader(URI[] uris, ReadOnlyVFS vfs)
{
...
}
/**
* Find and define the given java class
*
* @param name - the binary class name
* @return the defined Class object
* @throws ClassNotFoundException thrown if the class could not be found
* or defined
*/
protected Class<?> findClass(String name) throws ClassNotFoundException
{
...
}
/**
* Search for the resource in the VFS contraining the search to the
* class loader paths.
* @param name - the resource name
* @return the resource URL if found, null otherwise
*/
public URL findResource(String name)
{
...
}
/**
* Search for the resource in the VFS contraining the search to the
* class loader paths.
* @param name - the resource name
* @return A possibly empty enumeration of the matching resources
*/
public Enumeration<URL> findResources(String name) throws IOException
{
..
}
}
Some issues that are still not clear to me are:
1. As I see it the existing DomainClassLoader needs to be layered on top of the VFS and could extend VFSClassLoader. Perhaps the DomainClassLoader should just encompass the VFS.
2. One thing I want to get away from is the need to copy deployments. The two big issues requiring this currently are buggy URLClassLoader behavior, and nested jars. The first we can address with our own VFSClassLoader. The second requires a custom jar protocol handler that allows for nested jar URLs and the ability to traverse the nested zip streams efficiently. Whether this can be done efficiently and there are other issues that end up forcing unpacking of copies remains to be seen.
