8.5. Features
One of the first major problems the Microcontainer developers faced was proper usage of nested resources, more specifically nested jar files: For example, normal ear deployments:
gema.ear/ui.war/WEB-INF/lib/struts.jar.
In order to read contents of
struts.jar we have two options:
- handle resources in memory
- create top level temporary copies of nested jars, recursively
The first option is easier to implement, but it's very memory-consuming, requiring potentially large applications to reside in memory. The other approach leaves behind a large number of temporary files, which should be invisible to the end user and therefore should disappear after undeployment.
Consider the following scenario: A user accesses a VFS URL instance, which points to some nested resource.
The way plain VFS would handle this is to re-create the entire path from scratch: it would unpack nested resources over and over again. This leads to a great number of temporary files.
The Microcontainer avoids this by using
VFSRegistry, VFSCache, and TempInfo.
When you ask for VirtualFile over VFS (
getRoot, not createNewRoot), VFS asks the VFSRegistry implementation to provide the file. The existing DefaultVFSRegistry first checks if a matching root VFSContext exists for the provided URI. If it does, DefaultVFSRegistry first tries to navigate to the existing TempInfo (link to a temporary files), falling back to regular navigation if no such temporary file exists. In this way you completely reuse any temporary files which have already been unpacked, saving time and disk space. If no matching VFSContext is found in cache, the code will create a new VFSCache entry and continue with default navigation.
Determining how the
VFSCache handles cached VFSContext entries depends on the implementation used. VFSCache is configurable via VFSCacheFactory. By default, nothing is cached, but there are a few useful existing VFSCache implementations, using algorithms such as Least Recently Used (LRU) or timed cache.
