<document>
<header>
<product>resin</product>
<title>Packaging/Deployment</title>
<description>
<p>Resin provides a wide variety of custom packaging and deployment
options.
</p>
</description>
</header>

<body>

<localtoc/>

<s1 title="See Also">

<ul>
<li><a href="webapp-tags.xtp">web-app tags</a> defines all of the available
tags for web-app configuration.</li>
<li><a href="host-tags.xtp">host tags</a> defines all of the available
tags for host configuration.</li>
</ul>

</s1>

<s1 title="Custom web-app with .war file">

<p>In this scenario, you want to configure a web-app with a
specific root-directory and specify the location of the .war file.
As usual, when Resin sees any changes in the .war file, it will expand
the new data into the root-directory and restart the web-app.  This
capability, gives sites more flexibility where their directories and
archive files should be placed, beyond the standard webapps directory.</p>

<p>The optional <code>archive-path</code> argument of the
&lt;web-app> will point to the .war file to be expanded.</p>

<deftable title="web-app deployment options">
<tr>
  <th>Attribute</th>
  <th>Description</th>
  <th>Default</th>
</tr>
<tr>
  <td>archive-path</td>
  <td>path to the .war file which contains the web-app's contents</td>
  <td></td>
</tr>
<tr>
  <td>dependency-check-interval</td>
  <td>how often Resin should check for changes in the web-app for a redeployment</td>
  <td>2s</td>
</tr>
<tr>
  <td>id</td>
  <td>unique identifier for the web-app and the default context-path value</td>
  <td></td>
</tr>
<tr>
  <td>redeploy-check-interval</td>
  <td>how often Resin should check the .war file for changes</td>
  <td>60s</td>
</tr>
<tr>
  <td>redeploy-mode</td>
  <td>how Resin should handle redeployment: automatic, lazy, or manual</td>
  <td>automatic</td>
</tr>
<tr>
  <td>root-directory</td>
  <td>path to the expanded web-app directory</td>
  <td><var>id</var> as a sub-directory of the virtual-hosts's root</td>
</tr>
</deftable>

<example title="Example: resin.xml for custom web-app">
&lt;resin xmlns="http://caucho.com/ns/resin">
&lt;cluster id="">
  &lt;host id="">

    <b>&lt;web-app id="/foo" root-directory="/var/www/foo"
             archive-path="/usr/local/stage/foo.war"/></b>

  &lt;/host>
&lt;/cluster>
&lt;/resin>
</example>

</s1>

<s1 title="web-app versioning">

<p>Resin can deploy multiple versions of a web-app simultaneously,
simplifying any application upgrades.  The old version of the web-app
will continue to receive old sessions, while the new version will get
the new requests.  So any user will see a consistent version as the
web site update occurs with no downtime required.</p>

<p>The versioning requires &lt;web-app-deploy>, i.e. it works with
the webapps directory.  The versioning is numerically-based, allowing
dotted notation, to determine the most recent version.  A simple deployment
process might use <var>foo-101</var> to upgrade from <var>foo-100</var>.
A more complicated one might use <var>foo-10.3.14</var> to upgrade from
<var>foo-10.3.13</var>.</p>

<p>The <var>versioning</var> attribute of the &lt;web-app-deploy>
enables versioning:</p>

<example title="Example: resin.xml for webapps versioning">
&lt;resin xmlns="http://caucho.com/ns/resin">
&lt;cluster id="">
&lt;host id="">

  <b>&lt;web-app-deploy path="webapps" versioning="true"/></b>

&lt;/host>
&lt;/cluster>
&lt;/resin>
</example>

</s1>

<s1 title="Deploying to a live server without interruption">
<p>It may be possible to deploy a web application to a live server
without interruption to service if certain conditions are met.</p>

<ol>
  <li>The session objects for your users are being persisted.
  </li><li>The usage of session scoped objects between the old version and the new is compatible.
  </li><li>The usage of application scoped objects between the old version and the new is compatible.
  </li><li>Database schema changes are not required.
</li></ol>

<p>Resin allows you to have a backup instance running.  The idea is that
this backup instance of Resin takes over if your primary Resin
instance goes down.</p>

<p>If you are using a load balancer to distribute your load to multiple
primary servers, each primary server has a backup server.</p>

<p>You can use this feature to deploy to a live server without
interruption of service.</p>

<ol>
<li>shutdown primary server(s) (backup server(s) takes over)

</li><li>deploy new war to primary server(s)

</li><li>start primary server(s).  As soon as the primary server starts,
the user will be using the new version of the application.
    
</li><li>deploy new war to backup server(s)
</li></ol>

</s1>

<s1 name="precompile-jsp" title="JSP Precompilation">

<p>
See <a href="jsp-compile.xtp">JSP/Compilation.</a>
</p>
</s1>

</body>
</document>