Regarding, http://jira.jboss.com/jira/browse/JBAS-2380 I have gotten back to prototyping this. The notion of the VFS aspect is that class loading and deployers should not be dealing with the current local file, jar unpacking, etc notions. Further, optimized local deployments should be possible for more efficient class and resource access.
In working on this I have decided jars are a bad thing when it comes to a VFS abstraction. They do not fit into a VFS notion as they do not generally have the property of a random access file system. The current java classes REQUIRE that the jar be accessible via a File object to achieve the random access semantics of the java.util.jar.JarFile api. Throw nested jars into the mix and the concept of a JarVFS with O(1) is broken even when the archive is local.
As such, the notion of a JarVFS over an arbitrary URL protocol does not make sense. So what I am thinking is that we do need to move away from the notion of ant as a deploy tool and have a canonical jboss deployment package with tools for creating such packages to with this archive/VFS mismatch. Some properties of a "canonical jboss deployment package":
* Its either an exploded directory structure or a collapsed jar. By collapsed jar I mean that all nested jars are expanded within the containing jar.
* It survives server restarts. Unlike the tmp/deploy unpacked content of the current releases, the deployment package is a persistent configuration of the server.
* It contains optimization information. The package can contain indexes for class loading, resources along with timestamp(s) for identifying whether its in synch with the traditional hot deployable source.
* It is a subset of the classes seen in the full deployment archive. A common problem with scoped deployments is users including classes that cannot be overriden. There are hacks for this in the web container class loader, but this should be handled for all containers outside of the class loader.
* Tools exist for creating the deployment package. If I'm creating a read-only CD or a netbootable image where there should be no runtime copying of the traditional deployment I need to be able to create the deployment package offline.
This needs to be integrated with the jsr88 deployment service:
A significantly different class loader than the URLClassLoader is going to be needed as unlike the traditional deployment archive where a URLClassLoader hierarchy is created using ordered lists of the URLs of the various jars/directories in the deployment, the VFSClassLoader(s) is composed of an ordered list of search contexts in the VFS. This differs from the URLClassLoader when the deployment package is a collapsed archive, as in the case of this web-sso.ear:
META-INF/application.xml roles.properties users.properties sso-form-auth1.war/error.html sso-form-auth1.war/index.html sso-form-auth1.war/login.html sso-form-auth1.war/META-INF/MANIFEST.MF sso-form-auth1.war/WEB-INF/classes/org/jboss/test/web/servlets/EJBServlet.class sso-form-auth1.war/WEB-INF/classes/org/jboss/test/web/servlets/LogoutServlet.class sso-form-auth1.war/WEB-INF/classes/org/jboss/test/web/util/ sso-form-auth1.war/WEB-INF/classes/org/jboss/test/web/util/Util.class sso-form-auth1.war/WEB-INF/jboss-web.xml sso-form-auth1.war/WEB-INF/web.xml
The web-sso.ear/sso-form-auth1.war search context is not an archive. Its a prefix in the web-sso.ear deployment archive that groups the entries associated with the sso-form-auth1.war search context. When the deployment pacakge is fully unpacked then web-sso.ear/sso-form-auth1.war search context is a directory just as it in the URLClassLoader case.