Virtual directories

IBM® WebSphere® sMash applications are built using modules, in which one module might depend on, or require, another module. Because dependencies of a given module can also have dependencies, it is possible for the top level application to have a long dependency chain with many included modules.

The virtual directory system of WebSphere sMash allows access from a Web client to all of the public, or Web accessible resources, in any module within the dependency chain of an application. This ability provides seamless integration of script directories across an application and its dependencies, while maintaining each as separate entities.

For example, while processing a request for GET /index.html, WebSphere sMash searches for a file public/index.html in the application directory, then within each resolved dependency. The first occurrence of the file is served. WebSphere sMash applications run as if the contents of the public directories, from application to dependencies, are merged with a first-one-wins precedence.

The virtual directory function applies to all the script directories, including public, app/errors, app/resources, app/scripts, and app/views.

A virtual directory example

In this example, MyApplication is a WebSphere sMash application that depends on the extension modules acme.A and acme.B, as shown in this excerpt from the following config/ivy.xml file within MyApplication:

    <dependencies>
      <dependency org="acme" name="acme.A" rev="[1.0.0.0,2.0.0.0["/> 
      <dependency org="acme" name="acme.B" rev="[1.0.0.0,2.0.0.0["/> 
      <dependency org="zero" name="zero.core" rev="[1.0.0.0,2.0.0.0["/> 
    </dependencies>

In this example, acme.A depends on extension modules acme.A1 and acme.A2, as shown in the following config/ivy.xml file within acme.A:

    <dependencies>
      <dependency org="acme" name="acme.A1" rev="[1.0.0.0,2.0.0.0["/> 
      <dependency org="acme" name="acme.A2" rev="[1.0.0.0,2.0.0.0["/> 
    </dependencies>

Also, acme.B depends on acme.B1 and acme.B2 as shown in the following example:

    <dependencies>
      <dependency org="acme" name="acme.B1" rev="[1.0.0.0,2.0.0.0["/> 
      <dependency org="acme" name="acme.B2" rev="[1.0.0.0,2.0.0.0["/> 
    </dependencies>
    

These dependencies can be summarized in the following way:

MyApplication -> acme.A -> acme.A1
                        -> acme.A2
              -> acme.B -> acme.B1
                        -> acme.B2

Search order

Searches through virtual directories are ordered by directories contained within the application, then the dependencies of the application in the order they appear in ivy.xml files. As a dependency is searched, each dependency of that dependency is searched.

For this example, the search order is:

1. MyApplication
2. acme.A
3. acme.B
4. acme.A1
5. acme.A2
6. acme.B1
7. acme.B2

Example file layout

The example file layout uses the notation ${MyApplication} to represent the root directory of MyApplication:

${/config/dependencies/MyApplication}
+ /public
  + index.html

${/config/dependencies/acme.B}
+ /public
  + index.gt
  + HelloWorld.groovy

${/config/dependencies/acme.A1}
+ /public
  + HelloWorld.groovy

Results

Requests are served based on the search order, as shown in the following table:

Default files

A default file is the file processed on a request for a directory, such as GET /. With default configuration, the default files are a list that is searched in the following order: index.groovy, index.gt, then index.html.

Searches for default files are performed within each directory, rather than across directories. In the previous example, the search for a default file for GET / would be as follows:

1. ${/config/dependencies/MyApplication}/public/index.groovy
2. ${/config/dependencies/MyApplication}/public/index.gt
3. ${/config/dependencies/MyApplication}/public/index.html
4. ${/config/dependencies/acme.A}/public/index.groovy
5. ${/config/dependencies/acme.A}/public/index.gt
6. ${/config/dependencies/acme.A}/public/index.html
7. ...