This {@link AppProvider} implementation can deploy either {@link WebAppContext}s or plain {@link ContextHandler}s that are assembled from a series of overlays:
Each overlays may provide the following files and subdirectories:
Any init parameters set on the context, filters or servlets may have parameterized values, with the parameters including:
The OverlayedAppProvider will scan the "webapps", "templates", "nodes" and "instances" subdirectories of the directory configured with {@link #setScanDir(File)}. New webapps and overlays and modified files within the overlays will trigger hot deployment, redeployment or undeployment. The scan for modified files is restricted to only top level files (eg overlay.xml) and the files matching WEB-INF/*.xml WEB-INF/lib/ and WEB-INF/classes/*. The webapps/overlays may be directory structures or war/jar archives.
The filenames of the templates and instances are used to match them together and with a webapplication. A webapp may be named anyway, but it is good practise to include a version number (eg webapps/foo-1.2.3.war or webapps/foo-1.2.3/). A template for that webapplication must have a name that includes the template name and the war name separated by '=' (eg templates/myFoo=foo-1.2.3.jar or templates/myFoo=foo-1.2.3/). An instance overlay is named with the template name and an arbitrary instance name separated by '=' (eg instances/myFoo=instance1.jar instances/myFoo=instance2/ etc.).
If a template name does not include a webapp name, then the template is created as a ContextHandler instead of a WebAppContext (with the exact type being determined by overlay.xml).
|
|
|
|