NanoContainer Deployer Overview
NanoContainer Deployer is capable of deploying an application from any kind of file system supported by Commons VFS, including folder and archives (zip, jar, etc), following the NanoContainer scripting model.
Application Structure
The application to deploy must have the following file structure:
+-swingingapp/
+-META-INF/
| +-nanocontainer.[groovy|xml|bsh|py|js]
+-com/
+-lindy/
+-Hip.class
+-Hop.class
For those familiar with J2EE containers (or other containers for that matter), the META-INF/picocontainer script is the ScriptedContainerBuilderFactory <em>composition script</em>. It plays the same role as more classical "deployment descriptors", except that deploying via a full blown scripting language is a lot more powerful!
Classloader Considerations
A new class loader (which will be a child of parentClassLoader) will be created. This classloader will make the classes under the application root available to the deployment script.
The scripting engine (rhino, jython, groovy etc.) should be loaded by the same classLoader as the appliacation classes, i.e. the VFSClassLoader pointing to the app directory.
+-------------------+
| xxx | <-- parent app loader (must not contain classes from app builder classloader)
+-------------------+
|
+-------------------+
| someapp | <-- app classloader (must not contain classes from app builder classloader)
+-------------------+
|
+-------------------+
| picocontainer |
| nanocontainer | <-- app builder classloader
| rhino |
| jython |
| groovy |
+-------------------+
This means that these scripting engines should not be accessible by any of the app classloader, since this may prevent the scripting engine from seeing the classes loaded by the VFSClassLoader. In other words, the scripting engine classed may be loaded several times by different class loaders - once for each deployed application.