Okay, after much discussion and gnashing of teeth here's the best approach we can figure out so far. In order to accommodate the variety of conditions under which an archive may be mounted, the easiest solution would be to keep a registry of deployments, root or nested, which is the "resource owner" for the various submounts. This way, on undeploy the only information we need to clean everything up is the VirtualFile of the deployment root, which we should always have available if I understand this correctly. This registry is lazily populated as deployers need access to archives; this is not unlike the automagic mount facility in VFS2. The difference is that all mounts have a deterministic lifecycle that is tied to deployments in various ways. In order to manage references to mounted archives outside of the deployment, this registry would provide a simple refcount-backed mount system. Every deployment using a specific external classpath root would have a reference handle which is associated with the deployment registry mentioned above; when the deployment is removed, the handles will be cleaned up automatically, and any resources whose refcount drops to zero will be unmounted. In addition, all mounts inside a deployment are subject to removal when the deployment is removed. In particular, if a refcounted resource later comes to be a part of another deployment for whatever reason, that deployment then assumes automatic ownership of that mount, so if the deployment is removed, the mount is nuked and any outside deployments referring to that resource are SOL. This solution should allow deployments to access archive data as needed, including external shared archives, while still making sure that all resources are unmounted once nothing refers to them anymore. Hoping this makes sense. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261626#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...