When you think about it all deployments can be broken down into three types of data:

Sometimes only a single deployment descriptor is required although more often you create a deployment archive containing one or more descriptors together with a number of classes. In the case of a Web Archive (WAR) we also include any resources that are to be hosted by the web server.

During development it is convenient to be able to deploy such archives in an unpackaged rather than a packaged state. This means that files can be freely edited in their directories and the deployment processed again without having to re-package everything each time. Packaging is usually more appropriate during the test phase or when going to production as a way of keeping everything together.

Depending on the layout of the development, test or production system it's helpful to allow the deployment of packaged or unpackaged archives both locally, on the computer's hard drive, or remotely over a network. Support for nested deployments is also important so that related items can be deployed together.

To allow all of these concerns to be addressed in a maintainable and extendable way the deployment framework uses a Virtual File System (VFS). This provides a way to represent a deployment as a read-only hierarchical file system regardless of whether it is packaged or not. It also allows deployments to be accessed both locally and remotely using a pluggable design so that new protocols can easily be added to those supplied by default:

Finally the VFS takes care of generating physical URLs for classloading and debugging. Logical URLs can also be generated for configuration purposes, or codebase protection domains.