Basics

We can look at a directory structure, and as intelligent humans, recognize patterns.

Look at a tree such as

WEB-INF/
    web.xml
    lib/
        drools.jar
    classes/
        org/
            jboss/

  Or maybe

META-INF/
    persistence.xml
org/
    jboss/

The first looks like a WAR, while the second looks like a plain JAR.

Once we've identified the type or structure, we know the meaning of the parts of the tree.  In a WAR, we know that WEB-INF/ will contain metadata such as web.xml.  In a JAR, we know that META-INF/ may contain metadata such as persistence.xml.

We can consider these to be metadata paths that Microcontainer should scan for metadata deployments.

Additionally, for a WAR, this tree contains some implicit items for the classpath.  Any JAR nestled under WEB-INF/lib/, along with classes under WEB-INF/classes/ should be considered as entries in the classpath.  For a JAR, the root of the tree should be a classpath entry, loading the whole JAR.

To embody these concepts, Microcontainer has StructureDeployers.

When a file resource such as a JAR, a WAR, or a Rails application directory is deployed through Microcontainer, MC checks with the known StructureDeployer implementations to try to identify it. 

There's a JARStructure deployer that looks for META-INF/ to identify JARs and a WARStructure that looks for an extension of .war or the existence of WEB-INF/ to identify WARs.  If the StructureDeployer recognizes the candidate, it sets up the metadata paths and classpaths implied by the given structure.  Microcontainer then will load up the classes and continue to deploy the items found within the metadata paths.

Rails Structure

Rails developers are familiar with trees that look like

config/
    database.yml
    environment.rb
app/
    models/
    controllers/
    views/
lib/

It's apparent to me that config/ is where configuration information is kept.  It's somewhat like a JAR's META-INF/.

By convention, lib/java/**.jar is added to a JRuby-on-Rails classpath, to be made available to the application.

I've created a RailsStructure that looks for config/environment.rb, and if found, will consider the candidate to be a Rails application.  From there it adds config/ to the metadata path.

This is ultimately what allows config/jboss-scheduler.yml and other deployable files to be located, identified, and deployed.

It also adds lib/java/classes/ and all jars recursively under lib/java/ to the application's classpath, bridging the Java to Ruby gap nicely.