documentation/virgo-documentation-2.1.1.RELEASE/docs/virgo-user-guide/htmlsingle/virgo-user-guide.html - gerrit/www.eclipse.org/virgo - Git at Google

 <html><head>
       <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
    <title>Virgo User Guide</title><link rel="stylesheet" href="css/stylesheet.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.74.0"><!--Begin Google Analytics code--><script type="text/javascript">
 			var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
 			document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
 		</script><script type="text/javascript">
 			var pageTracker = _gat._getTracker("UA-2728886-3");
 			pageTracker._setDomainName("none");
 			pageTracker._setAllowLinker(true);
 			pageTracker._trackPageview();
 		</script><!--End Google Analytics code--></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="book" lang="en"><div class="titlepage"><div><div><h1 class="title"><a name="d0e1"></a>Virgo User Guide</h1></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Rob</span> <span class="surname">Harrop</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Paul</span> <span class="surname">Kuzan</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Sam</span> <span class="surname">Brannen</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Paul</span> <span class="surname">Harris</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Christopher</span> <span class="surname">Frost</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Ben</span> <span class="surname">Hale</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Glyn</span> <span class="surname">Normington</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Juliet</span> <span class="surname">Shackell</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Steve</span> <span class="surname">Powell</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Violeta</span> <span class="surname">Georgieva</span></h3></div><div class="author"><h3 class="author"><span class="firstname">Hristo</span> <span class="surname">Iliev</span></h3></div></div></div><div><div class="mediaobject" align="right"><img src="images/virgo-logo-small.png" align="right"></div></div><div><span class="productname">Virgo<br></span></div><div><p class="releaseinfo">2.1.1.RELEASE</p></div></div><div><div><div class="legalnotice"><a name="d0e72"></a><p>
 				Copyright &copy; 2009, 2010 VMware Inc. and others
 			</p><p>
 				Contributors:
 				</p><div class="itemizedlist"><ul type="disc"><li><p>
 						VMware Inc. - initial contribution
 					</p></li><li><p>
 						Violeta Georgieva, SAP AG - Tomcat context configuration
 					</p></li><li><p>
 						Hristo Iliev, SAP AG - Setting jmx.properties permissions
 					</p></li></ul></div><p>
 			</p></div></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="chapter"><a href="#introduction">1. Introduction</a></span></dt><dd><dl><dt><span class="section"><a href="#d0e94">1.1. A Note for Virgo Kernel Users</a></span></dt></dl></dd><dt><span class="chapter"><a href="#installation">2. Installing Virgo Web Server</a></span></dt><dd><dl><dt><span class="section"><a href="#installation-prereqs">2.1. Prerequisites</a></span></dt><dt><span class="section"><a href="#installation-zip">2.2. Installing from the ZIP Download</a></span></dt><dt><span class="section"><a href="#installation-post">2.3. Post-installation steps</a></span></dt></dl></dd><dt><span class="chapter"><a href="#kernel-installation">3. Installing Virgo Kernel</a></span></dt><dd><dl><dt><span class="section"><a href="#kernel-installation-prereqs">3.1. Prerequisites</a></span></dt><dt><span class="section"><a href="#kernel-installation-zip">3.2. Installing from the ZIP Download</a></span></dt><dt><span class="section"><a href="#kernel-installation-post">3.3. Post-installation steps</a></span></dt></dl></dd><dt><span class="chapter"><a href="#starting-stopping">4. Starting and Stopping VWS</a></span></dt><dd><dl><dt><span class="section"><a href="#d0e328">4.1. Starting Virgo Web Server</a></span></dt><dt><span class="section"><a href="#d0e376">4.2. Starting in Clean Mode</a></span></dt><dt><span class="section"><a href="#d0e410">4.3. Starting in Debug Mode</a></span></dt><dt><span class="section"><a href="#d0e489">4.4. Starting with JMX Access Modifications</a></span></dt><dt><span class="section"><a href="#d0e724">4.5. Starting with a Custom Configuration Directory</a></span></dt><dt><span class="section"><a href="#d0e778">4.6. Stopping Virgo Web Server</a></span></dt></dl></dd><dt><span class="chapter"><a href="#kernel-regions-overview">5. Overview of the Virgo Kernel and User Region</a></span></dt><dd><dl><dt><span class="section"><a href="#kernel-overview">5.1. The Virgo Kernel</a></span></dt><dt><span class="section"><a href="#user-region-overview">5.2. The User Region</a></span></dt></dl></dd><dt><span class="chapter"><a href="#admin-shell">6. Equinox Console Extension (vsh)</a></span></dt><dd><dl><dt><span class="section"><a href="#admin-shell-using">6.1. Using the Equinox Console Extension</a></span></dt><dt><span class="section"><a href="#admin-shell-command-reference">6.2. Equinox Console Extension Subcommand Reference</a></span></dt></dl></dd><dt><span class="chapter"><a href="#admin-console">7. The Admin Console</a></span></dt><dd><dl><dt><span class="section"><a href="#admin-console-login">7.1. Invoking the Admin Console</a></span></dt><dt><span class="section"><a href="#admin-console-tasks">7.2. Typical Admin Console Use Cases</a></span></dt></dl></dd><dt><span class="chapter"><a href="#repository">8. The Provisioning Repository</a></span></dt><dd><dl><dt><span class="section"><a href="#repository-introduction">8.1. Overview of the Provisioning Repository</a></span></dt><dt><span class="section"><a href="#repository-brits">8.2. Finding and Downloading Bundles from the SpringSource Enterprise Bundle Repository</a></span></dt><dt><span class="section"><a href="#repository-configuration">8.3. Configuring the repository</a></span></dt></dl></dd><dt><span class="chapter"><a href="#serviceability">9. Serviceability</a></span></dt><dd><dl><dt><span class="section"><a href="#serviceability-info-log">9.1. Event logging</a></span></dt><dt><span class="section"><a href="#serviceability-info-trace">9.2. (Trace) Logging</a></span></dt><dt><span class="section"><a href="#serviceability-info-dump">9.3. Service Dumps</a></span></dt></dl></dd><dt><span class="chapter"><a href="#deployment">10. Working with Applications</a></span></dt><dd><dl><dt><span class="section"><a href="#deployment-deploying">10.1. Deploying Artifacts</a></span></dt><dt><span class="section"><a href="#deployment-undeploy">10.2. Undeploying Artifacts</a></span></dt></dl></dd><dt><span class="chapter"><a href="#configuring">11. Configuration</a></span></dt><dd><dl><dt><span class="section"><a href="#configuring-kernel">11.1. Configuring the Virgo Kernel and User Region</a></span></dt><dt><span class="section"><a href="#configuring-serviceability">11.2. Configuring Serviceability</a></span></dt><dt><span class="section"><a href="#configuring-tomcat">11.3. Configuring the Embedded Tomcat Servlet Container</a></span></dt><dt><span class="section"><a href="#configuring-provisioning-repository">11.4. Configuring the Local Provisioning Repository</a></span></dt><dt><span class="section"><a href="#configuring-hosted-repo">11.5. Configuring a Hosted Repository</a></span></dt><dt><span class="section"><a href="#configuring-osgi-framework">11.6. Configuring the OSGi Framework</a></span></dt></dl></dd><dt><span class="appendix"><a href="#log-codes">A. Event log codes</a></span></dt><dd><dl><dt><span class="section"><a href="#event-log-codes-format">A.1. Format of the event log codes</a></span></dt></dl></dd><dt><span class="appendix"><a href="#known-issues">B. Known Issues</a></span></dt><dd><dl><dt><span class="section"><a href="#known-issues-firewall-timeout">B.1. Timeout During Startup Due to Firewall Settings</a></span></dt><dt><span class="section"><a href="#known-issues-perm-gen-sun-vm">B.2. OutOfMemoryError: PermGen space running on Sun VM</a></span></dt><dt><span class="section"><a href="#alternate-serviceability-work">B.3. Alternate serviceability and work Directories</a></span></dt><dt><span class="section"><a href="#web-application-context-configuration">B.4. Web Application Context Configuration File Copying</a></span></dt></dl></dd><dt><span class="appendix"><a href="#furtherreading">C.
 		Further Reading
 	</a></span></dt></dl></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="introduction"></a>1.&nbsp;Introduction</h2></div></div></div><p>
 		This User Guide covers both Virgo Web Server and Virgo Kernel, although it emphasises the Virgo Web Server since that is likely
 		to apply to more users.
 	</p><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="d0e94"></a>1.1&nbsp;A Note for Virgo Kernel Users</h2></div></div></div><p>
 		Virgo Kernel users can be reassured that the majority of the information
 		in this Guide is directly applicable to the Virgo Kernel and they can simply ignore the web-related sections.
 	</p></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="installation"></a>2.&nbsp;Installing Virgo Web Server</h2></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="installation-prereqs"></a>2.1&nbsp;Prerequisites</h2></div></div></div><p>
 			The Virgo Web Server, or VWS for short, requires Java SE 6 or later to be installed. Java is available from
 			<a class="ulink" href="http://www.java.com/" target="_top">http://www.java.com/</a> and elsewhere.
 		</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="installation-zip"></a>2.2&nbsp;Installing from the ZIP Download</h2></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e113"></a>Downloading the ZIP file</h3></div></div></div><p>
 				Virgo Web Server is distributed as a ZIP file. This can be downloaded from
 				<a class="ulink" href="http://www.eclipse.org/virgo/download/" target="_top">here</a>.
 			</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="installation-zip-installing"></a>Installing</h3></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="installation-zip-installing-linux"></a>Linux</h4></div></div></div><p>
 					To install the Virgo Web Server on Linux, unzip the distribution package to the desired installation directory.
 					For example, to install into <code class="literal">/opt</code>:
 				</p><pre class="screen">prompt$ unzip virgo-web-server-2.1.1.RELEASE.zip -d /opt</pre><p>
 					This creates a directory called <code class="literal">virgo-web-server-2.1.1.RELEASE</code> under <code class="literal">/opt</code>.
 				</p><p>
 					Virgo Web Server requires write access to the installation directory, in this case <code class="literal">/opt/virgo-web-server-2.1.1.RELEASE</code>.
 					Typically this means it must be run as the user that installed it, or the installation directory&#8217;s ownership must be changed.
 				</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="installation-zip-installing-win"></a>Microsoft Windows</h4></div></div></div><p>
 					To install the Virgo Web Server on Windows, unzip the distribution package to the desired installation directory.
 					You should use a zip application such as 7zip, not the built-in folder decompression.  Note that both Windows and
 					Java have some issues with long file names and file paths, so we recommend installing to the root directory of
 					your chosen drive.
 				</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="installation-post"></a>2.3&nbsp;Post-installation steps</h2></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="installation-post-env"></a>Set environment variable variables</h3></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="installation-post-env-java"></a>JAVA_HOME</h4></div></div></div><p>
 					The Virgo Web Server uses the <code class="literal">JAVA_HOME</code> environment variable to locate the <code class="literal">java</code>
 					executable. Configure this environment variable to point to the home directory of the Java 6 installation on your computer.
 				</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="installation-post-env-server"></a>SERVER_HOME</h4></div></div></div><p>
 					As a convenience it is recommended that you create an environment variable that points
 					to the Virgo Web Server installation directory. Note that the Virgo Web Server does not require that
 					such an environment variable has been set. This variable may have any name of your
 					choosing. The Virgo Web Server&#8217;s documentation assumes that the variable is named
 					<code class="literal">SERVER_HOME</code>.
 				</p><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="installation-post-env-server-linux"></a>Linux</h5></div></div></div><p>
 						Edit the <code class="literal">.profile</code> file in your home directory to
 						add the <code class="literal">SERVER_HOME</code> and <code class="literal">JAVA_HOME</code> environment variables. For
 						example, if you installed into <code class="literal">/opt</code>:
 					</p><pre class="screen">export SERVER_HOME=/opt/virgo-web-server-2.1.1.RELEASE/
 export JAVA_HOME=/user/java/jdk1.6.0_17
 export PATH=$JAVA_HOME/bin:$PATH</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="installation-post-env-server-win"></a>Microsoft Windows</h5></div></div></div><p>
 						This section shows how to add <code class="literal">SERVER_HOME</code> as a system variable on Windows.  Follow the same procedure to add or update the <code class="literal">JAVA_HOME</code> environment variable.
 					</p><p>
 						From the Start menu, open the Control Panel and double-click on &#8216;System&#8217;.
 					</p><p>
 						<img src="images/system-props.png">
 					</p><p>
 						Click the &#8216;Advanced&#8217; tab and select &#8216;Environment Variables&#8217;. Next,
 						click the &#8216;New&#8217; button in the &#8216;System Variables&#8217; section.
 					</p><p>
 						<img src="images/env-variables.png">
 					</p><p>
 						This will display the &#8216;New System Variable&#8217; window.  Enter
 						<code class="literal">SERVER_HOME</code> as the &#8216;Variable name&#8217; and
 						the installation directory as the &#8216;Variable value&#8217;. Click OK.
 					</p><p>
 						<img src="images/system-variable.png">
 					</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="installation-post-env-server-win-troubleshooting"></a>Microsoft Windows - Troubleshooting</h3></div></div></div><p>
 				When starting the Virgo Web Server on some variants of Windows you might encounter a problem with file permissions.
 				The error looks like this.
 			</p><pre class="screen">WARNING: jmxPermissions.vbs did not update the permissions of C:\virgo\config\org.eclipse.virgo.kernel.jmxremote.access.properties. Check the file has the correct permissions.</pre><p>
 				If the VWS starts at this point you can skip this section and carry on. However to secure your
 				installation you have to set correct permissions. To do so, go to the &#8216;config&#8217; directory of the installation
 				in Windows Explorer.
 			</p><p>
 				<img src="images/install-windows-1-FileListing.png">
 			</p><p>
 				Right click on the &#8216;org.eclipse.virgo.kernel.jmxremote.access.properties&#8217; file and view its properties,
 				then select the &#8216;Security&#8217; tab. Remove all groups and users from the list and select &#8216;Apply&#8217;.
 			</p><p>
 				<img src="images/install-windows-2-SecuritySettings.png">
 			</p><p>
 				Within the security page select the &#8216;Advanced&#8217; options. On the &#8216;Owner&#8217; tab, choose the owner
 				that you are trying to run the VWS as and select &#8216;Apply&#8217;.
 			</p><p>
 				<img src="images/install-windows-3-AdvanceSettingsOwner.png">
 			</p><p>
 				Once this is done select &#8216;OK&#8217; to return to the &#8216;Security&#8217; tab
 				and now add the owner to the list of groups and users that have permission to access the file.
 			</p><p>
 				<img src="images/install-windows-4-AllSetReadAndExecute.png">
 			</p><p>
 				Once all these steps are complete you can proceed to start the VWS.
 			</p><pre class="screen">C:\dev\virgo-web-server-2.1.0.RELEASE&gt;bin\startup.bat
 [2009-12-08 13:09:09.545] startup-tracker              &lt;KE0001I&gt; Kernel starting.</pre></div></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="kernel-installation"></a>3.&nbsp;Installing Virgo Kernel</h2></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="kernel-installation-prereqs"></a>3.1&nbsp;Prerequisites</h2></div></div></div><p>
 			The Virgo Kernel, or VK for short, requires Java SE 6 or later to be installed. Java is available from
 			<a class="ulink" href="http://www.java.com/" target="_top">http://www.java.com/</a> and elsewhere.
 		</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="kernel-installation-zip"></a>3.2&nbsp;Installing from the ZIP Download</h2></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e277"></a>Downloading the ZIP file</h3></div></div></div><p>
 				Virgo Kernel is distributed as a ZIP file. This can be downloaded from
 				<a class="ulink" href="http://www.eclipse.org/virgo/download/" target="_top">here</a>.
 			</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="kernel-installation-zip-installing"></a>Installing</h3></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="kernel-installation-zip-installing-linux"></a>Linux</h4></div></div></div><p>
 					To install the Virgo Kernel on Linux, unzip the distribution package to the desired installation directory.
 					For example, to install into <code class="literal">/opt</code>:
 				</p><pre class="screen">prompt$ unzip virgo-kernel-2.1.1.RELEASE.zip -d /opt</pre><p>
 					This creates a directory called <code class="literal">virgo-kernel-2.1.1.RELEASE</code> under <code class="literal">/opt</code>.
 				</p><p>
 					Virgo Kernel requires write access to the installation directory, in this case <code class="literal">/opt/virgo-kernel-2.1.1.RELEASE</code>.
 					Typically this means it must be run as the user that installed it, or the installation directory&#8217;s ownership must be changed.
 				</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="kernel-installation-zip-installing-win"></a>Microsoft Windows</h4></div></div></div><p>
 					To install the Virgo Kernel on Windows, unzip the distribution package to the desired installation directory.
 					You should use a zip application such as 7zip, not the built-in folder decompression.  Note that both Windows and
 					Java have some issues with long file names and file paths, so we recommend installing to the root directory of
 					your chosen drive.
 				</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="kernel-installation-post"></a>3.3&nbsp;Post-installation steps</h2></div></div></div>
 	    Follow the same <a class="link" href="#installation-post" title="2.3&nbsp;Post-installation steps">Post-installation steps</a> as for Virgo Web Server.
 	</div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="starting-stopping"></a>4.&nbsp;Starting and Stopping Virgo Web Server</h2></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="d0e328"></a>4.1&nbsp;Starting Virgo Web Server</h2></div></div></div><p>
 	      To start Virgo Web Server run the <code class="literal">startup.sh</code> (Linux) or <code class="literal">startup.bat</code> (Windows) script.
 	      For both platforms, the script is located in the <code class="literal">SERVER_HOME/bin</code> directory.
 	    </p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e342"></a>Linux</h3></div></div></div><p>
 	        To start Virgo Web Server, open a terminal window and run <code class="literal">startup.sh</code>:
 	      </p><pre class="screen">prompt$ cd $SERVER_HOME
 prompt$ bin/startup.sh</pre><p>
 	        Once Virgo Web Server has started, the console will display a log message
 	        similar to the one shown below, along with other status messages:
 	      </p><pre class="screen">[2009-11-30 12:12:12.111] Thread-2   &lt;UR0001I&gt; User region ready.</pre><p>The preceding message indicates that you can start using VWS.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e358"></a>Microsoft Windows</h3></div></div></div><p>
 	        To start Virgo Web Server, open a command-window and run <code class="literal">startup.bat</code>:
 	      </p><pre class="screen">prompt&gt; cd %SERVER_HOME%
 prompt&gt; bin\startup.bat</pre><p>
 	        Once Virgo Web Server has started, the console will display a log message
 	        similar to the one shown below, along with other status messages:
 	      </p><pre class="screen">[2009-11-30 12:12:12.111] Thread-2   &lt;UR0001I&gt; User region ready.</pre><p>
 	      </p><p>The preceding message indicates that you can start using VWS.</p><p>
 	      </p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="d0e376"></a>4.2&nbsp;Starting in Clean Mode</h2></div></div></div><p>
 			When you start Virgo Web Server in clean mode, the startup script removes the <code class="literal">SERVER_HOME/work</code> directory (and hence all
 			running applications) as well as all trace, log and dump files.  It leaves the
 			<code class="literal">SERVER_HOME/repository</code> and <code class="literal">SERVER_HOME/pickup</code> directories untouched,
 			which means that any applications previously hot deployed will be automatically reinstalled.
 	    </p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e390"></a>Linux</h3></div></div></div><p>
 	        To start Virgo Web Server in clean mode, open a terminal window and run <code class="literal">startup.sh -clean</code>:
 	      </p><pre class="screen">prompt$ cd $SERVER_HOME
 prompt$ bin/startup.sh -clean </pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e400"></a>Microsoft Windows</h3></div></div></div><p>
 	        To start Virgo Web Server in clean mode, open a command window and run <code class="literal">startup.bat -clean</code>:
 	      </p><pre class="screen">prompt&gt; cd %SERVER_HOME%
 prompt&gt; bin\startup.bat -clean</pre></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="d0e410"></a>4.3&nbsp;Starting in Debug Mode</h2></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e413"></a>Linux</h3></div></div></div><p>
 	        To start Virgo Web Server in debug mode, run
 	        <code class="literal">startup.sh</code> passing in the
 	        <code class="literal">-debug</code> argument:
 	      </p><pre class="screen">prompt$ cd $SERVER_HOME
 prompt$ bin/startup.sh -debug</pre><p>
 	        This will start the debug agent listening on port
 	        <code class="literal">8000</code> which is the default remote debug port used
 	        by Eclipse. To start in debug mode with a specific port number, pass
 	        this in as the value for the <code class="literal">-debug</code> argument:
 	      </p><pre class="screen">prompt$ cd $SERVER_HOME
 prompt$ bin/startup.sh -debug 8001</pre><p>
 	        This will start the debug agent listening on port
 	        <code class="literal">8001</code>. To start in debug mode and suspend the VM
 	        until a debugger attaches, pass in the <code class="literal">-suspend</code>
 	        argument along with the <code class="literal">-debug</code> argument:
 	      </p><pre class="screen">prompt$ cd $SERVER_HOME
 prompt$ bin/startup.sh -debug -suspend</pre><p>
 	        This starts the debug agent, but prevents Virgo Web Server from actually
 	        starting until a debugger attaches to the agent. This can be useful
 	        when trying to diagnose problems that occur during startup.
 	      </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e451"></a>Microsoft Windows</h3></div></div></div><p>
 	        To start Virgo Web Server in debug mode, run
 	        <code class="literal">startup.bat</code> passing in the
 	        <code class="literal">-debug</code> argument:
 	      </p><pre class="screen">prompt&gt; cd %SERVER_HOME%
 prompt&gt; bin\startup.bat -debug</pre><p>
 	        This will start the debug agent listening on port
 	        <code class="literal">8000</code> which is the default remote debug port used
 	        by Eclipse. To start in debug mode with a specific port number, pass
 	        this in as the value for the <code class="literal">-debug</code> argument:
 	      </p><pre class="screen">prompt&gt; cd %SERVER_HOME%
 prompt&gt; bin\startup.bat -debug 8001</pre><p>
 	        This will start the debug agent listening on port
 	        <code class="literal">8001</code>. To start in debug mode and suspend the VM
 	        until a debugger attaches, pass in the <code class="literal">-suspend</code>
 	        argument along with the <code class="literal">-debug</code> argument:
 	      </p><pre class="screen">prompt&gt; cd %SERVER_HOME%
 prompt&gt; bin\startup.bat -debug -suspend</pre><p>
 	        This starts the debug agent, but prevents Virgo Web Server from actually
 	        starting until a debugger attaches to the agent. This can be useful
 	        when trying to diagnose problems that occur during startup.
 	      </p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="d0e489"></a>4.4&nbsp;Starting with JMX Access Modifications</h2></div></div></div>
 			The Virgo Web Server always starts with JMX access enabled, allowing you to use a management tool such as JConsole
 			to attach to the Web Server instance.
 			By default both local access and remote access over SSL with username and password
 			authentication are provided. The default port for secure JMX access is <code class="literal">9875</code>
 			and the default username and password are <code class="literal">admin</code> and <code class="literal">springsource</code>.
 			<div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e502"></a>Linux</h3></div></div></div><p>
 					To start Virgo Web Server with default JMX access enabled, run <code class="literal">startup.sh</code> passing
 					in no arguments:
 				</p><pre class="screen">prompt$ cd $SERVER_HOME
 prompt$ bin/startup.sh </pre><p>
 					To start JConsole, run the <code class="literal">jconsole.sh</code> script, located in the <code class="literal">bin</code> directory, as shown:
 				</p><pre class="screen">prompt$ cd $SERVER_HOME
 prompt$ bin/jconsole.sh </pre><p>
 					The following image shows how to specify a local connection using JConsole.
 				</p><p>
 					<img src="images/jmx-local-attach.png">
 				</p><p>
 					The following image shows how to specify a remote connection in JConsole that uses SSL with the default
 					username/password (<code class="literal">admin/springsource</code> and default secure port of <code class="literal">9875</code>).
 				</p><p>
 					<img src="images/jmx-remote-attach-default.png">
 				</p><p>
 					To start with the JMX remote access on a specific port number other than the default <code class="literal">9875</code>,
 					pass this port number in as the value
 					of the <code class="literal">-jmxport</code> argument:
 				</p><pre class="screen">prompt$ cd $SERVER_HOME
 prompt$ bin/startup.sh -jmxport 9090</pre><p>
 					This will start the Virgo Web Server with JMX enabled for remote connections on port <code class="literal">9090</code>.
 				</p><p>
 					<img src="images/jmx-remote-attach-jmxport.png">
 				</p><p>To start the JMX remote access with a custom username and password, update the <code class="literal">$SERVER_HOME/config/org.eclipse.virgo.kernel.users.properties</code> file.  First specify the custom username by changing the value of the <code class="literal">role.admin</code> property.  Then set the password of this new user by adding a new property called <code class="literal">user.<span class="emphasis"><em>username</em></span></code>, where <code class="literal"><span class="emphasis"><em>username</em></span></code> refers to the actual name of the user.  Finally, restart VWS for the changes to take effect.</p><p>For example, if you want change the JMX remote access username to <code class="literal">zebedee</code> with password <code class="literal">florence</code>, change the file as follows:
 		</p><pre class="programlisting">##################
 # User definitions
 ##################
 user.zebedee=florence


 ##################
 # Role definitions
 ##################
 role.admin=zebedee</pre><p>Specify the custom username in JConsole as shown.  </p><p>
 					<img src="images/jmx-remote-attach-jmxusers.png">
 				</p><p>
 					To start the JMX remote access using a custom SSL certificate, edit the file located at
 					<code class="literal">$SERVER_HOME/config/keystore</code>. If you wish to use a different keystore,
 					pass this filename in as the value for the <code class="literal">-keystore</code> argument and the keystore
 					password in as the value for the <code class="literal">-keystorePassword</code> argument:
 				</p><pre class="screen">prompt$ cd $SERVER_HOME
 prompt$ bin/startup.sh -keystore customKeystore -keystorePassword customKeystorePassword</pre><p>
 					This will start the Virgo Web Server with JMX enabled for remote connections using an SSL certificate from
 					<code class="literal">customKeystore</code> with a password of <code class="literal">customKeystorePassword</code>.
 				</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e613"></a>Microsoft Windows</h3></div></div></div><p>
 					To start Virgo Web Server with default JMX access enabled, run <code class="literal">startup.bat</code> passing
 					in no arguments:
 				</p><pre class="screen">prompt&gt; cd %SERVER_HOME%
 prompt&gt; bin\startup.bat</pre><p>
 					To start JConsole, run the <code class="literal">jconsole.bat</code> script, located in the <code class="literal">bin</code> directory, as shown:
 				</p><pre class="screen">prompt&gt; cd %SERVER_HOME%
 prompt&gt; bin\jconsole.bat </pre><p>
 					The following image shows how to specify a local connection using JConsole.
 				</p><p>
 					<img src="images/jmx-local-attach.png">
 				</p><p>
 					The following image shows how to specify a remote connection in JConsole that uses SSL with the default
 					username/password (<code class="literal">admin/springsource</code> and default secure port of <code class="literal">9875</code>).
 				</p><p>
 					<img src="images/jmx-remote-attach-default.png">
 				</p><p>
 					To start with the JMX remote access on a specific port number other than the default <code class="literal">9875</code>,
 					pass this port number in as the value of the <code class="literal">-jmxport</code> argument:
 				</p><pre class="screen">prompt&gt; cd %SERVER_HOME%
 prompt&gt; bin\startup.bat -jmxport 9090</pre><p>
 					This will start the Virgo Web Server with JMX enabled for remote connections on port
 					<code class="literal">9090</code>.
 				</p><p>
 					<img src="images/jmx-remote-attach-jmxport.png">
 				</p><p>To start the JMX remote access with a custom username and password, update the <code class="literal">%SERVER_HOME%\config\org.eclipse.virgo.kernel.users.properties</code> file.  First specify the custom username by changing the value of the <code class="literal">role.admin</code> property.  Then set the password of this new user by adding a new property called <code class="literal">user.<span class="emphasis"><em>username</em></span></code>, where <code class="literal"><span class="emphasis"><em>username</em></span></code> refers to the actual name of the user.  Finally, restart VWS for the changes to take effect.</p><p>For example, if you want change the JMX remote access username to <code class="literal">zebedee</code> with password <code class="literal">florence</code>, change the file as follows:
 		</p><pre class="programlisting">##################
 # User definitions
 ##################
 user.zebedee=florence


 ##################
 # Role definitions
 ##################
 role.admin=zebedee</pre><p>Specify the custom username in JConsole as shown.  </p><p>
 					<img src="images/jmx-remote-attach-jmxusers.png">
 				</p><p>
 					To start the JMX remote access using a custom SSL certificate, edit the file located at
 					<code class="literal">%SERVER_HOME%\config\keystore</code>. If you wish to use a different
 					keystore, pass this filename in as the value for the <code class="literal">-keystore</code> argument and the
 					keystore password in as the value for the <code class="literal">-keystorePassword</code> argument:
 				</p><pre class="screen">prompt&gt; cd %SERVER_HOME%
 prompt&gt; bin\startup.bat -keystore customKeystore -keystorePassword customKeystorePassword</pre><p>
 					This will start the Virgo Web Server with JMX enabled for remote attach using an SSL certificate from
 					<code class="literal">customKeystore</code> with a password of <code class="literal">customKeystorePassword</code>.
 				</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="d0e724"></a>4.5&nbsp;Starting with a Custom Configuration Directory</h2></div></div></div><p>
 			Use the <code class="literal">-configDir</code> option to specify an alternate <code class="literal">config</code> directory, different from the
 			default <code class="literal">SERVER_HOME/config</code> directory. This option allows you to use the same Virgo Web Server
 			installation to run multiple instances of Web Server . Simply create a config directory for each
 			instance, specify unique port numbers, logging and tracing directories, and so on. and then specify that directory
 			when starting Virgo Web Server.
 		</p><p>
 			If you specify a relative path for the <code class="literal">-configDir</code> parameter,
 			the startup script interprets the path as relative to the root of the Virgo Web Server installation,
 			and not relative to the directory from which you execute the <code class="literal">startup</code> script.
 		</p><p>
 			See <a class="link" href="#alternate-serviceability-work" title="B.3&nbsp;Alternate serviceability and work Directories">Alternate <code class="literal">serviceability</code> and <code class="literal">work</code>
 			Directories</a> for a known issue related to specifying an alternate <code class="literal">config</code> directory.
 		</p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e760"></a>Linux</h3></div></div></div>
 			To start Virgo Web Server using a config directory of <code class="literal">/config/node1</code>:
 			<pre class="screen">prompt$ cd $SERVER_HOME
 prompt$ bin/startup.sh -configDir /config/node1</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e769"></a>Windows</h3></div></div></div>
 			To start Virgo Web Server using a config directory of <code class="literal">c:\config\node1</code>:
 			<pre class="screen">prompt&gt; cd %SERVER_HOME%
 prompt&gt; bin\startup.bat -configDir c:\config\node1</pre></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="d0e778"></a>4.6&nbsp;Stopping Virgo Web Server</h2></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e781"></a>Linux</h3></div></div></div><p>
 	        To stop a running instance of Virgo Web Server, start a new terminal window and run the <code class="literal">shutdown.sh</code> script:
 	      </p><pre class="screen">prompt$ cd $SERVER_HOME
 prompt$ bin/shutdown.sh</pre><p>
 	        To stop a running instance of Virgo Web Server immediately, bypassing normal shutdown
 		processing, run <code class="literal">shutdown.sh</code> with the <code class="literal">-immediate</code> option:
 	      </p><pre class="screen">prompt$ cd $SERVER_HOME
 prompt$ bin/shutdown.sh -immediate</pre><p>
 	        If, when you started the Web Server instance, you used the <code class="literal">-jmxport</code> option to specify a non-default JMX port number,
 	        then you must pass this port number to the <code class="literal">-jmxport</code> of the <code class="literal">shutdown.sh</code> script
 	        to gracefully shut it down.
 	        For example, if you specified <code class="literal">9090</code> as the JMX port, use the following to shut down the Web Server instance:
 	      </p><pre class="screen">prompt$ cd $SERVER_HOME
 prompt$ bin/shutdown.sh -jmxport 9090</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e817"></a>Microsoft Windows</h3></div></div></div><p>
 	        To stop a running instance of Virgo Web Server, start a new console window and run the <code class="literal">shutdown.bat</code> script:
 	      </p><pre class="screen">prompt&gt; cd %SERVER_HOME%
 prompt&gt; bin\shutdown.bat</pre><p>
 	        To stop a running instance of Virgo Web Server immediately, bypassing normal shutdown
 			processing, run <code class="literal">shutdown.bat</code> with the <code class="literal">-immediate</code> option:
 	      </p><pre class="screen">prompt&gt; cd %SERVER_HOME%
 prompt&gt; bin\shutdown.bat -immediate</pre><p>
 	        If, when you started the Web Server instance, you used the <code class="literal">-jmxport</code> option to specify a non-default JMX port number,
 	        then you must pass this port number to the <code class="literal">-jmxport</code> of the <code class="literal">shutdown.bat</code> script to gracefully shut it down.
 	        For example, if you specified <code class="literal">9090</code> as the JMX port, use the following to shut down the Web Server instance:
 	      </p><pre class="screen">prompt&gt; cd %SERVER_HOME%
 prompt&gt; bin\shutdown.bat -jmxport 9090</pre></div></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="kernel-regions-overview"></a>5.&nbsp;Overview of the Virgo Kernel and User Region</h2></div></div></div><p>Conceptually, VWS can be divided into two separate subsystems, one of which actually encompases the other:</p><div class="itemizedlist"><ul type="disc"><li>The <span class="emphasis"><em>kernel</em></span>, which is the heart of VWS.  It makes up most of the VWS, except for the part that supports Web applications.  In other words, the kernel provides full OSGi modular support for your applications, as long as they are not Web-based.
 			<p>See <a class="link" href="#kernel-overview" title="5.1&nbsp;The Virgo Kernel">The Virgo Kernel</a> for additional information.</p></li><li>The <span class="emphasis"><em>user region</em></span> is the subsystem that manages user applications. It deliberately isolates the kernel from both your applications and those of the VWS itself, such as the Admin Console, making it much easier for you to administer VWS.
 			<p>See <a class="link" href="#user-region-overview" title="5.2&nbsp;The User Region">The User Region</a> for additional information.</p></li></ul></div><p>When you download and install Virgo Web Server you get both the kernel and web server support (configured in the user region).  You can also <a class="ulink" href="http://www.eclipse.org/virgo/download/" target="_top">download and use the kernel</a> on its own if you do not plan on deploying Web applications.  </p><p>The following graphic shows how the kernel and user region make up VWS:</p><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="885"><tr style="height: 805px"><td><img src="images/kernel-user-region.png" width="885"></td></tr></table><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="kernel-overview"></a>5.1&nbsp;The Virgo Kernel</h2></div></div></div><p>
 		The Virgo Kernel encapsulates almost all of VWS except for the deployment of Web applications.  In sum, the kernel provides the following VWS features:
 		</p><div class="itemizedlist"><ul type="disc"><li><p>
 			Deployment of non-Web artifacts, such as OSGi bundles, PARs, plans,
 			and configuration artifacts.
 			</p></li><li><p>
 			Local and hosted repositories
 			</p></li><li><p>
 			Scoping
 			</p></li><li><p>
 			Hot deployment
 			</p></li><li><p>
 			User region
 			</p></li><li><p>
 			Auto-provisioning
 			</p></li><li><p>
 			System and application tracing and dump support
 			</p></li><li><p>
 			Spring beans and Spring DM support
 			</p></li></ul></div><p>See <a class="link" href="#configuring" title="11.&nbsp;Configuration">Configuring VWS</a> for details about configuring the kernel to better suit your environment. </p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="user-region-overview"></a>5.2&nbsp;The User Region</h2></div></div></div><p>
 			The user region isolates the kernel from deployed applications,
 			including both your own user applications and the user-oriented
 			VWS applications such as the Admin Console. This means
 			that the kernel is mostly invisible to applications and to application
 			management. This is because most of the kernel bundles are not
 			installed in the user region (apart from a few needed for region
 			management). The necessary function to support the kernel runs in the
 			OSGi framework, but the user region applications cannot see it, except
 			for the services that are normally offered.
 		</p><p>
 			This way of implementing VWS greatly simplifies
 			the administration tasks you perform. In particular, when you use the
 			Admin Console to manage Web Server, you do not see
 			the many bundles that are internal to the kernel. The only exceptions
 			are the kernel bundles that VWS uses for region
 			management, which are required to be installed in the user region.
 		</p><p>This isolation has many other benefits. For example, it is no longer necessary for the kernel and user applications to use the same version of the Spring Framework. In fact the kernel installs only those parts of the Spring Framework that it needs.  If you update the kernel, it is far less likely that you will also need to upgrade or adjust the applications to accomodate a new version of the kernel. The kernel implementation is therefore much more stable and resilient and applications are much more likely to survive kernel upgrades between releases.  </p><p>When you install VWS, the kernel creates a single user region.
 			The kernel and the user region are configured independently of each other; see <a class="link" href="#configuring" title="11.&nbsp;Configuration">Configuring VWS</a> for details.
 		</p><p>Finally, the isolation provided by the user region together with scoped applications and plans solve common dependency problems that occur when using OSGi. </p></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="admin-shell"></a>6.&nbsp;Equinox Console Extension (<code class="literal">vsh</code>)</h2></div></div></div><p>Virgo provides an extension to the Equinox console in the form of the <code class="literal">vsh</code> command that allows you to examine artifacts
 	currently installed to a particular Web Server instance, manage the lifecycle of the installed artifacts, install new artifacts, and shut down
 	the server.   You can install, examine, and manage the lifecycle of the following artifacts:
 	</p><div class="itemizedlist"><ul type="disc"><li><p>Bundles</p></li><li><p>Configuration Artifacts</p></li><li><p>PARs</p></li><li><p>Plans</p></li></ul></div><p>
 	and can examine:
 	</p><div class="itemizedlist"><ul type="disc"><li><p>Exported packages</p></li><li><p>Services in the OSGi service registry</p></li></ul></div><p>
 	</p><p>
 		The Equinox console is not enabled by default.  To enable it place the setting
 </p><pre class="programlisting">osgi.console=2401</pre><p>
 		in the <code class="literal">org.eclipse.virgo.kernel.userregion.properties</code> file in the <code class="literal">config</code> directory.
 		Any free port can be used, but 2401 is the usual default.
 	</p><p>
 		You can run the Equinox console via telnet to the configured port, for example:
 	</p><pre class="programlisting">prompt$ telnet localhost 2401
 Trying ::1...
 Connected to localhost.
 Escape character is '^]'.

 osgi&gt; </pre><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="admin-shell-using"></a>6.1&nbsp;Using the Equinox Console Extension</h2></div></div></div><p>You invoke the Equinox Console Extension using the <code class="literal">vsh</code> command. For example:</p><pre class="programlisting">
 osgi&gt; vsh help


     bundle   - Management and examination of bundle artifacts
     config   - Management and examination of configuration artifacts
     exit     - Exit the kernel shell environment
     help     - Get help on commands
     install  - Install (deploy) an artifact to the server
     package  - Examination of exported packages
     par      - Management and examination of PAR artifacts
     plan     - Management and examination of plan artifacts
     service  - Examination of services
     shutdown - Shutdown Virgo Kernel


 osgi&gt; </pre><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="admin-shell-using-command-list"></a>Equinox Console Extension (<code class="literal">vsh</code>) Subcommands</h3></div></div></div><p>The following table lists the Equinox Console Extension subcommands; each subcommand in turn has a variety of options that you can specify, depending on what you want to do, such as start a bundle or refresh a plan. The reference documentation about each subcommand provides the full list of available options. </p><div class="table"><a name="admin-shell-commands-table"></a><p class="title"><b>Table&nbsp;6.1.&nbsp;Equinox Console Extension Subcommands</b></p><div class="table-contents"><table summary="Equinox Console Extension Subcommands" style="border-collapse: collapse;border-top: 1.0pt solid ; border-bottom: 1.0pt solid ; border-left: 1.0pt solid ; border-right: 1.0pt solid ; "><colgroup><col><col></colgroup><thead><tr><th style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Subcommand </th><th style="border-bottom: 1.0pt solid ; ">Description</th></tr></thead><tbody><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><a class="link" href="#admin-shell-bundle-command" title="bundle Subcommand">bundle</a></td><td style="border-bottom: 1.0pt solid ; ">Manages and displays information about bundle artifacts.</td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><a class="link" href="#admin-shell-config-command" title="config Subcommand">config</a></td><td style="border-bottom: 1.0pt solid ; ">Manages and displays information about configuration artifacts.</td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><a class="link" href="#admin-shell-package-command" title="package Subcommand">package</a></td><td style="border-bottom: 1.0pt solid ; ">Displays information about exported packages.</td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><a class="link" href="#admin-shell-par-command" title="par Subcommand">par</a></td><td style="border-bottom: 1.0pt solid ; ">Manages and displays information about PAR artifacts.</td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><a class="link" href="#admin-shell-plan-command" title="plan Subcommand">plan</a></td><td style="border-bottom: 1.0pt solid ; ">Manages and displays information about plan artifacts.</td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><a class="link" href="#admin-shell-service-command" title="service Subcommand">service</a></td><td style="border-bottom: 1.0pt solid ; ">Displays information about services in the OSGi service registry.</td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><a class="link" href="#admin-shell-install-command" title="install Subcommand">install</a></td><td style="border-bottom: 1.0pt solid ; ">Installs an artifact to Web Server. </td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><a class="link" href="#admin-shell-shutdown-command" title="shutdown Subcommand">shutdown</a></td><td style="border-bottom: 1.0pt solid ; ">Shuts down the Web Server instance to which the Equinox Console is connected.</td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><a class="link" href="#admin-shell-help-command" title="help Subcommand">help</a></td><td style="border-bottom: 1.0pt solid ; ">Displays help about the list of available subcommands, as well as more detailed help about individual subcommands.</td></tr><tr><td style="border-right: 1.0pt solid ; "><a class="link" href="#admin-shell-exit-command" title="exit Subcommand">exit</a></td><td style="">Returns to the Equinox console with no effect.</td></tr></tbody></table></div></div><br class="table-break"></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="admin-shell-command-reference"></a>6.2&nbsp;Equinox Console Extension Subcommand Reference</h2></div></div></div><p>
 	  	This section contains reference information about the Equinox Console Extension subcommands
 		<a class="link" href="#admin-shell-bundle-command" title="bundle Subcommand">bundle</a>,
 		<a class="link" href="#admin-shell-config-command" title="config Subcommand">config</a>,
 		<a class="link" href="#admin-shell-package-command" title="package Subcommand">package</a>,
 		<a class="link" href="#admin-shell-par-command" title="par Subcommand">par</a>,
 		<a class="link" href="#admin-shell-plan-command" title="plan Subcommand">plan</a>,
 		<a class="link" href="#admin-shell-service-command" title="service Subcommand">service</a>,
 		<a class="link" href="#admin-shell-install-command" title="install Subcommand">install</a>,
 		<a class="link" href="#admin-shell-shutdown-command" title="shutdown Subcommand">shutdown</a>,
 		<a class="link" href="#admin-shell-help-command" title="help Subcommand">help</a>, and
 		<a class="link" href="#admin-shell-exit-command" title="exit Subcommand">exit</a>.
 	  </p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="admin-shell-bundle-command"></a>bundle Subcommand</h3></div></div></div><p>Use the <code class="literal">bundle</code> subcommand to manage the lifecycle of bundles deployed to VWS and to gather information about deployed bundles, such as diagnostic information, header information, and so on. </p><p>The following table lists the options you can specify for this subcommand.</p><div class="table"><a name="admin-shell-bundle-command-table"></a><p class="title"><b>Table&nbsp;6.2.&nbsp;Options of the bundle Subcommand</b></p><div class="table-contents"><table summary="Options of the bundle Subcommand" style="border-collapse: collapse;border-top: 1.0pt solid ; border-bottom: 1.0pt solid ; border-left: 1.0pt solid ; border-right: 1.0pt solid ; "><colgroup><col><col></colgroup><thead><tr><th style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Option </th><th style="border-bottom: 1.0pt solid ; ">Description</th></tr></thead><tbody><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">list</td><td style="border-bottom: 1.0pt solid ; ">Displays the list of bundles that are currently installed to the current Web Server instance.  With the exception of a few kernel bundles and their services, which Web Server uses to administer the user region, none of the kernel is visible to user installed artifacts; rather, only the bundles installed in the user region are visible.
 				  <p>Each bundle is identified by an internal <code class="literal">ID</code> which you can then use with the other <code class="literal">bundle</code> subcommands that manage a particular bundle, such as <code class="literal">start </code><span class="emphasis"><em><code class="literal">id</code></em></span>.   The <code class="literal">list</code> subcommand also displays the version of the bundle, along with its state, which is one of the following standard OSGi lifecycle states:</p>
 			        <div class="itemizedlist"><ul type="disc"><li><p><span class="bold"><strong>Installed</strong></span>: The bundle is installed but its dependencies have not yet been resolved.</p></li><li><p><span class="bold"><strong>Resolved</strong></span>: The bundle is resolved and you can now start it.</p></li><li><p><span class="bold"><strong>Uninstalled</strong></span>: The bundle is uninstalled and you can not use it.</p></li><li><p><span class="bold"><strong>Starting</strong></span>:  The bundle is in the process of starting.</p></li><li><p><span class="bold"><strong>Active</strong></span>: The bundle is running and you can now use it.</p></li><li><p><span class="bold"><strong>Stopping</strong></span>: The bundle is in the process of stopping.</p></li></ul></div>
 			     <p>Use one of the other <code class="literal">bundle</code> subcommands to change the state of a bundle.  For example, use the <code class="literal">bundle start </code><span class="emphasis"><em><code class="literal">id</code></em></span> subcommand to change the state of a bundle from <code class="literal">Installed</code> to <code class="literal">Active</code>.</p>
 			   </td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">examine <span class="emphasis"><em>id</em></span></td><td style="border-bottom: 1.0pt solid ; ">Displays detailed information about the specified bundle.  Use the <code class="literal">bundle list</code> subcommand to get the internal id of a particular bundle.
 			         <p>In addition to the information provided by the <code class="literal">bundle list</code> subcommand (id, full name, version, and state), the <code class="literal">examine</code> subcommand specifies whether the bundle includes a Spring application context (or is <span class="emphasis"><em>Spring Powered</em></span>) and the exact physical location of the bundle JAR file.  </p>
 				<p>The <code class="literal">examine</code> also provides the full list of packages that the bundle imports, as well as the bundles that in turn export these imported packages.  Finally, the subcommand displays the packages that the current bundle exports, and then in turn the list of other installed bundles that are currently importing these exported packages.  </p>
 			    </td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">start <span class="emphasis"><em>id</em></span></td><td style="border-bottom: 1.0pt solid ; ">Starts the specified bundle.  Use the <code class="literal">bundle list</code> subcommand to get the internal id of a particular bundle.
 				<p>After Web Server successfully starts the bundle, it is listed in the <code class="literal">Active</code> state. </p>
 				</td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">stop <span class="emphasis"><em>id</em></span></td><td style="border-bottom: 1.0pt solid ; ">Stops the specified bundle.  Use the <code class="literal">bundle list</code> subcommand to get the internal id of a particular bundle.
 				  <p>When you stop a bundle, it goes from the <code class="literal">Active</code> state to the <code class="literal">Resolved</code> state, and you must re-start it if you want to use the application that the bundle contains.</p> </td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">refresh <span class="emphasis"><em>id</em></span></td><td style="border-bottom: 1.0pt solid ; ">Updates the contents of the specified bundle. Use the <code class="literal">bundle list</code> subcommand to get the internal id of a particular bundle.  Use this subcommand if you have changed the contents of the bundle JAR file and you want to refresh the artifact as installed in the OSGi framework.
 				</td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">uninstall <span class="emphasis"><em>id</em></span></td><td style="border-bottom: 1.0pt solid ; ">Uninstalls the specified bundle from Web Server.   Use the <code class="literal">bundle list</code> subcommand to get the internal id of a particular bundle.
 				  <p>When the uninstall process is complete, the bundle does not show up in the list of bundles displayed by the <code class="literal">bundle list</code> subcommand.  If you want to use the application in the bundle, you must re-install it using the <code class="literal">install</code> subcommand.</p>
 				</td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">diag <span class="emphasis"><em>id</em></span></td><td style="border-bottom: 1.0pt solid ; ">Provides diagnostic information about the specified bundle.  In particular, this subcommand displays information about the imported packages that Web Server could not resolve.  Use the <code class="literal">bundle list</code> subcommand to get the internal id of a particular bundle.
 				</td></tr><tr><td style="border-right: 1.0pt solid ; ">headers <span class="emphasis"><em>id</em></span></td><td style="">Displays the complete list of manifest headers of the specified bundle.  Use the <code class="literal">bundle list</code> subcommand to get the internal id of a particular bundle.
 				  <p>The manifest headers include: <code class="literal">Import-Package</code>, <code class="literal">Export-Package</code>, <code class="literal">Bundle-SymbolicName</code>, and so on.  </p>
 				</td></tr></tbody></table></div></div><br class="table-break"><p>The following examples show how to use this subcommand.</p><p>First, use the <code class="literal">bundle list</code> subcommand to view all the installed bundles:</p><pre class="programlisting">osgi&gt; vsh bundle list

 Id   Name                                 Version                          State
 0    org.eclipse.osgi                     3.6.1.R36x_v20100806            ACTIVE
 1    org.eclipse.virgo.region.user        0.0.0                           ACTIVE
 2    org.eclipse.virgo.kernel.userregion  2.1.0.RELEASE                   ACTIVE
 3    org.eclipse.virgo.kernel.osgicommand 2.1.0.RELEASE                   ACTIVE
 4    org.springframework.osgi.core        1.2.1                           ACTIVE
 5  S org.springframework.osgi.extender    1.2.1                           ACTIVE
 6    org.springframework.osgi.io          1.2.1                           ACTIVE
 7    org.eclipse.virgo.kernel.agent.dm    2.1.0.RELEASE                   ACTIVE
 8  S org.eclipse.virgo.kernel.deployer.dm 2.1.0.RELEASE                   ACTIVE
 9    com.springsource.org.aopalliance     1.0.0                           ACTIVE
 10   org.eclipse.virgo.kernel.dmfragment  2.1.0.RELEASE                 RESOLVED
 11   org.springframework.aop              3.0.0.RELEASE                   ACTIVE
 12   org.springframework.asm              3.0.0.RELEASE                   ACTIVE
 13   org.springframework.beans            3.0.0.RELEASE                   ACTIVE
 14   org.springframework.context          3.0.0.RELEASE                   ACTIVE
 15   org.springframework.core             3.0.0.RELEASE                   ACTIVE
 16   org.springframework.expression       3.0.0.RELEASE                   ACTIVE

 osgi&gt; </pre><p>The following example shows how to view the headers of the <code class="literal">org.springframework.osgi.extender</code> bundle (only the first few lines are shown):</p><pre class="programlisting">osgi&gt; vsh bundle examine 5

 Id:              5
 Name:            org.springframework.osgi.extender
 Version          1.2.1
 State:           ACTIVE
 Spring Powered:  true
 Bundle Location: file:&lt;... omitted ...&gt;/org.springframework.osgi.extender-1.2.1.jar/

 Imported Packages:
     org.springframework.osgi.context [1.2.1, 1.2.1]
         exported by org.springframework.osgi.core 1.2.1 [4]
     &lt;... remainder omitted ...&gt;

 Exported Packages:
     org.springframework.osgi.extender 1.2.1
     &lt;... remainder omitted ...&gt;

 Published services:
      58 org.springframework.beans.factory.xml.NamespaceHandlerResolver
         consumed by org.springframework.osgi.extender 1.2.1 [5]
         consumed by org.eclipse.virgo.kernel.deployer.dm 2.1.0.RELEASE [8]
     &lt;... remainder omitted ...&gt;

 Consumed services:
      34 org.eclipse.virgo.kernel.shim.serviceability.TracingService
         published by org.eclipse.virgo.region.user 0.0.0 [1]
     &lt;... remainder omitted ...&gt;

 Fragments:
     org.eclipse.virgo.kernel.dmfragment 2.1.0.RELEASE [10]

 osgi&gt; </pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="admin-shell-config-command"></a>config Subcommand</h3></div></div></div><p>Use the <code class="literal">config</code> subcommand to view and manage the configuration artifacts that have been installed to Web Server.  A <span class="emphasis"><em>configuration artifact</em></span> is simply a properties file that is associated with a user application that is contained in a bundle.  Using configuration artifacts, you can manage the configuration of a user application completely separately from the bundle that contains the application. </p><p>The following table lists the options you can specify for this subcommand.</p><div class="table"><a name="admin-shell-config-command-table"></a><p class="title"><b>Table&nbsp;6.3.&nbsp;Options of the config Subcommand</b></p><div class="table-contents"><table summary="Options of the config Subcommand" style="border-collapse: collapse;border-top: 1.0pt solid ; border-bottom: 1.0pt solid ; border-left: 1.0pt solid ; border-right: 1.0pt solid ; "><colgroup><col><col></colgroup><thead><tr><th style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Option </th><th style="border-bottom: 1.0pt solid ; ">Description</th></tr></thead><tbody><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">list</td><td style="border-bottom: 1.0pt solid ; ">Lists the configuration artifacts that are currently installed in Web Server.
 			          <p>The <code class="literal">list</code> option displays the full name of each installed configuration artifact, its version, and its current state.  Configuration artifacts have similar lifecycles to other artifacts, such as bundles, and so the list of states in which a configuration can be in is the same as those of bundles; see <a class="link" href="#admin-shell-bundle-command" title="bundle Subcommand">the bundle subcommand</a> for the list of possible states. </p>
 			        </td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">examine <span class="emphasis"><em>name [version]</em></span></td><td style="border-bottom: 1.0pt solid ; ">Displays information about the specified configuration artifact.  Although you must specify the name of the configuration artifact, its version is optional unless you have multiple versions of the configuration artifact installed.  Use the <code class="literal">config list</code> subcommand to view all configuration artifacts and versions currently installed in Web Server.
 				<p>A configuration artifact must be active for you to examine it; if it is not currently active, use <code class="literal">config start</code> to start it and thus change its state to <code class="literal">Active</code>.</p>
 				<p>The subcommand first displays the factory pid of the configuration artifact as well as the complete location of the bundle to which the configuration artifact is associated.   The subcommand then lists all the properties that make up the configuration, as well as their current value. </p> </td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">start <span class="emphasis"><em>name [version]</em></span></td><td style="border-bottom: 1.0pt solid ; ">Starts the specified configuration artifact and makes it visible to the internal configuration sub-system of Web Server.  Although you must specify the name of the configuration artifact, its version is optional unless you have multiple versions of the configuration artifact installed.  Use the <code class="literal">config list</code> subcommand to view all configuration artifacts and versions currently installed in Web Server.

 				<p>Starting the configuration sets its state to <code class="literal">Active</code>.</p></td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">stop <span class="emphasis"><em>name [version]</em></span></td><td style="border-bottom: 1.0pt solid ; ">Stops the specified configuration artifact and makes it invisible to the internal configuration sub-system of Web Server.  Although you must specify the name of the configuration artifact, its version is optional unless you have multiple versions of the configuration artifact installed.  Use the <code class="literal">config list</code> subcommand to view all configuration artifacts and versions currently installed in Web Server.

 				<p>Stopping the configuration sets its state to <code class="literal">Resolved</code>.</p></td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">refresh <span class="emphasis"><em>name [version]</em></span></td><td style="border-bottom: 1.0pt solid ; ">Updates the contents of the specified configuration artifact to the internal configuration sub-system of Web Server.  Although you must specify the name of the configuration artifact, its version is optional unless you have multiple versions of the configuration artifact installed.  Use the <code class="literal">config list</code> subcommand to view all configuration artifacts and versions currently installed in Web Server.

 				<p>Use this subcommand if you have changed the contents of the configuration artifact, and you want to make this information known to Web Server and the associated bundle. </p></td></tr><tr><td style="border-right: 1.0pt solid ; ">uninstall <span class="emphasis"><em>name [version]</em></span></td><td style="">Uninstalls the specified configuration artifact and make it completely unavailable to Web Server.  Although you must specify the name of the configuration artifact, its version is optional unless you have multiple versions of the configuration artifact installed.  Use the <code class="literal">config list</code> subcommand to view all configuration artifacts and versions currently installed in Web Server.

 				<p>Stopping the configuration  removes it from Web Server's list of deployed artifacts and it will not show up when you perform a <code class="literal">config list</code>.</p></td></tr></tbody></table></div></div><br class="table-break"><p>The following example shows how to use this subcommand to list the installed configuration artifacts.</p><pre class="programlisting">osgi&gt; vsh config list

 Name                                      Version                          State
 org.eclipse.virgo.kernel                  0.0.0                           ACTIVE
 org.eclipse.virgo.kernel.jmxremote.access 0.0.0                           ACTIVE
 org.eclipse.virgo.kernel.userregion       0.0.0                           ACTIVE
 org.eclipse.virgo.kernel.users            0.0.0                           ACTIVE
 org.eclipse.virgo.medic                   0.0.0                           ACTIVE
 org.eclipse.virgo.repository              0.0.0                           ACTIVE

 osgi&gt; </pre><p>To view the properties of a configuration artifact, and their current values, use <code class="literal">config examine</code>:</p><pre class="programlisting">osgi&gt; vsh config examine org.eclipse.virgo.kernel

 Factory pid:
 Bundle Location: file:lib/kernel/org.eclipse.virgo.kernel.osgi-2.1.0.RELEASE.jar

 Properties:
     deployer.pickupDirectory:
         pickup
     deployer.timeout:
         300
     domain:
         org.eclipse.virgo.kernel
     home.directory:
         /Users/glynnormington/virgo-web-server-2.1.0.RELEASE
     service.pid:
         org.eclipse.virgo.kernel
     work.directory:
         /Users/glynnormington/virgo-web-server-2.1.0.RELEASE/work
 osgi&gt; </pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="admin-shell-package-command"></a>package Subcommand</h3></div></div></div><p>Use the <code class="literal">package</code> subcommand to view the complete list of packages exported by all bundles installed to Web Server, as well as examine a particular exported package in more detail.</p><p>The following table lists the options you can specify for this subcommand.</p><div class="table"><a name="admin-shell-package-command-table"></a><p class="title"><b>Table&nbsp;6.4.&nbsp;Options of the package Subcommand</b></p><div class="table-contents"><table summary="Options of the package Subcommand" style="border-collapse: collapse;border-top: 1.0pt solid ; border-bottom: 1.0pt solid ; border-left: 1.0pt solid ; border-right: 1.0pt solid ; "><colgroup><col><col></colgroup><thead><tr><th style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Option </th><th style="border-bottom: 1.0pt solid ; ">Description</th></tr></thead><tbody><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">list</td><td style="border-bottom: 1.0pt solid ; ">Displays all the exported packages for all bundles in the uer region of Web Server.  In addition to the package name, the subcommand displays the version of the exported package and the <code class="literal">id</code> of the bundle that contains the exported package.  You can examine the bundle by using the subcommand <code class="literal">bundle examine </code><span class="emphasis"><em><code class="literal">id</code></em></span>.</td></tr><tr><td style="border-right: 1.0pt solid ; ">examine <span class="emphasis"><em>name version</em></span></td><td style="">Displays details about the exported package.  You must specify both the name of the exported package and its version; use <code class="literal">package list</code> to view the exact names and version.
 				  <p>This subcommand provides the following additional information about the exported package:</p>

 				  <div class="itemizedlist"><ul type="disc"><li><p>The name and version of the bundle that exports the package.  This means that the package name is explicitly listed in the bundle's <code class="literal">MANIFEST.MF</code> file as part of the <code class="literal">Export-Package</code> header.</p></li><li><p>Any attributes that are part of the <code class="literal">Export-Package</code>, in addition to <code class="literal">version</code>.</p></li><li><p>The directives that are part of the <code class="literal">Export-Package</code> header.  A typical directive is <code class="literal">uses</code>, which declares up-front constraints on a number of other packages.</p></li><li><p>The list of all bundles that import the package.</p></li></ul></div>
 				</td></tr></tbody></table></div></div><br class="table-break"><p>The following example shows how to list all the exported packages for all bundles installed:</p><pre class="programlisting">osgi&gt; vsh package list

 Name                                                        Version                    Providing Bundle
 javax.accessibility                                         0.0.0                      0
 javax.activation                                            0.0.0                      0
 javax.activation                                            1.1.1                      0
 &lt;... remainder omitted ...&gt;

 osgi&gt; </pre><p>The following example shows how to examine a particular exported package:</p><pre class="programlisting">osgi&gt; vsh package examine org.slf4j 1.6.1

 Exporter: org.eclipse.virgo.region.user 0.0.0 [1]

 Attributes:
     None

 Directives:
     uses:
         org.slf4j.spi
     x-equinox-ee:
         -1
     x-internal:
         false

 Importer(s):
     org.eclipse.virgo.kernel.agent.dm 2.1.0.RELEASE [7]
         Import-Package attributes:
             bundle-version:
                 0.0.0
             version:
                 [1.6.1,2.0.0)
         Import-Package directives:
             resolution:
                 static
     &lt;... remainder omitted ...&gt;

 osgi&gt; </pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="admin-shell-par-command"></a>par Subcommand</h3></div></div></div><p>Use the <code class="literal">par</code> subcommand to view all the PARs currently installed in Web Server, view details about a particular PAR and manage its lifecycle, such as starting, stopping, refreshing, and uninstalling it.</p><p>The following table lists the options you can specify for this subcommand.</p><div class="table"><a name="admin-shell-par-command-table"></a><p class="title"><b>Table&nbsp;6.5.&nbsp;Options of the par Subcommand</b></p><div class="table-contents"><table summary="Options of the par Subcommand" style="border-collapse: collapse;border-top: 1.0pt solid ; border-bottom: 1.0pt solid ; border-left: 1.0pt solid ; border-right: 1.0pt solid ; "><colgroup><col><col></colgroup><thead><tr><th style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Option </th><th style="border-bottom: 1.0pt solid ; ">Description</th></tr></thead><tbody><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">list</td><td style="border-bottom: 1.0pt solid ; ">Displays all the PARs that are currently installed in Web Server.
 			          <p>The <code class="literal">list</code> option displays the full name of each installed PAR, its version, and its current state.  PARs have similar lifecycles to other artifacts, such as bundles, and so the list of states in which a PAR can be in is the same as those of bundles; see <a class="link" href="#admin-shell-bundle-command" title="bundle Subcommand">the bundle subcommand</a> for the list of possible states. </p></td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">examine <span class="emphasis"><em>name version</em></span></td><td style="border-bottom: 1.0pt solid ; ">Displays information about the specified PAR; you are required to identify the PAR with both its name and its version.  Use the <code class="literal">par list</code> subcommand to view all installed PAR files and their versions.  The subcommand displays the following information:
 			         <div class="itemizedlist"><ul type="disc"><li><p>The current state of the PAR (see <a class="link" href="#admin-shell-bundle-command" title="bundle Subcommand">the bundle subcommand</a> for the full list of possible states).</p></li><li><p>Whether the PAR is <span class="emphasis"><em>scoped</em></span>.  Scoping specifies whether Web Server should deploy the members of the PAR in their own scope; when scoping is disabled, Web Server deploys the artifacts into the global scope and they are accessible for access by all other artifacts.</p></li><li><p>Whether the PAR is <span class="emphasis"><em>atomic</em></span>.  When a PAR is atomic, Web Server manages the lifecycle of all its member artifacts as a single entity, which means if one artifact member is started, then Web Server starts <span class="emphasis"><em>all</em></span> the PAR artifacts. If one artifact fails to start, then Web Server stops all other artifacts in the PAR.</p></li><li><p>The individual members, or children, of the PAR.  These could be other PARs, plans, bundles, configuration artifacts, and so on.</p></li></ul></div>
 			   </td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">start <span class="emphasis"><em>name version</em></span></td><td style="border-bottom: 1.0pt solid ; ">Starts the specified PAR.  You must specify both the full name of the PAR as well as the version you want to start. Use the <code class="literal">par list</code> subcommand to get the list of PARs currently installed in Web Server.
 				<p>To start a PAR, it must have already been resolved by Web Server, or in other words, be in the <code class="literal">Resolved</code> state.  After Web Server successfully starts the PAR, it is listed in the <code class="literal">Active</code> state. </p></td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">stop <span class="emphasis"><em>name version</em></span></td><td style="border-bottom: 1.0pt solid ; ">Stops the specified PAR.  You must specify both the full name of the PAR as well as the version you want to stop. Use the <code class="literal">par list</code> subcommand to get the list of PARs currently installed in Web Server.
 				  <p>When you stop a PAR, it goes from the <code class="literal">Active</code> state to the <code class="literal">Resolved</code> state, and you must re-start it if you want to use the application that the PAR contains.</p> </td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">refresh <span class="emphasis"><em>name version</em></span></td><td style="border-bottom: 1.0pt solid ; ">Updates the contents of the specified PAR. You must specify both the name and version of the PAR you want to refresh.  Use the <code class="literal">par list</code> subcommand to this information.
 				<p>Use this subcommand if you have changed the contents of the PAR file and you want to refresh the artifact as installed in the OSGi framework.</p></td></tr><tr><td style="border-right: 1.0pt solid ; ">uninstall <span class="emphasis"><em>name version</em></span></td><td style="">Uninstalls the specified PAR. You must specify both the name and version of the PAR you want to refresh.  Use the <code class="literal">par list</code> subcommand to this information.
 				  <p>When the uninstall process is complete, the PAR will not show up in the list of PARs displayed by the <code class="literal">par list</code> subcommand.  If you want to use the application in the PAR, you must re-install it using the <code class="literal">install</code> subcommand.</p></td></tr></tbody></table></div></div><br class="table-break"><p>The following example shows how to list the PARs that have been installed in Web Server:</p><pre class="programlisting">osgi&gt; vsh par list

 Name                                         Version                      State

 org.eclipse.virgo.server.repository.hosted    2.1.0.RELEASE              ACTIVE

 osgi&gt; </pre><p>The following example shows how to examine a particular PAR file:</p><pre class="programlisting">osgi&gt; vsh par examine org.eclipse.virgo.server.repository.hosted 2.1.0.RELEASE

 State:  ACTIVE
 Scoped: true
 Atomic: true

 Children:
     bundle org.eclipse.virgo.server.repository.hosted.core 2.1.0.RELEASE
     bundle org.eclipse.virgo.server.repository.hosted.web 2.1.0.RELEASE
     bundle org.eclipse.virgo.server.repository.hosted-synthetic.context 2.1.0.RELEASE

 osgi&gt; </pre><p>Finally, the following example shows how to refresh an installed PAR file:</p><pre class="programlisting">osgi&gt; vsh par refresh my.exciting.par 1.2.0

 par my.exciting.par 1.2.0 refreshed successfully

 osgi&gt; </pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="admin-shell-plan-command"></a>plan Subcommand</h3></div></div></div><p>Use the <code class="literal">plan</code> subcommand to view all the plans currently installed in Web Server, view details about a particular plan and manage its lifecycle, such as starting, stopping, refreshing, and uninstalling it.</p><p>The following table lists the options you can specify for this subcommand.</p><div class="table"><a name="admin-shell-plan-command-table"></a><p class="title"><b>Table&nbsp;6.6.&nbsp;Options of the plan Subcommand</b></p><div class="table-contents"><table summary="Options of the plan Subcommand" style="border-collapse: collapse;border-top: 1.0pt solid ; border-bottom: 1.0pt solid ; border-left: 1.0pt solid ; border-right: 1.0pt solid ; "><colgroup><col><col></colgroup><thead><tr><th style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Option </th><th style="border-bottom: 1.0pt solid ; ">Description</th></tr></thead><tbody><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">list</td><td style="border-bottom: 1.0pt solid ; ">Displays all the plans that are currently installed in Web Server.
 			          <p>The <code class="literal">list</code> option displays the full name of each installed plan, its version, and its current state.  Plans have similar lifecycles to other artifacts, such as bundles, and so the list of states in which a plan can be in is the same as those of bundles; see <a class="link" href="#admin-shell-bundle-command" title="bundle Subcommand">the bundle subcommand</a> for the list of possible states. </p></td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">examine <span class="emphasis"><em>name version</em></span></td><td style="border-bottom: 1.0pt solid ; ">Displays information about the specified plan; you are required to identify the plan with both its name and its version.  Use the <code class="literal">plan list</code> subcommand to view all installed plans and their versions.  The subcommand displays the following information:
 			         <div class="itemizedlist"><ul type="disc"><li><p>The current state of the plan (see <a class="link" href="#admin-shell-bundle-command" title="bundle Subcommand">the bundle subcommand</a> for the full list of possible states).</p></li><li><p>Whether the plan is <span class="emphasis"><em>scoped</em></span>.  Scoping specifies whether Web Server should deploy the members of the plan in their own scope; when scoping is disabled, Web Server deploys the artifacts into the global scope and they are accessible for access by all other artifacts.</p></li><li><p>Whether the plan is <span class="emphasis"><em>atomic</em></span>.  When a plan is atomic, Web Server manages the lifecycle of all its member artifacts as a single entity, which means if one artifact member is started, then Web Server starts <span class="emphasis"><em>all</em></span> the plan artifacts. If one artifact fails to start, then Web Server stops all other artifacts in the plan.</p></li><li><p>The individual members, or children, of the plan.  These could be other plans, PARs, bundles, configuration artifacts, and so on.</p></li></ul></div>
 			   </td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">start <span class="emphasis"><em>name version</em></span></td><td style="border-bottom: 1.0pt solid ; ">Starts the specified plan.  You must specify both the full name of the plan as well as the version you want to start. Use the <code class="literal">plan list</code> subcommand to get the list of plans currently installed in Web Server.
 				<p>To start a plan, it must have already been resolved by Web Server, or in other words, be in the <code class="literal">Resolved</code> state.  After Web Server successfully starts the plan, it is listed in the <code class="literal">Active</code> state. </p></td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">stop <span class="emphasis"><em>name version</em></span></td><td style="border-bottom: 1.0pt solid ; ">Stops the specified plan.  You must specify both the full name of the plan as well as the version you want to stop. Use the <code class="literal">plan list</code> subcommand to get the list of plans currently installed in Web Server.
 				  <p>When you stop a plan, it goes from the <code class="literal">Active</code> state to the <code class="literal">Resolved</code> state, and you must re-start it if you want to use the application that the plan contains.</p> </td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">refresh <span class="emphasis"><em>name version</em></span></td><td style="border-bottom: 1.0pt solid ; ">Updates the contents of the specified plan. You must specify both the name and version of the plan you want to refresh.  Use the <code class="literal">plan list</code> subcommand to this information.
 				<p>Use this subcommand if you have changed the contents of the plan file and you want to refresh the artifact as installed in the OSGi framework.</p></td></tr><tr><td style="border-right: 1.0pt solid ; ">uninstall <span class="emphasis"><em>name version</em></span></td><td style="">Uninstalls the specified plan. You must specify both the name and version of the plan you want to refresh.  Use the <code class="literal">plan list</code> subcommand to this information.
 				  <p>When the uninstall process is complete, the plan will not show up in the list of plans displayed by the <code class="literal">plan list</code> subcommand.  If you want to use the application in the plan, you must re-install it using the <code class="literal">install</code> subcommand.</p></td></tr></tbody></table></div></div><br class="table-break"><p>The following example shows how to list the plans that have been installed in Web Server:</p><pre class="programlisting">osgi&gt; vsh plan list

 Name                                           Version                            State
 org.eclipse.virgo.apps.admin.plan              2.1.0                             ACTIVE
 org.eclipse.virgo.kernel.userregion.springdm   2.1.0                             ACTIVE
 org.eclipse.virgo.web                          2.1.0                             ACTIVE

 osgi&gt; </pre><p>The following example shows how to examine a particular plan:</p><pre class="programlisting">osgi&gt; vsh plan examine org.eclipse.virgo.kernel.userregion.springdm 2.1.0

 State:  ACTIVE
 Scoped: false
 Atomic: false

 Children:
     bundle org.eclipse.virgo.kernel.agent.dm 2.1.0.RELEASE
     bundle org.springframework.osgi.io 1.2.1
     bundle org.springframework.osgi.extender 1.2.1
     bundle org.springframework.osgi.core 1.2.1
     bundle org.eclipse.virgo.kernel.deployer.dm 2.1.0.RELEASE

 osgi&gt; </pre><p>The following example shows how to stop a currently Active plan:</p><pre class="programlisting">osgi&gt; vsh plan stop org.eclipse.virgo.web 2.1.0

 plan org.eclipse.virgo.web:2.1.0 stopped successfully

 osgi&gt; </pre><p>The following example shows how to start a plan:</p><pre class="programlisting">osgi&gt; vsh plan start org.eclipse.virgo.web 2.1.0

 plan org.eclipse.virgo.web:2.1.0 started successfully

 osgi&gt; </pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="admin-shell-service-command"></a>service Subcommand</h3></div></div></div><p>Use the <code class="literal">service</code> subcommand to view all the services that have been registered in the OSGi service registry of Web Server. You can also examine a specific service to discover its properties, the bundle that publishes the service, and any bundles that consume the service.</p><p>The following table lists the options you can specify for this subcommand.</p><div class="table"><a name="admin-shell-service-command-table"></a><p class="title"><b>Table&nbsp;6.7.&nbsp;Options of the service Subcommand</b></p><div class="table-contents"><table summary="Options of the service Subcommand" style="border-collapse: collapse;border-top: 1.0pt solid ; border-bottom: 1.0pt solid ; border-left: 1.0pt solid ; border-right: 1.0pt solid ; "><colgroup><col><col></colgroup><thead><tr><th style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Option </th><th style="border-bottom: 1.0pt solid ; ">Description</th></tr></thead><tbody><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">list</td><td style="border-bottom: 1.0pt solid ; ">Displays the list of services that are currently registered in the OSGi service registry of Web Server.
 				  <p>Each service is identified by an internal <code class="literal">ID</code> which you can then use with the <code class="literal">service examine</code> subcommand to view the details about a particular service. The <code class="literal">list</code> option also displays the object class that implements the service and the internal <code class="literal">id</code> of the bundle that provides the service. </p></td></tr><tr><td style="border-right: 1.0pt solid ; ">examine <span class="emphasis"><em>id</em></span></td><td style="">Displays detailed information about the specified service.  Use the <code class="literal">service list</code> subcommand to get the internal id of a particular service.
 				<p>This subcommand displays the properties of the service, such as the object class that implements the service, the name of the bundle that publishes the service and any bundles that consume the service. </p></td></tr></tbody></table></div></div><br class="table-break"><p>The following example shows how to list the services currently registered in the OSGi service registry:</p><pre class="programlisting">osgi&gt; vsh service list

 Id  Object Class(es)                                            Providing Bundle

 1   org.osgi.service.packageadmin.PackageAdmin                                 0
 2   org.osgi.service.permissionadmin.PermissionAdmin, ...                      0
 3   org.osgi.service.startlevel.StartLevel                                     0
 4   org.eclipse.osgi.service.debug.DebugOptions                                0
 5   java.lang.ClassLoader                                                      0
 6   org.eclipse.osgi.framework.log.FrameworkLog                                0
 7   org.eclipse.osgi.framework.log.FrameworkLog                                0
 &lt;... remainder omitted ...&gt;

 72 org.eclipse.gemini.web.core.spi.ServletContainer                           38
 73 org.eclipse.gemini.web.core.WebContainer                                   37
 74 org.eclipse.virgo.web.core.WebApplicationRegistry                          39
 &lt;... remainder omitted ...&gt;

 osgi&gt; </pre><p>The following example shows how to examine a particular service:</p><pre class="programlisting">osgi&gt; vsh service examine 73

 		Properties:
 		    objectClass:
 		        org.eclipse.gemini.web.core.WebContainer
 		    service.id:
 		        73

 		Publisher: org.eclipse.gemini.web.core 1.1.0.RELEASE [37]

 		Consumer(s):
 		    org.eclipse.virgo.web.core 2.1.0.RELEASE [39]

 		osgi&gt; </pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="admin-shell-install-command"></a>install Subcommand</h3></div></div></div><p>Use the <code class="literal">install</code> subcommand to deploy an artifact to Web Server.  The artifact can be a bundle, PAR, plan, or configuration artifact.</p><p>The <code class="literal">install</code> subcommand takes a single parameter: the URI of the artifact you want to deploy.  For example, to deploy a bundle on the local computer, use the <code class="literal">file</code> scheme:</p><pre class="programlisting">file://full-pathname-to-artifact</pre><p>After you execute the <code class="literal">install</code> subcommand, Web Server attempts to resolve the artifact's dependencies, and if it is successful, puts it in the <code class="literal">Resolved</code> state.  At that point, you must start the artifact to be able to actually use it. </p><p>The following example shows how to install a bundle called <code class="literal">swf-booking-mvc.war</code> located in the <code class="literal">/home/apps</code> directory of the computer on which the Equinox Console Extension is being run:</p><pre class="programlisting">:&gt; install file://home/apps/swf-booking-mvc.war

 Artifact bundle swf-booking-mvc.war 0.0.0 installed</pre><p>The following example shows how to use the <code class="literal">bundle list</code> subcommand to ensure that the bundle was indeed installed to Web Server; if you had installed a different kind of artifact, for example a plan, then you would use the appropriate subcommand (such as <code class="literal">plan list</code>):</p><pre class="programlisting">osgi&gt; vsh bundle list

 Id   Name                             Version                   State

 0    org.eclipse.osgi                 3.6.1.R36x_v20100806     ACTIVE
 1    org.eclipse.virgo.region.user    0.0.0                    ACTIVE
 &lt;... remainder omitted ...&gt;

 59   org.eclipse.virgo.server.splash   2.1.0.RELEASE           ACTIVE
 60   swf-booking-mvc.war              0.0.0                  RESOLVED

 osgi&gt; </pre><p>Note that the <code class="literal">swf-booking-mvc.war</code> file is in the <code class="literal">Resolved</code> state.   The following examples start the bundle, and then examine it to ensure that it is in the <code class="literal">Active</code> state:</p><pre class="programlisting">osgi&gt; vsh bundle start 60

 bundle swf-booking-mvc.war:0.0.0 started successfully


 osgi&gt; vsh bundle examine 60

 Id:              60
 Name:            swf-booking-mvc.war
 Version          0.0.0
 State:           ACTIVE
 Spring Powered:  true
 Bundle Location: file:&lt;... omitted ...&gt;/swf-booking-mvc.war/

 Imported Packages:
     javax.crypto.interfaces [0.0.0, 0.0.0]
         exported by org.eclipse.osgi 3.6.1.R36x_v20100806 [0]
     org.omg.CosNaming.NamingContextPackage [0.0.0, 0.0.0]
         exported by org.eclipse.osgi 3.6.1.R36x_v20100806 [0]
     org.omg.DynamicAny.DynAnyFactoryPackage [0.0.0, 0.0.0]
         exported by org.eclipse.osgi 3.6.1.R36x_v20100806 [0]
     &lt;... remainder omitted ...&gt;

 osgi&gt; </pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="admin-shell-shutdown-command"></a>shutdown Subcommand</h3></div></div></div><p>Use the <code class="literal">shutdown</code> subcommand to shut down the Web Server instance to which you are connected. When Web Server is shutdown, the shell returns you to the operating system prompt. </p><p>The <code class="literal">shutdown</code> subcommand does not have any options.</p><p>The following example shows how to use this subcommand.</p><pre class="programlisting">:&gt; shutdown

 Shutdown MBean called
 prompt$</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="admin-shell-help-command"></a>help Subcommand</h3></div></div></div><p>Use the <code class="literal">help</code> subcommand on its own to get a list of all available Equinox Console Extension subcommands.  If you specify a particular subcommand to the <code class="literal">help</code> subcommand, then you will get the list of options that you can pass to the subcommand. </p><p>For example:</p><pre class="programlisting">osgi&gt; vsh help


     bundle   - Management and examination of bundle artifacts
     config   - Management and examination of configuration artifacts
     exit     - Exit the kernel shell environment
     help     - Get help on commands
     install  - Install (deploy) an artifact to the server
     package  - Examination of exported packages
     par      - Management and examination of PAR artifacts
     plan     - Management and examination of plan artifacts
     service  - Examination of services
     shutdown - Shutdown Virgo Kernel


 osgi&gt; vsh help bundle

 bundle list                            - List all bundle artifacts that are
                                          currently installed
 bundle examine   [ id | name version ] - Examine a bundle artifact
 bundle start     [ id | name version ] - Start a bundle artifact. Starting this
                                          artifact starts it in the OSGi
                                          framework.
 bundle stop      [ id | name version ] - Stop a bundle artifact. Stopping this
                                          artifact stops it in the OSGi
                                          framework.
 bundle refresh   [ id | name version ] - Refresh a bundle artifact. Refreshing
                                          this artifact updates its contents in
                                          the OSGi framework.
 bundle uninstall [ id | name version ] - Uninstall a bundle artifact
 bundle diag      [ id | name version ] - Provide diagnostics for a bundle
                                          artifact
 bundle headers   [ id | name version ] - Show the headers for a bundle artifact

 osgi&gt; </pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="admin-shell-exit-command"></a>exit Subcommand</h3></div></div></div><p>This returns to the Equinox console and otherwise has no effect.</p><p>The <code class="literal">exit</code> subcommand does not have any options.</p></div></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="admin-console"></a>7.&nbsp;The Web Admin Console</h2></div></div></div><p>The Web Server Admin Console is a Web application for managing a single instance of Web Server.  Using the Admin Console, you can:</p><div class="itemizedlist"><ul type="disc"><li><p><a class="link" href="#admin-console-login" title="7.1&nbsp;Invoking the Admin Console">View an overview of the Web Server properties</a>.</p></li><li><p><a class="link" href="#admin-console-manage-artifacts" title="Viewing and Managing the Lifecycle of Deployed Artifacts">View and manage the lifecycle</a> of artifacts already deployed to the Web Server instance.  Artifacts include bundles, configuration files, PARs, and plans.  Lifecycle management tasks include starting, stopping, refreshing, and uninstalling the artifacts.</p></li><li><p><a class="link" href="#admin-console-install-artifacts" title="Installing a New Artifact">Install new artifacts to Web Server</a>.</p></li><li><p><a class="link" href="#admin-console-view-properties" title="Viewing Properties of Deployed Configuration Artifacts">View the properties of the configuration artifacts</a> deployed to Web Server.</p></li><li><p><a class="link" href="#admin-console-view-dumps" title="Viewing the Details of Dump Files">View details of dump files</a> that Web Server might have generated after encountering a problem.  This feature is particularly valuable if Web Server fails to install a new artifact due to resolution failures; the dump inspector can help you discover the exact artifact causing the resolution failure.</p></li><li><p><a class="link" href="#admin-console-view-osgi-state" title="Viewing Overview and Details of the OSGi State">View an overview and details of the OSGi State</a> of Web Server, or in other words, a list of all bundles currently installed in Web Server and their state.  You can then drill down into the details of each bundle, such as its symbolic name, packages it imports and exports, services it provides and consumes, and so on.  You can also view the bundles that were deployed when an exception that generated a dump occurred.</p></li></ul></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="admin-console-login"></a>7.1&nbsp;Invoking the Admin Console</h2></div></div></div><p>
 			To use the Admin Console, start the
 			Virgo Web Server and then enter the following URL in your
 			browser of choice.
 		</p><pre class="screen">http://localhost:8080/admin</pre><p>
 			Replace <code class="literal">localhost</code> with the hostname of the computer on which the Virgo Web Server is running if it is not the same as the computer on which you are running your browser.  </p><p>The Admin Console uses basic authentication, therefore you will need to enter the default administration ID and password.
 		</p><pre class="screen">ID: admin
 Password: springsource</pre><p>The following graphic shows the main page of the Admin Console.
 		</p><div class="mediaobject" align="right"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0"><tr><td align="right" valign="bottom"><img src="images/console-main-page.png" align="right"></td></tr></table></div><p>

 		</p><p>Use the links at the top of the console to perform various tasks, such as viewing and managing artifacts (<span class="bold"><strong>Artifacts</strong></span>), viewing the properties of deployed configuration artifacts (<span class="bold"><strong>Configuration</strong></span>), viewing details of dumps (<span class="bold"><strong>Dump Inspector</strong></span>), and viewing the OSGi state of the Web Server instance (<span class="bold"><strong>OSGi State</strong></span>).</p><p>You can always return to the main Admin Console page by clicking <span class="bold"><strong>Information</strong></span> in the top right-hand corner.</p><p>The <code class="literal">Server Properties</code> section provides information about Web Server itself, such as details about the Java Virtual Machine (JVM), the operating system on which Web Server is installed, the time zone configured for the computer, and the complete version of Web Server.</p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="admin-console-auth"></a>Changing the Admin User</h3></div></div></div><p>
 			To change the ID and password for the Admin Console, update the <code class="literal">SERVER_HOME/config/org.eclipse.virgo.kernel.users.properties</code> file.  First specify the administration username by changing the value of the <code class="literal">role.admin</code> property.  Then set the password of this new user by adding a new property called <code class="literal">user.<span class="emphasis"><em>username</em></span></code>, where <code class="literal"><span class="emphasis"><em>username</em></span></code> refers to the actual name of the user.  Finally, restart Web Server for the changes to take effect.</p><p>For example, if you want change the administration username to <code class="literal">juliet</code> with password <code class="literal">capulet</code>, change the file as follows:
 		</p><pre class="programlisting">##################
 # User definitions
 ##################
 user.juliet=capulet


 ##################
 # Role definitions
 ##################
 role.admin=juliet</pre><p>
 			The Admin Console always runs against the <code class="literal">admin</code> role.
 		</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="admin-console-tasks"></a>7.2&nbsp;Typical Admin Console Use Cases</h2></div></div></div><p>The following use cases describe the typical tasks that you can perform with the Web Server Admin Console:</p><div class="itemizedlist"><ul type="disc"><li><a class="link" href="#admin-console-manage-artifacts" title="Viewing and Managing the Lifecycle of Deployed Artifacts">View and Manage the Lifecycle of Deployed Artifacts</a></li><li><a class="link" href="#admin-console-install-artifacts" title="Installing a New Artifact">Install a New Artifact</a></li><li><a class="link" href="#admin-console-view-properties" title="Viewing Properties of Deployed Configuration Artifacts">View the Properties of Deployed Configuration Artifacts</a></li><li><a class="link" href="#admin-console-view-dumps" title="Viewing the Details of Dump Files">View Details of Dump Files</a></li><li><a class="link" href="#admin-console-view-osgi-state" title="Viewing Overview and Details of the OSGi State">View Overview and Details of the OSGi State</a></li></ul></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="admin-console-manage-artifacts"></a>Viewing and Managing the Lifecycle of Deployed Artifacts</h3></div></div></div><p>The following procedure describes how to view the list of artifacts that are currently deployed in the user region of Web Server.  It then describes how to stop, start, refresh, and uninstall the deployed artifacts.</p><div class="orderedlist"><ol type="1"><li><p>From the main Admin Console page, click the <span class="bold"><strong>Artifacts</strong></span> link at the top.</p><p>In the lower part of the page, the console displays a tree structure that displays the four kinds of artifacts that you can deploy to the user region of Web Server: bundles, configuration files, PARs, and plans.  When you first install Web Server, there will already be a number of artifacts deployed related to the Admin console itself, the main splash screen, the repository, and so on.  </p><p>The following graphic shows an expanded tree that displays a few of the deployed artifacts:</p><p><img src="images/console-artifacts.png"></p></li><li><p>To view details of a particular artifact, click the "+" to the left of the artifact to expand the tree.  The following graphic shows an expanded <code class="literal">org.eclipse.virgo.apps.admin.web</code> bundle:</p><p><img src="images/console-bundle-details.png"></p><p>The particular details that the Admin Console displays depends on the artifact.  For example, for all artifacts you can view their state and how it was installed (such as by a user using the Admin Console or programmatically).  The two most common states are Active (running and ready to be used) and Resolved (all dependencies resolved but you must start it before you can use it.)  An artifact can also be in one of the transition states, such as Starting and Stopping.  </p><p>As shown in the preceding graphic, the Admin Console provides a link for Web modules that you can click on to actually invoke the application (<code class="literal">org.eclipse.virgo.web.contextPath:/admin</code> in the example above.)</p><p>For PARs and plans, the Admin Console also displays whether the artifact is:</p><div class="itemizedlist"><ul type="disc"><li><span class="bold"><strong>Scoped</strong></span>. Scoping specifies whether Web Server should deploy the members of the PAR/plan in their own scope; when scoping is disabled, Web Server deploys the artifacts into the global scope and they are accessible by all other artifacts.</li><li><span class="bold"><strong>Atomic</strong></span>. When a PAR/plan is atomic, Web Server manages the lifecycle of all its member artifacts as a single entity, which means if one artifact member is started, then Web Server starts all the PAR/plan artifacts. If one artifact fails to start, then Web Server stops all other artifacts in the PAR/plan.</li></ul></div><p>The following graphic shows details of a PAR, in particular that it is both scoped and atomic:</p><p><img src="images/console-par-details.png"></p><p>Finally, for bundles, PARs, and plans, you can see the list of bundles that they depend on; this typically means the bundles that export the packages that they import.</p></li><li><p>To manage the lifecycle of an artifact, click on its name in the expanded tree to enable the lifecycle buttons.   Then, depending on the current state of the artifact, you can: </p><div class="itemizedlist"><ul type="disc"><li>Start the artifact.  All dependencies of the artifact must have been resolved for you to start it.  After successfully starting the artifact, it is in the Active state and you can use the application associated with the artifact.</li><li>Stop the artifact.  This moves the artifact from an Active to Resolved state, and you cannot use the application associated with the artifact.  </li><li>Refresh the artifact.  This action updates the physical contents of the artifact; use this button when you have changed the artifact in some way and you want your changes to take effect.</li><li>Uninstall the artifact.  This action removes the artifact from Web Server and it does not show up in the Admin Console any more.  To use the application associated with this artifact, you must re-install the artifact.</li></ul></div></li></ol></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="admin-console-install-artifacts"></a>Installing a New Artifact</h3></div></div></div><p>The following procedure describes how to install a new artifact (bundle, PAR, plan, or configuration file.)  The procedure is similar for all types of artifacts; the procedure uses a WAR file as an example.</p><div class="orderedlist"><ol type="1"><li><p>From the main Admin Console page, click the <span class="bold"><strong>Artifacts</strong></span> link at the top.</p></li><li><p>Click the <span class="bold"><strong>Browse</strong></span> button to invoke the file loader application for your platform.  Note that the Browse button searches the computer that is running the browser in which you invoked the Admin Console and <span class="emphasis"><em>not</em></span> the computer on which Web Server is running, in the case where they are different.</p><p>Use the file loader to find the artifact.  This can be a WAR file bundle, a configuration artifact that contains properties, an XML file that corresponds to a plan, or a PAR file.</p></li><li><p>Click <span class="bold"><strong>Upload</strong></span> to actually upload the artifact to Web Server.  </p><p>Web Server automatically attempts to resolve all dependencies, and then puts the artifact in an Active state if possible.  If all is successful, the message <code class="literal">Artifact Deployed</code> appears next to the <span class="bold"><strong>Artifact Console</strong></span> header.    If there is an error, a message to that effect is displayed; to get more details about the error, see the terminal window from which you started Web Server.</p></li><li><p>Expand the artifact tree to view your newly deployed artifact.  If Web Server installed it without errors, it should show up in the appropriate section and be in an Active state.</p></li></ol></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="admin-console-view-properties"></a>Viewing Properties of Deployed Configuration Artifacts</h3></div></div></div><p>The following procedure describes how you can view the list of configuration artifacts that are currently deployed to Web Server, and then view the specific properties that are defined for a particular configuration artifact.  </p><div class="orderedlist"><ol type="1"><li><p>From the main Admin Console page, click the <span class="bold"><strong>Configuration</strong></span> link at the top.</p><p>The Admin Console displays all the configuration artifacts that are currently deployed, as shown in the following graphic:</p><p><img src="images/console-configuration-details.png"></p></li><li><p>To view the properties defined for a particular configuration artifact click the arrow to the left of its name. </p></li></ol></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="admin-console-view-dumps"></a>Viewing the Details of Dump Files</h3></div></div></div><p>The following procedure describes how to view the details of any service dumps that have occurred in Web Server.   Each time a dump is triggered for Web Server, the server creates a directory in <code class="literal">$SERVER_HOME/serviceability/dump</code> with a name corresponding to the time the dump occurred, and then the server populates the directory with detailed information.  Using the Admin Console, you can easily view this information.</p><p> A service dump is triggered when there is either a failure in the Web Server code or Web Server detects a thread deadlock in either its own code or a user application.  The service dump contains a snapshot of all the important state from the running Web Server instance. <span class="bold"><strong>NOTE:</strong></span> This snapshot is not intended for end user consumption but is useful for service personnel.</p><div class="orderedlist"><ol type="1"><li><p>From the main Admin Console page, click the <span class="bold"><strong>Dump Inspector</strong></span> link at the top.</p></li><li><p>In the drop-down box on the left, select the dump you want to inspect based on its timestamp.</p></li><li><p>Click <span class="bold"><strong>Select Dump</strong></span>.</p></li><li><p>In the right drop-down box, select the type of dump information you want to view.</p><p>For example, <code class="literal">summary.txt</code> provides a short summary of why the dump might have occurred.  The <code class="literal">thread.txt</code> option provides information about the state of the Web Server threads at the time of the dump, including any that were deadlocked.  The <code class="literal">repository</code> options provide information about what was in the external and user repositories at the time of the dump. The <code class="literal">configurationAdmin.properties</code> option provides a snapshot of the complete configuration of Web Server, including the kernel and repositories.</p></li><li><p>Click <span class="bold"><strong>Select Entry</strong></span>.</p><p>The Admin Console displays the information in the Dump Entry Viewer, as shown in the following graphic:</p><p><img src="images/console-dump-details.png"></p></li></ol></div><p>
 			Note that the dump entry <code class="literal">osgi.zip</code> is a binary OSGi state dump which should be viewed as described in
 			<a class="link" href="#admin-console-view-osgi-state" title="Viewing Overview and Details of the OSGi State">Viewing Overview and Details of the OSGi State</a>.
 		</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="admin-console-view-osgi-state"></a>Viewing Overview and Details of the OSGi State</h3></div></div></div><p>
 			The following procedure describes how you can view the OSGi state of the Web Server, either currently or at the time that a particular service dump
 			occurred.
 		</p><p>
 			The OSGi state is a list of bundles that are currently installed. When viewing the current state, additional information is available
 			such as whether each bundle is Spring powered and a list of services in the OSGi service registry. This additional information is not available
 			when viewing a state dump.
 		</p><div class="orderedlist"><ol type="1"><li><p>From the main Admin Console page, click the <span class="bold"><strong>OSGi State</strong></span> link at the top.</p><p>By default, the Admin Console displays the complete list of bundles that are currently installed in Web Server.</p><p>For each bundle, the console displays its internal ID, its symbolic name, its version, and its current state (usually either Active or Resolved.)</p></li><li><p>To view the bundles that were installed at the time of a service dump, select the service dump based on its timestamp from the drop-down box on the
 			right and click <span class="bold"><strong>Go</strong></span>. </p></li><li><p>To view details about a particular bundle, click on its bundle ID. A full description of the bundle is displayed, as shown in the following graphic:</p><p><img src="images/console-osgi-state.png"></p><p>The console displays again the symbolic name, version, and internal ID of the bundle. It then displays whether the bundle is Spring powered and the exact physical location of the bundle JAR file on the computer that hosts Web Server.</p><p>The console then displays the full list of packages that the bundle imports, as well as the bundles that in turn export these imported packages. The console also displays the packages that the current bundle exports, and then in turn the list of other installed bundles that are currently importing these exported packages. For each package, you can drill down and view details of the corresponding bundle.</p><p>Similarly, the console displays the consumed and provided OSGi services.  </p><p>Finally, the console also displays information about the Spring context, if the bundle is Spring powered.  </p></li><li><p>To view the full list of OSGi services, click the <code class="literal">Services Overview</code> link from the main OSGi state page</p></li><li><p>Typically, the list of bundles and services can be very long, making it difficult to find a particular bundle.  Use the <span class="bold"><strong>Search</strong></span> box at the top right corner to narrow down the list of displayed bundles.</p></li></ol></div></div></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="repository"></a>8.&nbsp;The Provisioning Repository</h2></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="repository-introduction"></a>8.1&nbsp;Overview of the Provisioning Repository</h2></div></div></div><p>
 				This section describes the provisioning repository feature of Virgo Web Server, the reasons for using it, and how to configure it.
 			</p><p>
 				In most use cases, your application has a dependency on one or more separate artifacts; these artifacts might include OSGi bundles, configuration artifacts, third-party libraries, PARs or plans.  A typical example is a Spring application that depends on a third-party library such as Spring Framework or Hibernate.
 			</p><p>
 				The way you express this dependency depends on the artifact.  For example, a plan is by definition a list of dependent bundles.
 			</p><p>
 				Libraries are another example.  Some third-party dependencies consist of multiple bundles but are logically one unit.  To support this, the Virgo Web Server introduces the concept of a library.  A library is a collection of related bundles that can be referenced as a whole.  You typically express the dependencies between your application and third-party libraries using the <code class="literal">Import-Package</code>, <code class="literal">Import-Bundle</code>, or <code class="literal">Import-Library</code> manifest header in the <code class="literal">MANIFEST.MF</code> file of your application.  The <code class="literal">Import-Package</code> header is standard to OSGi; <code class="literal">Import-Bundle</code> and <code class="literal">Import-Library</code>, however, are specific to Virgo Web Server.
 			</p><p>
 				For additional details about the creation and usage of libraries, as well as general information about dependencies, see <a class="ulink" href="../../programmer-guide/html/index.html" target="_top">Programmer&#8217;s Guide</a>.
 			</p><p>
 				In Virgo Web Server, you store all third-party dependencies required by your applications, such as Spring Framework and Hibernate, as artifacts in the provisioning repository.   As mentioned above, you can store the following types of artifacts in the repository:
 			</p><div class="itemizedlist"><ul type="disc"><li>OSGi bundles</li><li>Libraries</li><li>PARs</li><li>Plans</li><li>Configuration Artifacts</li></ul></div><p>
 				When you deploy your application,  Virgo Web Server installs the bundle(s) comprising the application to the VWS runtime; part of this internal installation procedure is to satisfy all the application&#8217;s dependencies.  If your application has a dependency that cannot be satisfied from the bundles that you have already deployed (and VWS has thus installed), then VWS searches the provisioning repository for an artifact that can satisfy that dependency.
 			</p><p>
 				The provisioning repository for a particular instance of Virgo Web Server can include artifacts in the following general locations:
 			  </p><div class="itemizedlist"><ul type="disc"><li>Local: This means that artifacts have been physically installed in the provisioning repository directory structure of the local Virgo Web Server instance.   The artifacts in a local repository include installed third-party libraries, bundles supplied by VWS, bundles supplied by an end user, and internal bundles used only by VWS.  You can further categorize this location into <code class="literal">external</code> directories that adhere to a specified search pattern and are scanned by VWS just on a clean startup, or <code class="literal">watched</code> directories that point to a single directory location and which VWS scans on a regular basis.  </li><li>Remote: This means that a local instance of Virgo Web Server gets the artifact from a remotely-hosted repository that is physically located on a remote Virgo Web Server instance.  </li></ul></div><p>
 			You configure the provisioning repository using the <code class="literal">$SERVER_HOME/config/org.eclipse.virgo.repository.properties</code> file.
 			</p><p> As previously described, a particular instance of Virgo Web Server can itself also act as a repository host for remote server instances to use when satisfying the dependencies of the applications deployed to it.  In this case, you configure a hosted repository using the <code class="literal">$SERVER_HOME/config/org.eclipse.virgo.repository.hosted.properties</code> file.  Typically, only remote clients use hosted repositories and their contents; the Virgo Web Server instance that actually hosts the repository does not typically use the artifacts in it.  Rather, it uses artifacts in its local repository.
 			</p><p>
 				Making a third-party dependency available to your application is simply a matter of adding its artifact to the appropriate location in the provisioning repository.  This could be either in the local directories or the remote ones if you are getting artifacts from a remotely-hosted repository.
 			</p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="repository-structure"></a>Local Repository Structure</h3></div></div></div><p>
 				When you first install Virgo Web Server, the local provisioning repository is located at <code class="literal">$SERVER_HOME/repository</code> by default and consists of two main directories: <code class="literal">ext</code> and <code class="literal">usr</code>.  The <code class="literal">ext</code> directory contains artifacts supplied with the Virgo Web Server and <code class="literal">usr</code> contains artifacts supplied by the user.
 			</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="repository-installing-bundles"></a>Installing Artifacts to a Repository</h3></div></div></div><p>
 				To install an artifact into the default repository, simply copy it into the <code class="literal">$SERVER_HOME/repository/usr</code> directory.
 			</p><p>If you have configured additional watched or external repositories (additional, that is, to the default ones already configured in a freshly-installed VWS instance), you install the artifacts in the same way: simply copy the files to the configured directories.  You configure additional watched or external repositories in the same file as the default repositories: <code class="literal">$SERVER_HOME/config/org.eclipse.virgo.repository.properties</code>.
 			</p><p>When you install a plan or a library, you must ensure that all referenced artifacts within the plan or library have been installed as well.
 			</p><p>Artifacts must have unique names so it is considered best practice to include the version number in the file name,
 			allowing for multiple versions of the artifact to be installed at the same time.   For example, a bundle file name might be <code class="literal">my-exciting-bundle.2.1.0.jar</code>.
 			</p><p>
 				For watched repositories, such as <code class="literal">$SERVER_HOME/repository/usr</code>, the Virgo Web Server automatically detects changes
 				at runtime, thereby avoiding the need to restart the VWS.
 			</p><p>
 				Of specific relevance during development is picking up changes to an application&#8217;s direct dependencies during deployment of the application.  For example, if you deploy an application and receive a message that a dependency is missing, you can simply add the dependency to the repository and then redeploy the application.  The redeploy will cause the new dependency to be picked up, allowing progress to be made without restarting the VWS.  For other changes such as addition of optional dependencies, the Virgo Web Server must be restarted to pick up any changes to the provisioning repository.
 			</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="repository-brits"></a>8.2&nbsp;Finding and Downloading Bundles from the SpringSource Enterprise Bundle Repository</h2></div></div></div><p>
 		    The SpringSource Enterprise Bundle Repository is a public collection of open source libraries commonly used for developing enterprise Java applications with the Spring Framework and VWS.  It contains hundreds of the most popular enterprise Java libraries made available for general use in an OSGi-ready format.  You can browse the collection and then download the bundles that you need into your own local repository.
 		</p><p>
 			The SpringSource Enterprise Bundle Repository is located <a class="ulink" href="http://www.springsource.com/repository" target="_top">here</a>.
 		</p><p>
 			<img src="images/bundle-repository.png">
 		</p><p>
 			You can find bundles in the repository using a number of options.  You use the &#8216;Search&#8217; facility by typing in a keyword.  The matching criteria returned can be explored by name, symbolic name, class, package or resource.
 		</p><p>
 			There is also the option of clicking on &#8216;Browse by Bundle&#8217;.  This gives an alphabetical list of bundles.  You can select the desired bundle to see details and find the download link.  Finally, you can also choose to &#8216;Browse by Library&#8217;, which allows you to browse the alphabetical list of libraries in the repository.
 		</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="repository-configuration"></a>8.3&nbsp;Configuring the repository</h2></div></div></div><p>Details of how to configure a Virgo Web Server installation&#8217;s provisioning repository can be found in <a class="link" href="#configuring-provisioning-repository" title="11.4&nbsp;Configuring the Local Provisioning Repository">Configuring the Provisioning Repository</a>.  See <a class="link" href="#configuring-hosted-repo" title="11.5&nbsp;Configuring a Hosted Repository">Configuring a Hosted Repository</a> for details on how to configure a repository that remote clients can access, also called a hosted repository.
 		</p><p>
 			The two configuration chapters describe the format of the repository properties files of Virgo Web Server, how to add new directories to the local repository, how to configure the repository to get artifacts from a remote repository hosted on a remote VWS instance, and how to configure the local VWS instance to itself host a repository that other remote servers access.
 		</p></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="serviceability"></a>9.&nbsp;Serviceability</h2></div></div></div><p>
 	Virgo Web Server supports two kinds of logging: <span class="emphasis"><em>Event Logging</em></span> and <span class="emphasis"><em>Trace logging</em></span> which is usually referred
 	to simply as <span class="emphasis"><em>Logging</em></span>. The difference between Event Logging and Logging is explained below, but both are configured in the <code class="literal">serviceability.xml</code> file in the <code class="literal">config</code> directory.
 This file takes the form of a Logback configuration&#8212;VWS
 uses a Logback implementation behind the SLF4J logging interface.
 </p><p>
 For a description of the syntax and facilities provided by <code class="literal">serviceability.xml</code>
 see the <span class="emphasis"><em>Logback</em></span> documentation (referenced in <a class="xref" href="#furtherreading" title="Appendix&nbsp;C.&nbsp; Further Reading">Appendix&nbsp;C, <i>
 		Further Reading
 	</i></a>).
 </p><p>
 </p><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="serviceability-info-log"></a>9.1&nbsp;Event logging</h2></div></div></div><p>
         Event logging records important events in Virgo Web Server. Each event is logged to
  		an event log file and is accompanied by a code enclosed in angle brackets.
  		An example is shown below:
 </p><pre class="screen">
 [2010-10-25 16:20:45.897] system-artifacts             &lt;TC0010I&gt; Creating HTTP/1.1 connector with scheme http on port 8080.
 </pre><p>
 		(For a description of the log code syntax, see <a class="xref" href="#log-codes" title="Appendix&nbsp;A.&nbsp;Event log codes">Appendix&nbsp;A, <i>Event log codes</i></a>.)
         The format of event log messages is fully configurable.
       </p><p>
 		    By default, event log messages are stored in <code class="literal">$SERVER_HOME/serviceability/eventlogs/eventlog.log</code>.
       	</p><p>
 			The default behaviour is that, once <code class="literal">eventlog.log</code> reaches a 10Mb limit, it rolls into a series of files named
 			<code class="literal">eventlog_</code><span class="emphasis"><em>i</em></span><code class="literal">.log</code> where <span class="emphasis"><em>i</em></span> ranges from 1 to 4, and event logging continues in
 			a new <code class="literal">eventlog.log</code> file.
 		</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="serviceability-info-trace"></a>9.2&nbsp;(Trace) Logging</h2></div></div></div><p>
 	    The Virgo Web Server&#8217;s (trace) logging support serves two main purposes:
 	    </p><div class="itemizedlist"><ul type="disc"><li>
 		    It provides global trace files that capture high-volume information regarding the Virgo Web Server&#8217;s internal events.
 		    The files are intended
 		    for use by support personnel to diagnose runtime problems.
 	      </li><li>
 		    It provides application trace files that contain application-generated output.
 		    This includes output generated using popular logging and
 		    tracing APIs, as well as output generated by calls to <code class="literal">System.out</code> and <code class="literal">System.err</code>.
 		    These files are
 		    intended for use by application developers and system administrators.
 		  </li></ul></div><p>
         </p><p>
 		    By default, the VWS trace file is called
 		    <code class="literal">$SERVER_HOME/serviceability/logs/log.log</code>,
 		    and, again by default, the application trace files are called
 		    <code class="literal">$SERVER_HOME/serviceability/logs/</code><span class="emphasis"><em>application_name</em></span><code class="literal">/log.log</code>,
             where <span class="emphasis"><em>application_name</em></span> is automatically set by VWS for each application artifact installed and run
             (it is a combination of the artifact name and the version).
         </p><p>
 			The default behaviour of these trace files is that, once <code class="literal">log.log</code> reaches a 10Mb limit, it rolls into a series of files named
 			<code class="literal">log_</code><span class="emphasis"><em>i</em></span><code class="literal">.log</code> where <span class="emphasis"><em>i</em></span> ranges from 1 to 4, and logging continues in
 			a new <code class="literal">log.log</code> file.
 		</p><p>
 		Entries in trace files are by default of the form &lt;timestamp&gt; &lt;thread-name&gt; &lt;source&gt; &lt;level&gt; &lt;entry-text&gt;. For example:
 		</p><pre class="screen">
 [2008-05-15 09:09:46.940] server-dm-2 org.apache.coyote.http11.Http11Protocol I Initializing Coyote HTTP/1.1 on http-48080
 	    </pre><p>
         although this format is completely determined by the Logback configuration file <code class="literal">serviceability.xml</code>.
       </p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="serviceability-info-trace-app"></a>Application Output</h3></div></div></div><p>
 			Virgo Web Server provides advanced support for capturing and tracing application-generated output by automatically separating trace output on a
 			per-application basis and will also capture any <code class="literal">System.out</code> and <code class="literal">System.err</code> output.
 		</p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="per-application-trace"></a>Per-application trace</h4></div></div></div><p>
 				Virgo Web Server uses SLF4J interfaces to Logback, and the root logger (by default) captures all logging output
 				and appends it to the application-specific trace files as described above.
 				To modify this, define application-specific loggers in the <code class="literal">serviceability.xml</code> file in the normal way.
 			</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="sysout-and-syserr"></a>System.out and System.err</h4></div></div></div><p>
             <code class="literal">System.out</code> and <code class="literal">System.err</code> output from applications is, by default, captured in the
             application&#8217;s trace file.
             This happens because the output streams are intercepted and written to the loggers named
             <code class="literal">System.out</code> and <code class="literal">System.err</code> respectively.
 			Since there are no explicit loggers defined with these names in the <code class="literal">serviceability.xml</code> file,
 			this output is logged by the root logger (which captures <code class="literal">INFO</code> level and above).
           </p><p>
 			The capture of <code class="literal">System.out</code> and <code class="literal">System.err</code> output is configured in the
 			<code class="literal">config/org.eclipse.virgo.medic.properties</code> file by the <code class="literal">log.wrapSysOut</code> and
 			<code class="literal">log.wrapSysErr</code> properties. By default the properties have a value of <code class="literal">true</code>
 			and capture is enabled. Capture can be disabled by configuring the properties with a value of <code class="literal">false</code>.
 		  </p><p>
             The trace entries for <code class="literal">System.out</code> and <code class="literal">System.err</code>
 			output are of the form:
 		    </p><pre class="screen">
 [2008-05-16 09:28:45.874] server-tomcat-thread-1 System.out Hello world!
 [2008-05-16 09:28:45.874] server-tomcat-thread-1 System.err Hello world!
 			</pre><p>
 			The third column indicates where the output came from (<code class="literal">System.out</code> or <code class="literal">System.err</code>).
 		  </p><p>
 		  To over-ride this behaviour, simply define explicit loggers named <code class="literal">System.out</code>
 		  and/or <code class="literal">System.err</code> in the configuration file to send this output to an appender of your choice.
 		  Be aware that all applications&#8217; output streams will be caught by these loggers, and that a sifting appender might be useful to separate them.
 		  </p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="serviceability-info-dump"></a>9.3&nbsp;Service Dumps</h2></div></div></div><p>
         A service dump is triggered when one of the following events
         occurs:
       </p><div class="orderedlist"><ol type="1"><li><p>
             A failure is detected in the Virgo Web Server code, or
           </p></li><li><p>
             a thread deadlock is detected.
           </p></li></ol></div><p>
         A service dump contains a snapshot of all the important state from
         the running Virgo Web Server instance. This snapshot is not intended
         for end user consumption but is useful for service personnel.
       </p><p>
         By default, service dumps are created in
         <code class="literal">$SERVER_HOME/serviceability/dump</code>.
       </p></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="deployment"></a>10.&nbsp;Working with Applications</h2></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="deployment-deploying"></a>10.1&nbsp;Deploying Artifacts</h2></div></div></div><p>
 			In the context of Virgo Web Server, <span class="emphasis"><em>deploying</em></span> refers to installing an artifact to the server and then starting it to make it available to users.  Typically, when you install an artifact, VWS automatically starts it as long as the server is able to successfully resolve all its dependencies.  For this reason, the terms <span class="emphasis"><em>deploying</em></span> and <span class="emphasis"><em>installing</em></span> are often used interchangeably.
 		</p><p>You deploy artifacts to Virgo Web Server using either the hot-deploy directory on the file system or by using the Admin Console.  The artifacts that you can deploy to VWS are:
 		</p><div class="itemizedlist"><ul type="disc"><li>Bundles, including Web applications</li><li>PARs</li><li>Plans</li><li>Configuration Files</li></ul></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="deployment-deploying-hot"></a>Hot Deploy</h3></div></div></div><p>
 				To hot deploy an artifact, copy it into the pickup directory (by default <code class="literal">$SERVER_HOME/pickup</code>):
 			</p><pre class="programlisting">prompt$ cd /home/applications
 prompt$ cp helloWorld.war $SERVER_HOME/pickup</pre><p>
 				When the artifact is hot deployed, messages similar to the following appear in the log file:
 			</p><pre class="screen">[2009-12-10 06:41:01.021] fs-watcher          &lt;HD0001I&gt; Hot deployer processing 'CREATED' event for file 'helloWorld.war'.
 [2009-12-10 06:41:01.087] fs-watcher          &lt;DE0000I&gt; Installing bundle 'helloWorld' version '0.0.0'.
 [2009-12-10 06:41:01.274] fs-watcher          &lt;DE0001I&gt; Installed bundle 'helloWorld' version '0.0.0'.
 [2009-12-10 06:41:01.397] fs-watcher          &lt;DE0004I&gt; Starting bundle 'helloWorld' version '0.0.0'.
 [2009-12-10 06:41:01.414] Thread-3            &lt;WE0000I&gt; Starting web bundle 'helloWorld' version '0.0.0' with context path '/helloWorld'.
 [2009-12-10 06:41:01.537] Thread-3            &lt;WE0001I&gt; Started web bundle 'helloWorld' version '0.0.0' with context path '/helloWorld'.
 [2009-12-10 06:41:01.550] start-signalling-1  &lt;DE0005I&gt; Started bundle 'helloWorld' version '0.0.0'.</pre><p>
 				If there is a problem with the deployment, such as the server being unable to resolve all dependencies, the console and log both show an error message to help you with troubleshooting.
 			</p><p>If there are no problems, VWS automatically starts the artifact so that it is immediately available to users.
 			</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="deployment-deploying-manual"></a>Deploying Using the Admin Console</h3></div></div></div><p>
 				The Admin Console allows you to upload a file, which will be deployed automatically, from your local file system to the Virgo Web Server. As soon as Virgo Web Server deploys the artifact,  it appears in the list of artifacts in the Admin Console.  Note that the GUI for uploading varies according to the browser and operating system you use.
 			</p><p>See <a class="link" href="#admin-console-install-artifacts" title="Installing a New Artifact">Installing a New Artifact</a> for details about using the Admin Console to install (deploy) an artifact.  See <a class="link" href="#admin-console" title="7.&nbsp;The Web Admin Console">The Web Admin Console</a> for general information about the Admin Console.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="deployment-deploying-happens"></a>What Happens When You Deploy</h3></div></div></div><p>
 				When you deploy an artifact, either using hot-deployment or the Admin Console, Web Server copies the file to its work directory (<code class="literal">SERVER_HOME/work</code>) and registers it in its internal registry.
 				The server then checks any dependencies the artifact might have to see if
 				deployment can go ahead, and if all dependencies are resolved, Virgo Web Server starts the artifact.
 				Because of all these additional internal activities, you should NOT simply copy the artifact into the <code class="literal">work</code> directory and assume it will be deployed, because Virgo Web Server will not do so.
 			</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="deployment-deploying-ordering"></a>Deployment Ordering</h3></div></div></div><p>
 				When deploying bundles that have dependencies, it is important
 				that you deploy them in the correct order. Virgo Web Server
 				honors this ordering when it redeploys the artifacts on startup.
 			</p><p>
 				If you use hot deployment to deploy your artifacts, be sure to copy the corresponding files into the pickup
 				directory one-by-one. Copying the files in one group, for example by using a single <code class="literal">cp</code> command. provides no guarantees of ordering.
 			</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="deployment-deploying-restrictions"></a>Restrictions</h3></div></div></div><p>
 				Virgo Web Server does not support deploying fragment bundles. Typically, fragment bundles should be placed in <code class="literal">$SERVER_HOME/repository/ext</code>
 				or <code class="literal">$SERVER_HOME/repository/usr</code> so that they will be installed automatically with their host bundles.
 			</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="deployment-undeploy"></a>10.2&nbsp;Undeploying Artifacts</h2></div></div></div><p>
 			You undeploy artifacts from Virgo Web Server by using either the hot-deploy directory on the file system, or the Admin Console.
 		</p><p><span class="bold"><strong>Note:</strong></span>  As with deploying, in this guide the terms <span class="emphasis"><em>undeploying</em></span> and <span class="emphasis"><em>uninstalling</em></span> are used interchangeably.</p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="deployment-undeploy-hot"></a>Hot Undeploy</h3></div></div></div><p>
 				To hot-undeploy an artifact, remove the corresponding file from the pickup directory (by default <code class="literal">$SERVER_HOME/pickup</code>):
 			</p><pre class="programlisting">prompt$ cd $SERVER_HOME/pickup
 prompt$ rm helloWorld.war</pre><p>
 				When Virgo Web Server completes the undeployment of the artifact, messages similar to the following appear in the log:
 			</p><pre class="screen">[2009-12-10 06:46:33.254] fs-watcher   &lt;HD0001I&gt; Hot deployer processing 'DELETED' event for file 'helloWorld.war'.
 [2009-12-10 06:46:33.259] Thread-3     &lt;WE0002I&gt; Stopping web bundle 'helloWorld' version '0.0.0' with context path '/helloWorld'.
 [2009-12-10 06:46:33.285] Thread-3     &lt;WE0003I&gt; Stopped web bundle 'helloWorld' version '0.0.0' with context path '/helloWorld'.
 [2009-12-10 06:46:33.290] fs-watcher   &lt;DE0010I&gt; Stopping bundle 'helloWorld' version '0.0.0'.
 [2009-12-10 06:46:33.295] fs-watcher   &lt;DE0011I&gt; Stopped bundle 'helloWorld' version '0.0.0'.
 [2009-12-10 06:46:33.302] fs-watcher   &lt;DE0013I&gt; Uninstalling bundle 'helloWorld' version '0.0.0'.
 [2009-12-10 06:46:33.319] fs-watcher   &lt;DE0014I&gt; Uninstalled bundle 'helloWorld' version '0.0.0'.</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="deployment-undeploy-manual"></a>Undeploying Using the Admin Console</h3></div></div></div><p>
 				You can undeploy only whole artifacts from the Admin Console, or in other words, you cannot undeploy the separate modules or bundles that make up an artifact.</p><p>
 				The only artifact that you cannot undeploy from the Admin Console is the Admin Console itself. If you need to undeploy this application, you must remove it from the pickup directory (by default <code class="literal">SERVER_HOME/pickup</code>); the name of the artifact is
 				<code class="literal">org.eclipse.virgo.server.admin-2.1.0.RELEASE.plan</code>.
 			</p><p>See <a class="link" href="#admin-console-manage-artifacts" title="Viewing and Managing the Lifecycle of Deployed Artifacts">Viewing and Managing the Lifecycle of Deployed Artifacts</a> for details about uninstalling (undeploying) an artifact using the Admin Console.  The high-level steps are to highlight the artifact in the artifact tree then click <code class="literal">Uninstall</code>. </p></div></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="configuring"></a>11.&nbsp;Configuration</h2></div></div></div><p>You use configuration files in the <code class="literal">$SERVER_HOME/config</code> directory to configure VWS.  You can also configure the OSGi framework  using files in <code class="literal">$SERVER_HOME/lib</code>. This section divides the configuration of the server into the following high-level tasks:</p><div class="itemizedlist"><ul type="disc"><li><p><a class="link" href="#configuring-kernel" title="11.1&nbsp;Configuring the Virgo Kernel and User Region">Configuring the kernel and the user region.</a></p></li><li><p><a class="link" href="#configuring-tomcat" title="11.3&nbsp;Configuring the Embedded Tomcat Servlet Container">Configuring embedded Tomcat servlet container.</a></p></li><li><p><a class="link" href="#configuring-serviceability" title="11.2&nbsp;Configuring Serviceability">Configuring serviceability.</a></p></li><li><p><a class="link" href="#configuring-provisioning-repository" title="11.4&nbsp;Configuring the Local Provisioning Repository">Configuring the local provisioning repository.</a></p></li><li><p><a class="link" href="#configuring-hosted-repo" title="11.5&nbsp;Configuring a Hosted Repository">Configuring the hosted repository.</a></p></li><li><p><a class="link" href="#configuring-osgi-framework" title="11.6&nbsp;Configuring the OSGi Framework">Configuring the OSGi framework.</a></p></li></ul></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="configuring-kernel"></a>11.1&nbsp;Configuring the Virgo Kernel and User Region</h2></div></div></div><p>This section provides information about configuring the VWS kernel and the user region by updating the following files in the <code class="literal">$SERVER_HOME/config</code> directory:</p><div class="table"><a name="configuring-kernel-table"></a><p class="title"><b>Table&nbsp;11.1.&nbsp;Kernel Configuration Files </b></p><div class="table-contents"><table summary="Kernel Configuration Files " style="border-collapse: collapse;border-top: 1.0pt solid ; border-bottom: 1.0pt solid ; border-left: 1.0pt solid ; border-right: 1.0pt solid ; "><colgroup><col><col></colgroup><thead><tr><th style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Property File (prefixed by <code class="literal">org.eclipse.virgo</code>)</th><th style="border-bottom: 1.0pt solid ; ">Description</th></tr></thead><tbody><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><code class="literal">.kernel.properties</code></td><td style="border-bottom: 1.0pt solid ; ">Configures <a class="link" href="#configuring-deployment" title="Configuring Deployment">deployment</a>. </td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><code class="literal">.kernel.userregion.properties</code></td><td style="border-bottom: 1.0pt solid ; ">Configures the <a class="link" href="#configuring-user-region" title="Configuring the User Region">user region</a> of VWS and enables the OSGi console.</td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><code class="literal">.kernel.users.properties</code></td><td style="border-bottom: 1.0pt solid ; ">Configures the <a class="link" href="#configuring-authentication" title="Configuring Authentication">users that are allowed to access</a> the Admin Console, and roles to which they map. </td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><code class="literal">.kernel.jmxremote.access.properties</code></td><td style="border-bottom: 1.0pt solid ; ">Configures the <a class="link" href="#configuring-authentication" title="Configuring Authentication">permissions for users</a> that are allowed to access the Admin Console. </td></tr><tr><td style="border-right: 1.0pt solid ; "><code class="literal">.kernel.authentication.config</code></td><td style="">Configures the <a class="link" href="#configuring-authentication" title="Configuring Authentication">Java Authentication and Authorization Service (JAAS)</a> for the Tomcat server users.</td></tr></tbody></table></div></div><br class="table-break"><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="configuring-deployment"></a>Configuring Deployment</h3></div></div></div><p>You can configure two properties of deployment: the pickup directory into which you copy applications for hot-deployment and the deployment timeout.  </p><p>To change any of these properties, edit the <code class="literal">deployer.XXX</code> properties of the <code class="literal">$SERVER_HOME/config/org.eclipse.virgo.kernel.properties</code> file.  The following table describes these properties.  </p><div class="table"><a name="configuring-deployment-table"></a><p class="title"><b>Table&nbsp;11.2.&nbsp;Deployment Configuration Properties</b></p><div class="table-contents"><table summary="Deployment Configuration Properties" style="border-collapse: collapse;border-top: 1.0pt solid ; border-bottom: 1.0pt solid ; border-left: 1.0pt solid ; border-right: 1.0pt solid ; "><colgroup><col><col></colgroup><thead><tr><th style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Property</th><th style="border-bottom: 1.0pt solid ; ">Description</th></tr></thead><tbody><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><code class="literal">deployer.pickupDirectory</code></td><td style="border-bottom: 1.0pt solid ; ">Specifies the absolute or relative path to the pickup directory to which you copy applications for hot-deployment.  Relative paths are relative to <code class="literal">$SERVER_HOME</code>.  The default value is <code class="literal">./pickup</code>.</td></tr><tr><td style="border-right: 1.0pt solid ; "><code class="literal">deployer.timeout</code></td><td style="">Specifies the amount of time, in seconds, after which VWS times out while trying to deploy a bundle, library, or plan.  The default value is <code class="literal">300</code>.  If you want to disable deployment timeout, specify <code class="literal">0</code>.</td></tr></tbody></table></div></div><br class="table-break"><p>The following listing displays the default configuration distributed with the VWS; only relevant sections of the <code class="literal">org.eclipse.virgo.kernel.properties</code> file are shown. </p><pre class="programlisting">deployer.timeout=300
 deployer.pickupDirectory=pickup</pre><p>As the default configuration shows, the default pickup directory is <code class="literal">$SERVER_HOME/pickup</code> and the deployment timeout is 300 seconds.
 		</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="configuring-user-region"></a>Configuring the User Region</h3></div></div></div><p>
 			The user region is the subsystem of VWS that
 			supports deployed applications, both your own user applications and
 			those of the server itself, such as the Admin Console. The user region
 			is deliberately isolated from the kernel, which makes it much simpler
 			for you to manage your applications with the Admin Console
 			because the internal kernel bundles are not visible.
 		</p><p>
 			You configure the user region by updating properties in the
 			<code class="literal">$SERVER_HOME/config/org.eclipse.virgo.kernel.userregion.properties</code>
 			file; these properties are described in the following table.
 		</p><p>
 			<span class="bold"><strong>WARNING:</strong></span>
 			We strongly recommend that you update only the
 			<code class="literal">initialArtifacts</code> and the <code class="literal">osgi.console</code>
 			properties; updating other properties could cause
 			VWS to fail. These properties are documented for your
 			information.
 		</p><div class="table"><a name="configuring-user-region-table"></a><p class="title"><b>Table&nbsp;11.3.&nbsp;User Region Configuration Properties</b></p><div class="table-contents"><table summary="User Region Configuration Properties" style="border-collapse: collapse;border-top: 1.0pt solid ; border-bottom: 1.0pt solid ; border-left: 1.0pt solid ; border-right: 1.0pt solid ; "><colgroup><col><col></colgroup><thead><tr><th style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Property</th><th style="border-bottom: 1.0pt solid ; ">Description</th></tr></thead><tbody><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><code class="literal">baseBundles</code></td><td style="border-bottom: 1.0pt solid ; ">Specifies the hard-coded list of bundles that VWS installs directly into the user region. Virgo Web Server does not perform any automatic dependency satisfaction for these bundles; in other words, you only get the bundles in the list and nothing more. </td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><code class="literal">packageImports</code></td><td style="border-bottom: 1.0pt solid ; ">Specifies the packages that exist in the kernel that VWS imports into the user region so that they are in turn available to be imported by bundles in the user region. This property supports a <code class="literal">.*</code> wildcard.  For example, <code class="literal">org.eclipse.virgo.util.*</code> will import all packages that start with <code class="literal">org.eclipse.virgo.util</code>.</td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><code class="literal">serviceImports</code></td><td style="border-bottom: 1.0pt solid ; ">Specifies the services in the kernel that are imported into the user region so that they're available to bundles in the user region.  </td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><code class="literal">serviceExports</code></td><td style="border-bottom: 1.0pt solid ; ">Specifies the services in the user region that are exported to the kernel so that they're available to bundles in the kernel.  </td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><code class="literal">inheritedFrameworkProperties</code></td><td style="border-bottom: 1.0pt solid ; ">Specifies the framework properties, configured in the <code class="literal">$SERVER_HOME/lib/org.eclipse.virgo.kernel.launch.properties</code> file, that will also be set on the user region's nested framework.</td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><code class="literal">osgi.console</code></td><td style="border-bottom: 1.0pt solid ; ">Specifies the port number which the Equinox console will use.
 				The usual port number is 2401.
 				If specified, the Equinox console is enabled (with the Equinox Console Extension) during user region start.
 				If not specified, the Equinox console is not available.</td></tr><tr><td style="border-right: 1.0pt solid ; "><code class="literal">initialArtifacts</code></td><td style="">Specifies the artifacts that VWS deploys into the user region when the server starts. Virgo Web Server performs dependency satisfaction when it deploys these artifacts.  This means that you only need to list the top-level artifacts that you care about; VWS automatically installs any other artifacts upon which they depend from the repository.
 				</td></tr></tbody></table></div></div><br class="table-break"></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="configuring-authentication"></a>Configuring Authentication</h3></div></div></div><p>
 		Virgo Web Server uses the
 		<a class="ulink" href="http://java.sun.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html" target="_top">Java Authentication and Authorization Service (JAAS)</a>
 		framework to authenticate the administration user that connects to Web
 		Servers using the Admin Console. This section describes
 		how the authentication mechanism is configured by default, and the
 		files that you need to update if you want to change the administration
 		user, change their password, and so on.
 	</p><p>The <code class="literal">$SERVER_HOME/config/org.eclipse.virgo.kernel.authentication.config</code> file configures the underlying authentication technology for VWS.  The short file consists of the following entry:</p><pre class="programlisting">virgo-kernel {
         org.eclipse.virgo.kernel.authentication.KernelLoginModule REQUIRED;
 };</pre><p>The entry is named <code class="literal">virgo-kernel</code>.  This name corresponds to the <code class="literal">&lt;Realm&gt;</code> element in the <code class="literal">$SERVER_HOME/config/tomcat-server.xml</code> file that configures the JAAS authentication mechanism for the <code class="literal">Catalina</code> service of the <a class="link" href="#configuring-tomcat" title="11.3&nbsp;Configuring the Embedded Tomcat Servlet Container">Tomcat servlet container</a>.  The <code class="literal">virgo-kernel</code> entry specifies that the JAAS LoginModule that VWS uses to authenticate users is <code class="literal">org.eclipse.virgo.kernel.authentication.KernelLoginModule</code> and that this <code class="literal">KernelLoginModule</code> is required to "succeed" in order for authentication to be considered successful. The <code class="literal">KernelLoginModule</code> succeeds only if the name and password supplied by the user are the ones it expects.  The default administration username/password pair for Web Server is <code class="literal">admin/springsource</code>. </p><p>You configure the administration user in the <code class="literal">org.eclipse.virgo.kernel.users.properties</code> file.  The default file for a freshly installed VWS is as follows:</p><pre class="programlisting">##################
 # User definitions
 ##################
 user.admin=springsource

 ##################
 # Role definitions
 ##################
 role.admin=admin</pre><p>
 		The administration user that connect to the Admin Console must have the
 		<code class="literal">admin</code>
 		role. The preceding file shows how, by default, the
 		<code class="literal">admin</code>
 		role is assigned the
 		<code class="literal">admin</code>
 		user with password
 		<code class="literal">springsource</code>.
 	</p><p>If you want to change the administration user, update the <code class="literal">org.eclipse.virgo.kernel.users.properties</code> file.  For example, if you want the <code class="literal">juliet</code> user, with password <code class="literal">supersecret</code>, to be the new adminstration user, update the file as shown:</p><pre class="programlisting">##################
 # User definitions
 ##################
 user.juliet=supersecret

 ##################
 # Role definitions
 ##################
 role.admin=juliet</pre><p>Be sure to restart VWS after you make this change for it to take effect.</p><p>The final file involved in VWS authentication is <code class="literal">$SERVER_HOME/config/org.eclipse.virgo.kernel.jmxremote.access.properties</code>.  This file specifies the JMX access privileges that the administration user has; by default they are read and write, as shown in the following listing:</p><pre class="programlisting">admin=readwrite</pre><p>
 		The only other value you can enter is
 		<code class="literal">readonly</code>, which means that the adminstration user would only be able to <span class="emphasis"><em>view</em></span>
 		information using the Admin Console.
 	</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="configuring-serviceability"></a>11.2&nbsp;Configuring Serviceability</h2></div></div></div><p>The serviceability sub-system of VWS allows you to gather and view data and information that you can then use to diagnose problems and failures.  Serviceability includes data from:</p><div class="itemizedlist"><ul type="disc"><li><p>
 		Service dumps: Contain a snapshot of all the important state from the running VWS instance when an internal failure or thread deadlock is detected.
 		</p><p>You configure service dumps for Virgo Web Server using the <a class="link" href="#configuring-serviceability-medic" title="The org.eclipse.virgo.medic.properties File">org.eclipse.virgo.medic.properties</a> file in the <code class="literal">$SERVER_HOME/config</code> directory.  This file also includes some additional logging configuration.</p></li><li><p>
 		Event logs and server/application (trace) logging: Logging support in VWS is based on <a class="ulink" href="http://logback.qos.ch/" target="_top">Logback</a>.  This means that you now have complete control over the format of log output and have the complete range of Logback's appenders available for your use.
 		</p><p>You configure logging for Virgo Web Server using the <a class="link" href="#configuring-serviceability-logback" title="The serviceability.xml File">serviceability.xml</a> file in the <code class="literal">$SERVER_HOME/config</code> directory.  This file is essentially the Logback <code class="literal">logback.xml</code> (or <code class="literal">logback-test.xml</code>) configuration file but renamed for VWS. </p></li></ul></div><p>For additional conceptual information about the serviceability subsystem, see <a class="xref" href="#serviceability" title="9.&nbsp;Serviceability">Chapter&nbsp;9, <i>Serviceability</i></a>. </p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="configuring-serviceability-medic"></a>The org.eclipse.virgo.medic.properties File</h3></div></div></div><p>The <code class="literal">$SERVER_HOME/config/org.eclipse.virgo.medic.properties</code> file configures VWS service dumps and whether you want to capture <code class="literal">System.out</code> and <code class="literal">System.err</code> output to your application's trace file. </p><p>The following table describes the properties you can include in the <code class="literal">$SERVER_HOME/config/org.eclipse.virgo.medic.properties</code> file. This file configures serviceability properties that VWS includes in addition to those supplied by the Logback, configured in the <code class="literal">serviceability.xml</code> file.</p><div class="table"><a name="medic-properties-table"></a><p class="title"><b>Table&nbsp;11.4.&nbsp;Serviceability Properties</b></p><div class="table-contents"><table summary="Serviceability Properties" style="border-collapse: collapse;border-top: 1.0pt solid ; border-bottom: 1.0pt solid ; border-left: 1.0pt solid ; border-right: 1.0pt solid ; "><colgroup><col><col></colgroup><thead><tr><th style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Property</th><th style="border-bottom: 1.0pt solid ; ">Description</th></tr></thead><tbody><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><code class="literal">dump.root.directory</code></td><td style="border-bottom: 1.0pt solid ; ">Specifies the directory to which VWS writes the service dumps.  The directory name is relative to <code class="literal">$SERVER_HOME</code>.  </td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><code class="literal">log.wrapSysOut</code></td><td style="border-bottom: 1.0pt solid ; ">Specifies whether you want to capture <code class="literal">System.out</code> output from your applications to the application trace file.  The output is logged by VWS's root logger, which captures <code class="literal">INFO</code> level and above.
 			<p>Valid values for this property are <code class="literal">true</code> to capture <code class="literal">System.out</code> output, or <code class="literal">false</code> to disable the capture.</p>
 			<p>For more information, see <a class="link" href="#sysout-and-syserr" title="System.out and System.err">System.out and System.err</a>.</p>
 		  </td></tr><tr><td style="border-right: 1.0pt solid ; "><code class="literal">log.wrapSysErr</code></td><td style="">Specifies whether you want to capture <code class="literal">System.err</code> output from your applications to the application trace file.  The output is logged by VWS's root logger, which captures <code class="literal">INFO</code> level and above.
 			<p>Valid values for this property are <code class="literal">true</code> to capture <code class="literal">System.err</code> output, or <code class="literal">false</code> to disable the capture.</p>
 			<p>For more information, see <a class="link" href="#sysout-and-syserr" title="System.out and System.err">System.out and System.err</a>.</p>
 		  </td></tr></tbody></table></div></div><br class="table-break"></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="configuring-serviceability-logback"></a>The serviceability.xml File</h3></div></div></div><p>Logging support in VWS is based on <a class="ulink" href="http://logback.qos.ch/" target="_top">Logback</a>, which is a successor of the log4j project. The Logback logging framework is faster, more reliable, and easier to use than log4j and certain other logging systems.</p><p>You configure logging for Virgo Web Server using the <code class="literal">$SERVER_HOME/config/serviceability.xml</code> file.  This file is the standard Logback <code class="literal">logback.xml</code> or <code class="literal">logback-test.xml</code> configuration file, but renamed for VWS. </p><p>The following listing shows the default <code class="literal">serviceability.xml</code> file in a freshly-installed VWS; see the text after the listing for a brief overview of the file:</p><pre class="programlisting">&lt;<span class="hl-tag">configuration</span>&gt;
 	&lt;<span class="hl-tag">appender</span> <span class="hl-attribute">name</span>=<span class="hl-value">"SIFTED_LOG_FILE"</span> <span class="hl-attribute">class</span>=<span class="hl-value">"ch.qos.logback.classic.sift.SiftingAppender"</span>&gt;
 		&lt;<span class="hl-tag">discriminator</span>&gt;
 			&lt;<span class="hl-tag">Key</span>&gt;applicationName&lt;<span class="hl-tag">/Key</span>&gt;
 			&lt;<span class="hl-tag">DefaultValue</span>&gt;virgo-server&lt;<span class="hl-tag">/DefaultValue</span>&gt;
 		&lt;<span class="hl-tag">/discriminator</span>&gt;
 		&lt;<span class="hl-tag">sift</span>&gt;
 			&lt;<span class="hl-tag">appender</span> <span class="hl-attribute">name</span>=<span class="hl-value">"${applicationName}_LOG_FILE"</span> <span class="hl-attribute">class</span>=<span class="hl-value">"ch.qos.logback.core.rolling.RollingFileAppender"</span>&gt;
 				&lt;<span class="hl-tag">file</span>&gt;serviceability/logs/${applicationName}/log.log&lt;<span class="hl-tag">/file</span>&gt;
 				&lt;<span class="hl-tag">rollingPolicy</span> <span class="hl-attribute">class</span>=<span class="hl-value">"ch.qos.logback.core.rolling.FixedWindowRollingPolicy"</span>&gt;
 					&lt;<span class="hl-tag">FileNamePattern</span>&gt;serviceability/logs/${applicationName}/log_%i.log&lt;<span class="hl-tag">/FileNamePattern</span>&gt;
 					&lt;<span class="hl-tag">MinIndex</span>&gt;1&lt;<span class="hl-tag">/MinIndex</span>&gt;
 					&lt;<span class="hl-tag">MaxIndex</span>&gt;4&lt;<span class="hl-tag">/MaxIndex</span>&gt;
 				&lt;<span class="hl-tag">/rollingPolicy</span>&gt;
 				&lt;<span class="hl-tag">triggeringPolicy</span> <span class="hl-attribute">class</span>=<span class="hl-value">"ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"</span>&gt;
 					&lt;<span class="hl-tag">MaxFileSize</span>&gt;10MB&lt;<span class="hl-tag">/MaxFileSize</span>&gt;
 				&lt;<span class="hl-tag">/triggeringPolicy</span>&gt;
 				&lt;<span class="hl-tag">encoder</span> <span class="hl-attribute">class</span>=<span class="hl-value">"ch.qos.logback.classic.encoder.PatternLayoutEncoder"</span>&gt;
 					&lt;<span class="hl-tag">Pattern</span>&gt;[%d{yyyy-MM-dd HH:mm:ss.SSS}] %-28.28thread %-64.64logger{64} %X{medic.eventCode} %msg %ex%n&lt;<span class="hl-tag">/Pattern</span>&gt;
 				&lt;<span class="hl-tag">/encoder</span>&gt;
 			&lt;<span class="hl-tag">/appender</span>&gt;
 		&lt;<span class="hl-tag">/sift</span>&gt;
 	&lt;<span class="hl-tag">/appender</span>&gt;

 	&lt;<span class="hl-tag">appender</span> <span class="hl-attribute">name</span>=<span class="hl-value">"LOG_FILE"</span> <span class="hl-attribute">class</span>=<span class="hl-value">"ch.qos.logback.core.rolling.RollingFileAppender"</span>&gt;
 		&lt;<span class="hl-tag">file</span>&gt;serviceability/logs/log.log&lt;<span class="hl-tag">/file</span>&gt;
 		&lt;<span class="hl-tag">rollingPolicy</span> <span class="hl-attribute">class</span>=<span class="hl-value">"ch.qos.logback.core.rolling.FixedWindowRollingPolicy"</span>&gt;
 			&lt;<span class="hl-tag">FileNamePattern</span>&gt;serviceability/logs/log_%i.log&lt;<span class="hl-tag">/FileNamePattern</span>&gt;
 			&lt;<span class="hl-tag">MinIndex</span>&gt;1&lt;<span class="hl-tag">/MinIndex</span>&gt;
 			&lt;<span class="hl-tag">MaxIndex</span>&gt;4&lt;<span class="hl-tag">/MaxIndex</span>&gt;
 		&lt;<span class="hl-tag">/rollingPolicy</span>&gt;
 		&lt;<span class="hl-tag">triggeringPolicy</span> <span class="hl-attribute">class</span>=<span class="hl-value">"ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"</span>&gt;
 			&lt;<span class="hl-tag">MaxFileSize</span>&gt;10MB&lt;<span class="hl-tag">/MaxFileSize</span>&gt;
 		&lt;<span class="hl-tag">/triggeringPolicy</span>&gt;
 		&lt;<span class="hl-tag">encoder</span> <span class="hl-attribute">class</span>=<span class="hl-value">"ch.qos.logback.classic.encoder.PatternLayoutEncoder"</span>&gt;
 			&lt;<span class="hl-tag">Pattern</span>&gt;[%d{yyyy-MM-dd HH:mm:ss.SSS}] %-28.28thread %-64.64logger{64} %X{medic.eventCode} %msg %ex%n&lt;<span class="hl-tag">/Pattern</span>&gt;
 		&lt;<span class="hl-tag">/encoder</span>&gt;
 	&lt;<span class="hl-tag">/appender</span>&gt;

 	&lt;<span class="hl-tag">appender</span> <span class="hl-attribute">name</span>=<span class="hl-value">"EVENT_LOG_STDOUT"</span> <span class="hl-attribute">class</span>=<span class="hl-value">"org.eclipse.virgo.medic.log.logback.ReroutingAwareConsoleAppender"</span>&gt;
 		&lt;<span class="hl-tag">encoder</span> <span class="hl-attribute">class</span>=<span class="hl-value">"ch.qos.logback.classic.encoder.PatternLayoutEncoder"</span>&gt;
 			&lt;<span class="hl-tag">Pattern</span>&gt;[%d{yyyy-MM-dd HH:mm:ss.SSS}] %-28.28thread &amp;lt;%X{medic.eventCode}&amp;gt; %msg %ex%n&lt;<span class="hl-tag">/Pattern</span>&gt;
 		&lt;<span class="hl-tag">/encoder</span>&gt;
 	&lt;<span class="hl-tag">/appender</span>&gt;

 	&lt;<span class="hl-tag">appender</span> <span class="hl-attribute">name</span>=<span class="hl-value">"EVENT_LOG_FILE"</span> <span class="hl-attribute">class</span>=<span class="hl-value">"ch.qos.logback.core.rolling.RollingFileAppender"</span>&gt;
 		&lt;<span class="hl-tag">file</span>&gt;serviceability/eventlogs/eventlog.log&lt;<span class="hl-tag">/file</span>&gt;
 		&lt;<span class="hl-tag">rollingPolicy</span> <span class="hl-attribute">class</span>=<span class="hl-value">"ch.qos.logback.core.rolling.FixedWindowRollingPolicy"</span>&gt;
 			&lt;<span class="hl-tag">FileNamePattern</span>&gt;serviceability/eventlogs/eventlog_%i.log&lt;<span class="hl-tag">/FileNamePattern</span>&gt;
 			&lt;<span class="hl-tag">MinIndex</span>&gt;1&lt;<span class="hl-tag">/MinIndex</span>&gt;
 			&lt;<span class="hl-tag">MaxIndex</span>&gt;4&lt;<span class="hl-tag">/MaxIndex</span>&gt;
 		&lt;<span class="hl-tag">/rollingPolicy</span>&gt;
 		&lt;<span class="hl-tag">triggeringPolicy</span> <span class="hl-attribute">class</span>=<span class="hl-value">"ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"</span>&gt;
 			&lt;<span class="hl-tag">MaxFileSize</span>&gt;10MB&lt;<span class="hl-tag">/MaxFileSize</span>&gt;
 		&lt;<span class="hl-tag">/triggeringPolicy</span>&gt;
 		&lt;<span class="hl-tag">encoder</span> <span class="hl-attribute">class</span>=<span class="hl-value">"ch.qos.logback.classic.encoder.PatternLayoutEncoder"</span>&gt;
 			&lt;<span class="hl-tag">Pattern</span>&gt;[%d{yyyy-MM-dd HH:mm:ss.SSS}] %-28.28thread &amp;lt;%X{medic.eventCode}&amp;gt; %msg %ex%n&lt;<span class="hl-tag">/Pattern</span>&gt;
 		&lt;<span class="hl-tag">/encoder</span>&gt;
 	&lt;<span class="hl-tag">/appender</span>&gt;

 	&lt;<span class="hl-tag">logger</span> <span class="hl-attribute">level</span>=<span class="hl-value">"INFO"</span> <span class="hl-attribute">additivity</span>=<span class="hl-value">"false"</span> <span class="hl-attribute">name</span>=<span class="hl-value">"org.eclipse.virgo.medic.eventlog.localized"</span>&gt;
 		&lt;<span class="hl-tag">appender-ref</span> <span class="hl-attribute">ref</span>=<span class="hl-value">"EVENT_LOG_STDOUT"</span> /&gt;
 		&lt;<span class="hl-tag">appender-ref</span> <span class="hl-attribute">ref</span>=<span class="hl-value">"EVENT_LOG_FILE"</span> /&gt;
 	&lt;<span class="hl-tag">/logger</span>&gt;

 	&lt;<span class="hl-tag">logger</span> <span class="hl-attribute">level</span>=<span class="hl-value">"INFO"</span> <span class="hl-attribute">additivity</span>=<span class="hl-value">"false"</span> <span class="hl-attribute">name</span>=<span class="hl-value">"org.eclipse.virgo.medic.eventlog.default"</span>&gt;
 		&lt;<span class="hl-tag">appender-ref</span> <span class="hl-attribute">ref</span>=<span class="hl-value">"SIFTED_LOG_FILE"</span> /&gt;
 		&lt;<span class="hl-tag">appender-ref</span> <span class="hl-attribute">ref</span>=<span class="hl-value">"LOG_FILE"</span> /&gt;
 	&lt;<span class="hl-tag">/logger</span>&gt;

 	&lt;<span class="hl-tag">root</span> <span class="hl-attribute">level</span>=<span class="hl-value">"INFO"</span>&gt;
 		&lt;<span class="hl-tag">appender-ref</span> <span class="hl-attribute">ref</span>=<span class="hl-value">"SIFTED_LOG_FILE"</span> /&gt;
 		&lt;<span class="hl-tag">appender-ref</span> <span class="hl-attribute">ref</span>=<span class="hl-value">"LOG_FILE"</span> /&gt;
 	&lt;<span class="hl-tag">/root</span>&gt;

 &lt;<span class="hl-tag">/configuration</span>&gt;</pre><p>Logback allows VWS to use logger, appender, and encoder (layout) objects to log messages according to message type and level and to format these messages and define where they are written.  The default <code class="literal">serviceability.xml</code> file shown above includes four appenders and three loggers (two user and one root.)</p><p>The main information to get from this file is that VWS writes log messages to four different locations that map to the four appenders:</p><div class="itemizedlist"><ul type="disc"><li><p>The <code class="literal">SIFTED_LOG_FILE</code> appender logs both global and application-specific messages to the <code class="literal">$SERVER_HOME/serviceability/logs/</code><span class="emphasis"><em><code class="literal">applicationName</code></em></span><code class="literal">/log.log</code> file, where <span class="emphasis"><em><code class="literal">applicationName</code></em></span> refers to the name of the application.   The log messages for the VWS itself are logged to the <code class="literal">$SERVER_HOME/serviceability/logs/virgo-server/log.log</code> file. Because this appender creates different log files for each application, it is called a <span class="emphasis"><em>sifting appender</em></span>.   </p><p>
 			The default behaviour of these trace files is that, once <code class="literal">log.log</code> reaches a 10Mb limit, it rolls into a series of files named
 			<code class="literal">log_</code><span class="emphasis"><em>i</em></span><code class="literal">.log</code> where <span class="emphasis"><em>i</em></span> ranges from 1 to 4, and logging continues in
 			a new <code class="literal">log.log</code> file. This is called its <span class="emphasis"><em>rolling policy</em></span>.
 		</p><p>The <code class="literal">&lt;Pattern&gt;</code> element defines the format of each log message;  messages include the timestamp, the thread that generated the log message, the context-specific event code, and a stack trace of the exception, if any.  For example:</p><p><code class="literal">[2008-05-15 09:09:46.940] server-dm-2 org.apache.coyote.http11.Http11Protocol I Initializing Coyote HTTP/1.1 on http-48080</code></p></li><li><p>The <code class="literal">LOG_FILE</code> appender is very similar to the first one, but it logs <span class="emphasis"><em>all</em></span> log messages to the <code class="literal">$SERVER_HOME/serviceability/log/log.log</code> file rather than sifting application-specific messages to their own log file.  The rolling policy and message format for this appender is similar to that of the <code class="literal">SIFTED_LOG_FILE</code> appender.</p></li><li><p>The <code class="literal">EVENT_LOG_STDOUT</code> appender does not log messages to a file, but rather to the console window from which you started VWS. For example:</p><p><code class="literal">[2010-10-25 16:20:49.367] Thread-3   &lt;WE0000I&gt; Starting web bundle 'org.eclipse.virgo.apps.admin.web' version '2.1.0.RELEASE' with context path '/admin'.</code></p></li><li><p>The <code class="literal">EVENT_LOG_FILE</code> appender logs only important events to the <code class="literal">$SERVER_HOME/serviceability/eventlogs/eventlog.log</code> file, and thus the volume of information is much lower than with the first two appenders. The rolling policy for the event log is the same as with the first two appenders, but the format of the messages is similar to that of the <code class="literal">EVENT_LOG_STDOUT</code> appender. </p></li></ul></div><p>The loggers and root logger specify the level of log that is written for each of the referenced appenders.</p><p>Typically, the default logging configuration as specified by the <code class="literal">serviceability.xml</code> file is adequate for all VWS environments.  However, if you want to customize the logging framework further, you can edit this file as well as the <code class="literal">org.eclipse.virgo.medic.properties</code>.  See the <a class="ulink" href="http://logback.qos.ch/manual/index.html" target="_top">logback documentation</a> for detailed information about the architecture and the configuration of Logback.</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="configuring-tomcat"></a>11.3&nbsp;Configuring the Embedded Tomcat Servlet Container</h2></div></div></div><p>
 			Virgo Web Server
 			embeds an OSGi-enhanced version of the <a class="ulink" href="http://tomcat.apache.org/" target="_top">Tomcat Servlet Container</a>
 			in order to provide support for deploying Java EE WARs and OSGi <span class="emphasis"><em>Web Application Bundles</em></span>.
 			You configure the embedded Servlet container using the standard Apache Tomcat configuration.   The main difference is that the configuration file is called <code class="filename">tomcat-server.xml</code> rather than <code class="literal">server.xml</code>.  As with the other VWS configuration files, the <code class="literal">tomcat-server.xml</code> file is located in the <code class="literal">$SERVER_HOME/config</code> directory.
 		</p><p>Here's an extract of the default configuration distributed with the VWS.
 		</p><pre class="programlisting">&lt;<span class="hl-tag">?xml version='1.0' encoding='utf-8'?</span>&gt;
 &lt;<span class="hl-tag">Server</span> <span class="hl-attribute">port</span>=<span class="hl-value">"8005"</span> <span class="hl-attribute">shutdown</span>=<span class="hl-value">"SHUTDOWN"</span>&gt;

 	&lt;<span class="hl-tag">Listener</span> <span class="hl-attribute">className</span>=<span class="hl-value">"org.apache.catalina.core.AprLifecycleListener"</span> <span class="hl-attribute">SSLEngine</span>=<span class="hl-value">"on"</span> /&gt;
 	&lt;<span class="hl-tag">Listener</span> <span class="hl-attribute">className</span>=<span class="hl-value">"org.apache.catalina.core.JasperListener"</span> /&gt;
 	&lt;<span class="hl-tag">Listener</span> <span class="hl-attribute">className</span>=<span class="hl-value">"org.apache.catalina.mbeans.ServerLifecycleListener"</span> /&gt;
 	&lt;<span class="hl-tag">Listener</span> <span class="hl-attribute">className</span>=<span class="hl-value">"org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"</span> /&gt;

 	&lt;<span class="hl-tag">Listener</span> <span class="hl-attribute">className</span>=<span class="hl-value">"org.eclipse.virgo.web.tomcat.ServerLifecycleLoggingListener"</span>/&gt;

 	&lt;<span class="hl-tag">Service</span> <span class="hl-attribute">name</span>=<span class="hl-value">"Catalina"</span>&gt;
 		&lt;<span class="hl-tag">Connector</span> <span class="hl-attribute">port</span>=<span class="hl-value">"8080"</span> <span class="hl-attribute">protocol</span>=<span class="hl-value">"HTTP/1.1"</span>
 			<span class="hl-attribute">connectionTimeout</span>=<span class="hl-value">"20000"</span>
 			<span class="hl-attribute">redirectPort</span>=<span class="hl-value">"8443"</span> /&gt;

 		&lt;<span class="hl-tag">Connector</span> <span class="hl-attribute">port</span>=<span class="hl-value">"8443"</span> <span class="hl-attribute">protocol</span>=<span class="hl-value">"HTTP/1.1"</span> <span class="hl-attribute">SSLEnabled</span>=<span class="hl-value">"true"</span>
 			<span class="hl-attribute">maxThreads</span>=<span class="hl-value">"150"</span> <span class="hl-attribute">scheme</span>=<span class="hl-value">"https"</span> <span class="hl-attribute">secure</span>=<span class="hl-value">"true"</span>
 			<span class="hl-attribute">clientAuth</span>=<span class="hl-value">"false"</span> <span class="hl-attribute">sslProtocol</span>=<span class="hl-value">"TLS"</span>
 			<span class="hl-attribute">keystoreFile</span>=<span class="hl-value">"config/keystore"</span>
 			<span class="hl-attribute">keystorePass</span>=<span class="hl-value">"changeit"</span>/&gt;

 		&lt;<span class="hl-tag">Connector</span> <span class="hl-attribute">port</span>=<span class="hl-value">"8009"</span> <span class="hl-attribute">protocol</span>=<span class="hl-value">"AJP/1.3"</span> <span class="hl-attribute">redirectPort</span>=<span class="hl-value">"8443"</span> /&gt;

 		&lt;<span class="hl-tag">Engine</span> <span class="hl-attribute">name</span>=<span class="hl-value">"Catalina"</span> <span class="hl-attribute">defaultHost</span>=<span class="hl-value">"localhost"</span>&gt;
 			&lt;<span class="hl-tag">Realm</span> <span class="hl-attribute">className</span>=<span class="hl-value">"org.apache.catalina.realm.JAASRealm"</span> <span class="hl-attribute">appName</span>=<span class="hl-value">"virgo-kernel"</span>
 					<span class="hl-attribute">userClassNames</span>=<span class="hl-value">"org.eclipse.virgo.kernel.authentication.User"</span>
 					<span class="hl-attribute">roleClassNames</span>=<span class="hl-value">"org.eclipse.virgo.kernel.authentication.Role"</span>/&gt;

 			&lt;<span class="hl-tag">Host</span> <span class="hl-attribute">name</span>=<span class="hl-value">"localhost"</span>  <span class="hl-attribute">appBase</span>=<span class="hl-value">"webapps"</span>
 					<span class="hl-attribute">unpackWARs</span>=<span class="hl-value">"true"</span> <span class="hl-attribute">autoDeploy</span>=<span class="hl-value">"true"</span>
 					<span class="hl-attribute">xmlValidation</span>=<span class="hl-value">"false"</span> <span class="hl-attribute">xmlNamespaceAware</span>=<span class="hl-value">"false"</span>&gt;

 				&lt;<span class="hl-tag">Valve</span> <span class="hl-attribute">className</span>=<span class="hl-value">"org.apache.catalina.valves.AccessLogValve"</span> <span class="hl-attribute">directory</span>=<span class="hl-value">"serviceability/logs/access"</span>
 					<span class="hl-attribute">prefix</span>=<span class="hl-value">"localhost_access_log."</span> <span class="hl-attribute">suffix</span>=<span class="hl-value">".txt"</span> <span class="hl-attribute">pattern</span>=<span class="hl-value">"common"</span> <span class="hl-attribute">resolveHosts</span>=<span class="hl-value">"false"</span>/&gt;

 				&lt;<span class="hl-tag">Valve</span> <span class="hl-attribute">className</span>=<span class="hl-value">"org.eclipse.virgo.web.tomcat.ApplicationNameTrackingValve"</span>/&gt;
 			&lt;<span class="hl-tag">/Host</span>&gt;
 		&lt;<span class="hl-tag">/Engine</span>&gt;
 	&lt;<span class="hl-tag">/Service</span>&gt;
 &lt;<span class="hl-tag">/Server</span>&gt;</pre><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="overview-tomcat-servlet-container"></a>Description of the Default Apache Tomcat Configuration</h3></div></div></div><p>
 		  The following bullets describe the main elements and attributes in the default <code class="literal">tomcat-server.xml</code> file; for details about updating this file to further configure the embedded Apache Tomcat server, see the <a class="ulink" href="http://tomcat.apache.org/tomcat-6.0-doc/config/index.html" target="_top">Apache Tomcat Configuration Reference</a>.
 		</p><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Tip: Relative paths"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Tip]" src="images/tip.gif"></td><th align="left">Relative paths</th></tr><tr><td align="left" valign="top"><p>If the configured path to a directory or file does not represent an absolute path, VWS typically interprets it as a path relative to the <code class="filename">$SERVER_HOME</code> directory.</p></td></tr></table></div><div class="itemizedlist"><ul type="disc"><li><p>The root element of the <code class="literal">tomcat-server.xml</code> file is <code class="literal">&lt;Server&gt;</code>. The attributes of this element represent the characteristics of the entire embedded Tomcat servlet container. The <code class="literal">shutdown</code> attribute specifies the command string that the shutdown port number receives via a TCP/IP connection in order to shut down the servlet container. The <code class="literal">port</code> attribute specifies the TCP/IP port number that listens for a shutdown message.</p></li><li><p>The <code class="literal">&lt;Listener&gt;</code> XML elements specify the list of lifecycle listeners that monitor and manage the embedded Tomcat servlet container. Each listener class is a Java Management Extensions (JMX) MBean that listens to a specific component of the servlet container and has been programmed to do something at certain lifecycle events of the component, such as before starting up, after stopping, and so on.</p><p> The first four <code class="literal">&lt;Listener&gt;</code> elements configure standard Tomcat lifecycle listeners. The listener implemented by the <code class="literal">org.eclipse.virgo.web.tomcat.ServerLifecycleLoggingListener</code> class is specific to Virgo Web Server and manages server lifecycle logging.
 		</p></li><li><p>The <code class="literal">&lt;Service&gt;</code> XML element groups together one or more connectors and a single engine. Connectors define a transport mechanism, such as HTTP, that clients use to to send and receive messages to and from the associated service. There are many transports that a client can use, which is why a <code class="literal">&lt;Service&gt;</code> element can have many <code class="literal">&lt;Connector&gt;</code> elements. The engine then defines how these requests and responses that the connector receives and sends are in turn handled by the servlet container; you can define only a single <code class="literal">&lt;Engine&gt;</code> element for any given <code class="literal">&lt;Service&gt;</code> element.</p><p> The sample <code class="literal">tomcat-server.xml</code> file above includes three <code class="literal">&lt;Connector&gt;</code> elements: one for the HTTP transport, one for the HTTPS transport, and one for the AJP transport. The file also includes a single <code class="literal">&lt;Engine&gt;</code> element, as required.
 		</p></li><li><p>The first connector listens for HTTP requests at the <code class="literal">8080</code> TCP/IP port. The connector, after accepting a connection from a client, waits for a maximum of 20000 milliseconds for a request URI; if it does not receive one from the client by then, the connector times out. If this connector receives a request from the client that requires the SSL transport, the servlet container automatically redirects the request to port <code class="literal">8443</code>. </p></li><li><p>The second connector is for HTTPS requests.  The TCP/IP port that users specify as the secure connection port is <code class="literal">8443</code>. Be sure that you set the value of the <code class="literal">redirectPort</code> attribute of your non-SSL connectors to this value to ensure that users that require a secure connection are redirected to the secure port, even if they initially start at the non-secure port.  The <code class="literal">SSLEnabled</code> attribute specifies that SSL is enabled for this connector.  The <code class="literal">secure</code> attribute ensures that a call to <code class="literal">request.isSecure()</code> from the connecting client always returns <code class="literal">true</code>. The <code class="literal">scheme</code> attribute ensures that a call to <code class="literal">request.getScheme()</code> from the connecting client always returns <code class="literal">https</code> when clients use this connector. </p><p>The <code class="literal">maxThreads</code> attribute specifies that the servlet container creates a maximum of 150 request processing threads,
 		which determines the maximum number of simultaneous requests that can be handled.
 		The <code class="literal">clientAuth</code> attribute specifies that the servlet container does not require a certificate chain
 		unless the client requests a resource protected by a security constraint that uses CLIENT-CERT authentication.
 		</p><p>The <code class="literal">keystoreFile</code> attribute specifies the name of the file that contains the servlet container&#8217;s
                 private key and public certificate used in the SSL handshake, encryption, and decryption.
                 You use an alias and password to access this information.
                 In the example, this file is <code class="literal">$SERVER_HOME/config/keystore</code>.
                 The <code class="literal">keystorePass</code> attributes specify the password used to access the keystore.
                 </p></li><li><p>The third AJP Connector element represents a Connector component that communicates with a web connector via the AJP protocol.
 		</p></li><li><p>The engine has a logical name of <code class="literal">Catalina</code>;
 		this is the name used in all log and error messages so you can easily identify problems.
 		The value of the <code class="literal">defaultHost</code> attribute refers to the name of a <code class="literal">&lt;Host&gt;</code>
 		child element of <code class="literal">&lt;Engine&gt;</code>;
 		this host processes requests directed to host names on this servlet container.
 		</p></li><li><p>The <code class="literal">&lt;Realm&gt;</code> child element of <code class="literal">&lt;Engine&gt;</code> represents a database of
 		users, passwords, and mapped roles used for authentication in this service.  Virgo Web Server uses an implementation of the Tomcat 6 Realm interface that authenticates users through the Java Authentication and Authorization Service (JAAS) framework which is provided as part of the standard J2SE API.</p><p>With the JAASRealm, you can combine practically any conceivable security realm with Tomcat's container managed authentication.  For details, see <a class="ulink" href="http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html" target="_top">Realm Configuration</a>.</p></li><li><p>The <code class="literal">&lt;Host&gt;</code> child element represents a virtual host,
 		which is an association of a network name for a server (such as <code class="literal">www.mycompany.com</code>) with the particular
 		server on which Catalina is running.
 		The servlet container unpacks Web applications into a directory hierarchy if they are deployed as WAR files.
 		The <code class="literal">xmlValidation</code> attribute specifies that the servlet container does not validate XML files when parsing them,
 		or in other words, it accepts invalid XML.
 		The <code class="literal">xmlNamespaceAware</code> attribute specifies that the servlet container does not take namespaces into account
 		when reading XML files.
 		</p></li><li><p>Finally, the <code class="literal">org.apache.catalina.valves.AccessLogValve</code> valve creates log files
 		in the same format as those created by standard web servers.
 		The servlet container creates the log files in the <code class="literal">$SERVER_HOME/serviceability/logs/access</code> directory.
 		The log files are prefixed with the string <code class="literal">localhost_access_log.</code>, have a suffix of <code class="literal">.txt</code>,
 		use a standard format for identifying what should be logged, and do not include DNS lookups of the IP address of the remote host.
 		</p></li></ul></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="configuring-tomcat-connectors"></a>Connector Configuration</h3></div></div></div><p> The Virgo Web Server supports the configuration of any connector supported by Apache Tomcat.
 			See the default configuration above for syntax examples, and for further details of the configuration properties
 			supported for various <code class="literal">&lt;Connector&gt;</code> implementations,
 			consult the official <a class="ulink" href="http://tomcat.apache.org/tomcat-6.0-doc/config/http.html" target="_top">Tomcat HTTP Connector</a> documentation.
 			</p><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Tip: Configuring SSL for Tomcat"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Tip]" src="images/tip.gif"></td><th align="left">Configuring SSL for Tomcat</th></tr><tr><td align="left" valign="top"><p> The Virgo Web Server distribution includes a preconfigured <code class="filename">$SERVER_HOME/config/keystore</code>
 				file that contains a single self-signed SSL Certificate.
 				The password for this <code class="filename">keystore</code> file is <code class="literal">changeit</code>.
 				This <code class="filename">keystore</code> file is intended for testing purposes only.
 				For detailed instructions on how to configure Tomcat&#8217;s SSL support,
 				consult the official <a class="ulink" href="http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html" target="_top">Tomcat SSL Configuration HOW-TO</a>.
 				</p></td></tr></table></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="configuring-tomcat-clustering"></a>Cluster Configuration</h3></div></div></div><p>
 				Virgo Web Server supports standard Apache Tomcat cluster configuration.
 				By default, clustering of the embedded servlet container is disabled,
 				and the default configuration does not include any clustering information.
 				See  <a class="ulink" href="http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html" target="_top">Tomcat Clustering/Session Replication HOW-TO</a>
 				for detailed information about enabling and configuring clustering.
 			</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="configuring-tomcat-contexts"></a>Context Configuration</h3></div></div></div><p>
 					Virgo Web Server supports standard Apache Tomcat web application context configuration.
 					The <a class="ulink" href="http://tomcat.apache.org/tomcat-6.0-doc/config/index.html" target="_top">Apache Tomcat Configuration Reference</a> has a section on
 					<a class="ulink" href="http://tomcat.apache.org/tomcat-6.0-doc/config/context.html" target="_top">The Context Container</a> which describes the mechanism that
 					is used in VWS for searching context configuration files and details the context configuration properties.
 				</p><p>
 					Context configuration files may be placed in the following locations,
 					where <code class="literal">[enginename]</code> is the name of Tomcat's engine ('Catalina' by default) and <code class="literal">[hostname]</code> names
 					a virtual host ('localhost' by default), both of which are configured in <code class="literal">tomcat-server.xml</code>:
 					</p><div class="itemizedlist"><ul type="disc"><li><p>
 							<code class="literal">$SERVER_HOME/config/context.xml</code> provides the default context configuration file for all web applications.
 						</p></li><li><p>
 							The <code class="literal">$SERVER_HOME/config/[enginename]/[hostname]</code> directory may contain:
 					  		</p><div class="itemizedlist"><ul type="circle"><li><p>
 									The default context configuration for all web applications of a given virtual host in the file <code class="literal">context.xml.default</code>.
 								</p></li><li><p>
 									Individual web applications' context configuration files as described in the Apache Tomcat Configuration Reference.
 									For example, the context for a web application with
 									context path <code class="literal">foo</code> may be configured in <code class="literal">foo.xml</code>.
 					   			</p></li></ul></div><p>
 						</p></li></ul></div><p>
 				</p><p>
 					Note that the following context configuration features are not supported in Virgo Web Server:
 					</p><div class="itemizedlist"><ul type="disc"><li><p>
 							Custom class loaders.
 						</p></li><li><p>
 							Specifying the context path. This is specified using the <code class="literal">Web-ContextPath</code> header in the web application's
 							<code class="literal">MANIFEST.MF</code> file.
 						</p></li><li><p>
 							Specifying the document base directory.
 						</p></li></ul></div><p>
 				</p><p>
 					See <a class="link" href="#web-application-context-configuration" title="B.4&nbsp;Web Application Context Configuration File Copying">Web Application Context Configuration File Copying</a> for a known issue related to
 					providing a context configuration file inside a web application archive.
 				</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="configuring-provisioning-repository"></a>11.4&nbsp;Configuring the Local Provisioning Repository</h2></div></div></div><p>
 		    You configure the locations that Virgo Web Server includes in its provisioning repository
 		    by editing the <code class="literal">org.eclipse.virgo.repository.properties</code> file in the <code class="literal">$SERVER_HOME/config</code> directory.
 		    </p><p>When you specify a property in the file, use the format <code class="literal">repository-name.property=value</code>, where:
 		</p><div class="itemizedlist"><ul type="disc"><li><p><code class="literal">repository-name</code> refers to the name of the local repository.</p></li><li><p><code class="literal">property</code> refers to the name of a particular property.</p></li><li><p><code class="literal">value</code> refers to the value of the property.</p></li></ul></div><p>
 		</p><p>For example, <code class="literal">ext.type=external</code> specifies that the <code class="literal">type</code> property of the repository
 		with name <code class="literal">ext</code> is <code class="literal">external</code>.
         </p><p>
 			The <code class="literal">chain</code> property specifies the order in which Virgo Web Server searches the individual repositories
 			when it looks for dependencies.
 			The <code class="literal">chain</code> property uses the names of the individual repositories as specified in the individual repository properties;
 			for example, in the property <code class="literal">ext.type=external</code>, the name of the repository is <code class="literal">ext</code>.
 		</p><p>
 			The default repository configuration for a newly installed Virgo Web Server is as follows:
 			</p><pre class="programlisting">ext.type=external
 ext.searchPattern=repository/ext/{artifact}

 usr.type=watched
 usr.watchDirectory=repository/usr

 chain=ext,usr</pre><p>
 		</p><p>
 		The default configuration shown above has two searchpaths corresponding to the two default sub-directories of the <code class="literal">$SERVER_HOME/repository</code> directory created when you first install VWS: <code class="literal">ext</code> and <code class="literal">usr</code>. Virgo Web Server searches each of these individual repositories when locating entries for inclusion in the repository.  </p><p>
 	        The <code class="literal">chain</code> property shows the order in which Virgo Web Server searches the individual repositories: first <code class="literal">ext</code> and then <code class="literal">usr</code>.
 	</p><p>
 		The following table lists all the available properties that you can use to configure an individual repository.
 		Individual repositories as well as the repository search chain  are configured in the file
 		<code class="literal">$SERVER_HOME/config/org.eclipse.virgo.repository.properties</code>.
 		</p><div class="table"><a name="repository-options-table"></a><p class="title"><b>Table&nbsp;11.5.&nbsp;Repository Properties</b></p><div class="table-contents"><table summary="Repository Properties" style="border-collapse: collapse;border-top: 1.0pt solid ; border-bottom: 1.0pt solid ; border-left: 1.0pt solid ; border-right: 1.0pt solid ; "><colgroup><col><col></colgroup><thead><tr><th style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Property</th><th style="border-bottom: 1.0pt solid ; ">Description</th></tr></thead><tbody><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><span class="emphasis"><em><code class="literal">repository-name</code></em></span><code class="literal">.type</code></td><td style="border-bottom: 1.0pt solid ; ">
                           <p>
                             Specifies the type of path.  You can set this property to one of the following three valid values:
 			    </p><div class="itemizedlist"><ul type="disc"><li><p>
 				<code class="literal">external</code>: Specifies that this path points to a number of directories that satisfy a given search pattern
 				and are local to the current Virgo Web Server instance.
 				Use the <code class="literal">searchPattern</code> property to specify the directory search pattern.
 				</p></li><li><p>
 				<code class="literal">watched</code>: Specifies that this path points to a single directory, local to the current Virgo Web Server instance.
 				Virgo Web Server regularly scans watched repositories so it automatically picks up any changes to the artifacts in the directory at runtime.
 				Use the <code class="literal">watchDirectory</code> property to specify the watched directory
 				and the <code class="literal">watchInterval</code> property
 				to specify how often VWS checks the directory.
 				</p></li><li><p>
 				<code class="literal">remote</code>: Specifies that the path points to a remotely-hosted repository,
 				hosted by a remote instance of Virgo Web Server.
 				Use the <code class="literal">uri</code> property to specify the full URI of the remote repository.
 				You can also specify the optional <code class="literal">indexRefreshInterval</code> property.
 				</p></li></ul></div><p>
                           </p>

 			  <p>See <a class="link" href="#configuring-repository-watched-versus-external" title="Should I Configure a Watched or External Repository?">Watched or External Repository?</a>
 			  for additional information about when to configure watched or external repositories for your particular environment.
 			  </p>
 			</td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><span class="emphasis"><em><code class="literal">repository-name</code></em></span><code class="literal">.searchPattern</code></td><td style="border-bottom: 1.0pt solid ; "> <p>Specifies the pattern that an external repository uses when deciding which local directories it should search
 			when identifying artifacts.  Use this property together with <span class="emphasis"><em><code class="literal">repository-name</code></em></span><code class="literal">.type=external</code>.
 			See <a class="link" href="#configuring-provisioning-repository-search-paths" title="Search Paths: Additional Information">Search Paths: Additional Information</a>
 			for detailed information about specifying a search pattern.
 			</p> </td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><span class="emphasis"><em><code class="literal">repository-name</code></em></span><code class="literal">.watchDirectory</code></td><td style="border-bottom: 1.0pt solid ; "> <p>Specifies the single directory of a watched repository.
 			You can specify either an absolute or relative pathname for the directory.
 			If you specify a relative pathname, it is relative  to the root of the VWS installation (<code class="literal">$SERVER_HOME</code>).
 			Use this property together with <span class="emphasis"><em><code class="literal">repository-name</code></em></span><code class="literal">.type=watched</code>.
 			</p></td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><span class="emphasis"><em><code class="literal">repository-name</code></em></span><code class="literal">.watchInterval</code></td><td style="border-bottom: 1.0pt solid ; "> <p>Specifies the interval in seconds between checks of a watched directory by a watched repository.
 			This property is optional, if it is not specified the default interval of 5 seconds is used.
 			Use this property together with <span class="emphasis"><em><code class="literal">repository-name</code></em></span><code class="literal">.type=watched</code>.
 			</p> </td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><span class="emphasis"><em><code class="literal">repository-name</code></em></span><code class="literal">.uri</code></td><td style="border-bottom: 1.0pt solid ; "> <p>Specifies the URI of the hosted repository to which a remote repository connects.
 			The value of this property takes the following format:
 			</p>
 				<p><code class="literal">http://</code><span class="emphasis"><em><code class="literal">host</code></em></span><code class="literal">:</code><span class="emphasis"><em><code class="literal">port</code></em></span><code class="literal">/org.eclipse.virgo.apps.repository/</code><span class="emphasis"><em><code class="literal">remote-repository-name</code></em></span></p>
                       <p>where:
 			</p><div class="itemizedlist"><ul type="disc"><li><p>
 				<span class="emphasis"><em><code class="literal">host</code></em></span> refers to the computer on which the remote VWS instance hosts the remote repository.
 				</p></li><li><p>
 				<span class="emphasis"><em><code class="literal">port</code></em></span> refers to Tomcat listen port of the remote VWS instance which hosts the remote repository.
 				</p></li><li><p>
 				<span class="emphasis"><em><code class="literal">remote-repository-name</code></em></span> refers to the name of the remote repository,
 				as specified in the <code class="literal">hostedRepository.properties</code> file of the remote VWS instance.
 				</p></li></ul></div><p>
                        </p>
                        <p>Use this property together with <span class="emphasis"><em><code class="literal">repository-name</code></em></span><code class="literal">.type=remote</code>.
                        </p> </td></tr><tr><td style="border-right: 1.0pt solid ; "><span class="emphasis"><em><code class="literal">repository-name</code></em></span><code class="literal">.indexRefreshInterval</code></td><td style="">
 				<p>
 					Specifies the interval in seconds between checks by a remote repository that
 					its local copy of the hosted repository index is up-to-date
 					(a remote repository acts as a proxy for a hosted repository and thus it holds a local copy of the hosted repository&#8217;s index).
 					This property is optional,
 					if it is not specified the default interval of 5 seconds is used.
 				</p>
 				<p>Use this property together with <span class="emphasis"><em><code class="literal">repository-name</code></em></span><code class="literal">.type=remote</code>.</p> </td></tr></tbody></table></div></div><p><br class="table-break">
 	</p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="configuring-repository-watched-versus-external"></a>Should I Configure a Watched or External Repository?</h3></div></div></div><p>The main difference between a watched and an external repository is that Virgo Web Server regularly scans watched directories
 		and automatically picks up any changed artifacts,
 		while VWS scans external directories only at startup, and then only if there is no cached index available.
 		This means that VWS always performs a scan of an external repository when you start the server
 		with the <code class="literal">-clean</code> (as this deletes the index) and only scans during a normal startup if the index isn&#8217;t there because,
 		for example, this is the first time you start the server.
 		</p><p>There is a performance cost associated with using a watched repository due to VWS using resources
 		to scan the directory at the configured interval.
 		The cost is small if the watched repository contains just a few artifacts; however,
 		the performance cost increases as the number of artifacts increases.
 		</p><p> For this reason, we recommend that you put most of your dependencies in external repositories,
 		even when in development mode.
 		If you make any changes to the artifacts in the external repositories,
 		remember to restart VWS with the <code class="literal">-clean</code> option so that the server picks up any changes.
 		Use watched directories for artifacts that you are prototyping, actively updating, or when adding new dependencies
 		so that VWS quickly and easily picks them up.
 		To increase performance even during development, however, you can use an external repository for most of your dependencies,
 		in particular the ones that are fairly static.
 		</p><p>In production environments, where dependencies should not change,
 		we recommend that you use <span class="emphasis"><em>only</em></span> external repositories.
 		</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="configuring-provisioning-repository-search-paths"></a>Search Paths: Additional Information</h3></div></div></div><p>
 	            The <span class="emphasis"><em><code class="literal">repository-name</code></em></span><code class="literal">.searchPattern</code> and
 	            <span class="emphasis"><em><code class="literal">repository-name</code></em></span><code class="literal">.watchDirectory</code> properties specify search paths
 	            for external and watched repositories, respectively,
 	            that define a physical location that Virgo Web Server searches when looking for a library or bundle dependency.
 	            If a search path is relative, its location is relative to the root of the installation,
 	            in other words, the <code class="literal">$SERVER_HOME</code> directory.
    	        </p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="configuring-provisioning-repository-search-paths-wildcards"></a>Using Wildcards</h4></div></div></div><p>
 		            Search paths specified with the <span class="emphasis"><em><code class="literal">repository-name</code></em></span><code class="literal">.searchPattern</code> property
 		            provide support for wildcards.
 		            In the entries above, the path segments surrounded by curly braces,
 		            for example <code class="literal">{bundle}</code> and <code class="literal">{library}</code>,
 		            are wildcards entries for a directory with any name.
 		            Allowing wildcards to be named in this way is intended to improve the readability of search path configuration.
 		        </p><p>
 			        In addition to supporting the above-described form of wildcards, Virgo Web Server also supports Ant-style paths,
 			        that is <code class="literal">*</code> and <code class="literal">**</code> can be used to represent any directory and
 			        any series of directories, respectively.
 			        For example, <code class="literal">repository/usr/{bundle}</code> and <code class="literal">repository/usr/*</code>
 			        are equivalent.
 			    </p><p>
 				    A common usage of the <code class="literal">**</code> wildcard is to allow dependencies stored in a directory structure of varying depth,
 				    such as a local Maven repository, to be provisioned by the Virgo Web Server.
 				</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="configuring-provisioning-repository-using-system-properties"></a>Using System Properties</h3></div></div></div><p>
 				You can use system properties when specifying the values of the <span class="emphasis"><em><code class="literal">repository-name</code></em></span><code class="literal">.searchPattern</code>,
 				<span class="emphasis"><em><code class="literal">repository-name</code></em></span><code class="literal">.watchDirectory</code>,
 				<span class="emphasis"><em><code class="literal">repository-name</code></em></span><code class="literal">.watchInterval</code>,
 				<span class="emphasis"><em><code class="literal">repository-name</code></em></span><code class="literal">.uri</code>,
 				and <span class="emphasis"><em><code class="literal">repository-name</code></em></span><code class="literal">.indexRefreshInterval</code>
 				properties.
 				You reference system properties as <code class="literal">${system.property.name}</code>;
 				for example, a search path of <code class="literal">${user.home}/repository/bundles</code> references the
 				<code class="literal">repository/bundles</code> directory in the user&#8217;s home directory.
 			</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="configuring-provisioning-repository-examples"></a>Example Repository Configurations</h3></div></div></div><p>
 		        The following examples provide sample configuration that could be used for some common use cases.
 		    </p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="configuring-provisioning-repository-examples-ivy"></a>Add an Ivy cache repository</h4></div></div></div><p>The following example shows how to add an external repository whose location is actually an Ivy cache.</p><p><span class="emphasis"><em>Note that Ivy repositories can contain bundles which will conflict with the normal operation of Virgo, so care should
 				be exercised when adding such an external repository.</em></span></p><pre class="programlisting">ext.type=external
 ext.searchPattern=repository/ext/{artifact}

 usr.type=watched
 usr.watchDirectory=repository/usr

 ivy-repo.type=external
 ivy-repo.searchPattern=${user.home}/.ivy2/cache/{org}/{name}/{version}/{bundle}.jar

 chain=ext,usr,ivy-repo</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="configuring-provisioning-repository-examples-maven"></a>Add a Maven local repository</h4></div></div></div><p>The following example shows how to add an external repository whose location is actually a Maven repository.</p><p><span class="emphasis"><em>Note that Maven repositories can contain bundles which will conflict with the normal operation of Virgo, so care should
 				be exercised when adding such an external repository.</em></span></p><pre class="programlisting">ext.type=external
 ext.searchPattern=repository/ext/{artifact}

 usr.type=watched
 usr.watchDirectory=repository/usr

 maven-repo.type=external
 maven-repo.searchPattern=${user.home}/.m2/repository/**/{bundle}.jar

 chain=ext,usr,maven-repo</pre></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="configuring-repository-examples-remote-watched"></a>Add remote and watched repositories</h4></div></div></div><p>The following example shows the default <code class="literal">org.eclipse.virgo.repository.properties</code> file
 		from a freshly-installed VWS, but then updated to include new remote and watched repositories.
 		Both of these repositories are part of the repository chain.
 		</p><p>The remote repository is called <code class="literal">remote-repo</code>.
 		The URI of the hosted repository from which <code class="literal">remote-repo</code> gets its artifacts is
 		<code class="literal">http://my-host:8080/org.eclipse.virgo.apps.repository/my-hosted-repo</code>;
 		this means that there is a VWS instance running on host <code class="literal">my-host</code>
 		whose Tomcat server listens at the default port, <code class="literal">8080</code>,
 		and this server instance hosts a repository called <code class="literal">my-hosted-repo</code>,
 		configured in the <code class="literal">hostedRepository.properties</code> file of the remote server instance.
 		The remote repository checks for changes in the hosted repository every 30 seconds.
 		</p><p>The watched repository is called <code class="literal">watched-repo</code> and the directory that holds the artifacts
 		is <code class="literal">repository/watched</code>,
 		relative to the installation directory of the VWS instance.
 		The server checks for changes in this watched repository every 5 seconds.
 		</p><pre class="programlisting">ext.type=external
 ext.searchPattern=repository/ext/{artifact}

 usr.type=watched
 usr.watchDirectory=repository/usr

 remote-repo.type=remote
 remote-repo.uri=http://my-host:8080/org.eclipse.virgo.apps.repository/my-hosted-repo
 remote-repo.indexRefreshInterval=30

 watched-repo.type=watched
 watched-repo.watchedDirectory=repository/watched
 watched-repo.watchedInterval=5

 chain=ext,usr,remote-repo,watched-repo</pre></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="configuring-hosted-repo"></a>11.5&nbsp;Configuring a Hosted Repository</h2></div></div></div><p>You configure a VWS instance to host a repository
 		by editing the <code class="literal">$SERVER_HOME/config/org.eclipse.virgo.repository.hosted.properties</code> file;
 		remote clients can then access the artifacts in this hosted repository and use them locally.
 		</p><p>When you specify a property in the file, use the format <code class="literal">repository-name.property=value</code>, where:
              </p><div class="itemizedlist"><ul type="disc"><li><p><code class="literal">repository-name</code> refers to the name of the hosted repository.</p></li><li><p><code class="literal">property</code> refers to the name of a particular property.</p></li><li><p><code class="literal">value</code> refers to the value of the property.</p></li></ul></div><p>
               </p><p>For example, <code class="literal">my-hosted-repo.type=external</code> specifies that the <code class="literal">type</code> property
              of the <code class="literal">my-hosted-repository</code> repository is <code class="literal">external</code>.
              </p><p>The following table lists the properties that you can include in the <code class="literal">hostedRepository.properties</code> file.
 		</p><div class="table"><a name="hosted-repository-properties-table"></a><p class="title"><b>Table&nbsp;11.6.&nbsp;Hosted Repository Properties</b></p><div class="table-contents"><table summary="Hosted Repository Properties" style="border-collapse: collapse;border-top: 1.0pt solid ; border-bottom: 1.0pt solid ; border-left: 1.0pt solid ; border-right: 1.0pt solid ; "><colgroup><col><col></colgroup><thead><tr><th style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Property</th><th style="border-bottom: 1.0pt solid ; ">Description</th></tr></thead><tbody><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><span class="emphasis"><em><code class="literal">repository-name</code></em></span><code class="literal">.type</code></td><td style="border-bottom: 1.0pt solid ; ">Specifies the type of path of the hosted repository.
 				All paths are local to the current VWS instance.
 				You can set this property to one of the following valid values:
 	<div class="itemizedlist"><ul type="disc"><li><p>
     	<code class="literal">external</code>: Specifies that this path points to a number of directories that satisfy a given search pattern.
     	Use the <code class="literal">searchPattern</code> property to specify the directory search pattern.
     	</p></li><li><p>
 	<code class="literal">watched</code>: Specifies that this path points to a single directory.
 	Virgo Web Server regularly scans watched repositories so it automatically picks up any changes to the artifacts in the directory at runtime.
 	Use the <code class="literal">watchDirectory</code> property to specify the actual watched directory and the <code class="literal">watchInterval</code> property
 	to specify how often VWS checks the directory.
 	</p></li></ul></div>
 			  <p>See <a class="link" href="#configuring-repository-watched-versus-external" title="Should I Configure a Watched or External Repository?">Watched or External Repository?</a>
 			  for additional information about when to configure watched or external repositories for your particular environment.
 			  </p>
 				</td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><span class="emphasis"><em><code class="literal">repository-name</code></em></span><code class="literal">.searchPattern</code></td><td style="border-bottom: 1.0pt solid ; "> <p>Specifies the pattern that an external hosted repository uses when deciding which
 			local directories it should search when identifying artifacts.
 			Use this property when <code class="literal">repository-name.type=external</code>.
 			See <a class="link" href="#configuring-provisioning-repository-search-paths" title="Search Paths: Additional Information">Search Paths: Additional Information</a>
 			for detailed information about specifying a search pattern.
 			</p> </td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><span class="emphasis"><em><code class="literal">repository-name</code></em></span><code class="literal">.watchDirectory</code></td><td style="border-bottom: 1.0pt solid ; "> <p>Specifies the single directory of a watched hosted repository.
 			You can specify either an absolute or relative pathname for the directory.
 			If you specify a relative pathname, it is relative to the root of the VWS installation (<code class="literal">$SERVER_HOME</code>).
 			Use this property when <code class="literal">repository-name.type=watched</code>.
 			</p></td></tr><tr><td style="border-right: 1.0pt solid ; "><span class="emphasis"><em><code class="literal">repository-name</code></em></span><code class="literal">.watchInterval</code></td><td style=""> <p>Specifies the interval in seconds between checks of a watched directory by a watched hosted repository.
 			This property is optional.  Use this property when <code class="literal">repository-name.type=watched</code>.
 			</p> </td></tr></tbody></table></div></div><br class="table-break"><p>The following sample shows a <code class="literal">org.eclipse.virgo.repository.hosted.properties</code> file with a single external repository
 		called <code class="literal">my-hosted-repo</code> with search pattern <code class="literal">$SERVER_HOME/repository/hosted/*</code>.
 		</p><pre class="programlisting">my-hosted-repo.type=external
 my-hosted-repo.searchPattern=repository/hosted/*</pre><p>
 		</p><p>See <a class="link" href="#configuring-repository-examples-remote-watched" title="Add remote and watched repositories">Example of watched and remote repositories</a>
 	for details on how a local repository can remotely access the artifacts in this hosted repository.
 	</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="configuring-osgi-framework"></a>11.6&nbsp;Configuring the OSGi Framework</h2></div></div></div><p>
 			This section provides information about configuring the OSGi framework by updating the following files in the
 			<code class="literal">$SERVER_HOME/lib</code> directory:
 		</p><div class="table"><a name="configuring-osgi-framework-table"></a><p class="title"><b>Table&nbsp;11.7.&nbsp;OSGi Framework Configuration Files </b></p><div class="table-contents"><table summary="OSGi Framework Configuration Files " style="border-collapse: collapse;border-top: 1.0pt solid ; border-bottom: 1.0pt solid ; border-left: 1.0pt solid ; border-right: 1.0pt solid ; "><colgroup><col><col></colgroup><thead><tr><th style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Property File</th><th style="border-bottom: 1.0pt solid ; ">Description</th></tr></thead><tbody><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><code class="literal">org.eclipse.virgo.kernel.launch.properties</code></td><td style="border-bottom: 1.0pt solid ; ">Configures <a class="link" href="#configuring-framework-properties" title="Configuring OSGi Framework Properties">OSGi framework properties</a>.</td></tr><tr><td style="border-right: 1.0pt solid ; "><code class="literal">java6-server.profile</code></td><td style="">Configures the <a class="link" href="#configuring-framework-profile" title="Configuring OSGi Framework Profile">OSGi framework profile</a>.</td></tr></tbody></table></div></div><br class="table-break"><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="configuring-framework-properties"></a>Configuring OSGi Framework Properties</h3></div></div></div><p>
 				You specify the framework properties in the <code class="literal">$SERVER_HOME/lib/org.eclipse.virgo.kernel.launch.properties</code> file. The
 				properties most relevant to users are described in the following table.
 			</p><p>
 				<span class="bold"><strong>WARNING:</strong></span> We strongly recommend that you update only the
 				<code class="literal">org.eclipse.virgo.suppress.heap.dumps</code> property; updating the other properties could cause VWS
 				to fail. These properties are documented for your information only.
 			</p><div class="table"><a name="configuring-framework-properties-table"></a><p class="title"><b>Table&nbsp;11.8.&nbsp;Framework Properties</b></p><div class="table-contents"><table summary="Framework Properties" style="border-collapse: collapse;border-top: 1.0pt solid ; border-bottom: 1.0pt solid ; border-left: 1.0pt solid ; border-right: 1.0pt solid ; "><colgroup><col><col></colgroup><thead><tr><th style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Property</th><th style="border-bottom: 1.0pt solid ; ">Description</th></tr></thead><tbody><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><code class="literal">launcher.bundles</code></td><td style="border-bottom: 1.0pt solid ; ">
 								This property lists the bundles that comprise the kernel using <code class="literal">file:</code> URIs.
 								Bundles to be started are tagged with a trailing <code class="literal">@start</code>.
 							</td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><code class="literal">org.eclipse.virgo.suppress.heap.dumps</code></td><td style="border-bottom: 1.0pt solid ; ">
 								Set to 'false' by default this property will prevent heap dumps being contributed to dumps taken during a
 								First Failure Data Capture (FFDC) event. When the heap dumps are produced they will be located along with
 								the other dump artifacts in the <code class="literal">$SERVER_HOME/serviceability/dump/</code> folder.
 							</td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><code class="literal">osgi.console</code></td><td style="border-bottom: 1.0pt solid ; ">
 								Specifies the port number which will be used by an Equinox console <span class="bold"><strong>attached to the kernel</strong></span>.
 								The usual port number is 2402, to avoid clashing with any console attached to the user region.
 								If specified, the Equinox console is enabled (without the Equinox Console Extension) during kernel start.
 								If not specified, the Equinox console is not available for the kernel.
 							</td></tr><tr><td style="border-right: 1.0pt solid ; "><code class="literal">osgi.java.profile</code></td><td style="">
 								Specifies the profile to use using a <code class="literal">file:</code> URI with default value
 								<code class="literal">file:lib/java6-server.profile</code>.
 							</td></tr></tbody></table></div></div><br class="table-break"></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="configuring-framework-profile"></a>Configuring OSGi Framework Profile</h3></div></div></div><p>
 				You specify the framework profile in the <code class="literal">$SERVER_HOME/lib/java6-server.profile</code> file. The
 				properties most relevant to users are described in the following table.
 			</p><p>
 				<span class="bold"><strong>WARNING:</strong></span> We advise you not to change the framework profile unless you are sure you know exactly what
 				you are doing; updating the profile could cause VWS to fail.
 			</p><div class="table"><a name="configuring-framework-profile-table"></a><p class="title"><b>Table&nbsp;11.9.&nbsp;Framework Profile Properties</b></p><div class="table-contents"><table summary="Framework Profile Properties" style="border-collapse: collapse;border-top: 1.0pt solid ; border-bottom: 1.0pt solid ; border-left: 1.0pt solid ; border-right: 1.0pt solid ; "><colgroup><col><col></colgroup><thead><tr><th style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Property</th><th style="border-bottom: 1.0pt solid ; ">Description</th></tr></thead><tbody><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; "><code class="literal">org.osgi.framework.bootdelegation</code></td><td style="border-bottom: 1.0pt solid ; ">
 								<p>
 									This property specifies the packages which are loaded by delegation to the application class loader.
 									Bundles can load classes belonging to these packages without importing the packages.
 									The <code class="literal">.*</code> wildcard matches any package suffix. <code class="literal">java.*</code> is always
 									boot delegated and must not be specified in this property.
 								</p>
 								<p>
 									A common reason for adding packages to this property is to run VWS under a performance profiler.
 								</p>
 							</td></tr><tr><td style="border-right: 1.0pt solid ; "><code class="literal">org.osgi.framework.system.packages</code></td><td style="">
 								<p>
 									This property specifies the packages which are exported by the system bundle.
 								</p>
 								<p>
 									It is very occasionally necessary to extend the set, for example when configuring email logging appenders since the
 									implementation of <code class="literal">javax.mail</code>	is intimately related to the implementation of
 									<code class="literal">javax.activation</code>.
 								</p>
 								<p>
 									To make the corresponding classes available for loading, the relevant JAR file(s) should be placed in
 									<code class="literal">$SERVER_HOME/lib</code> so that they will be added to the application class path.
 								</p>
 							</td></tr></tbody></table></div></div><br class="table-break"></div></div></div><div class="appendix" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="log-codes"></a>Appendix&nbsp;A.&nbsp;Event log codes</h2></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="event-log-codes-format"></a>A.1&nbsp;Format of the event log codes</h2></div></div></div><p>
 Event log codes issued by VWS have the general syntax
 <code class="literal">&lt;XXnnnnL&gt;</code> where:
 </p><div class="informaltable"><table style="border: none;"><colgroup><col><col></colgroup><tbody><tr><td style=""><code class="literal">XX</code></td><td style="">
 is a two-letter code (upper-case) identifying the area of the VWS code which issued the log message;
 </td></tr><tr><td style=""><code class="literal">nnnn</code></td><td style="">
 is a four-digit message number; and
 </td></tr><tr><td style=""><code class="literal">L</code></td><td style="">
 is a single-letter (upper-case) code identifying the level of the message.
 </td></tr></tbody></table></div><p>
 </p><p>
 The two-letter codes are (this list is not complete):
 </p><div class="informaltable"><table style="border: none;"><colgroup><col><col></colgroup><tbody><tr><td style=""><code class="literal">AG</code></td><td style=""><code class="literal">org.eclipse.virgo.kernel.agent.dm</code></td></tr><tr><td style=""><code class="literal">DE</code></td><td style=""><code class="literal">org.eclipse.virgo.kernel.deployer.core</code></td></tr><tr><td style=""><code class="literal">HD</code></td><td style=""><code class="literal">org.eclipse.virgo.kernel.deployer.hot</code></td></tr><tr><td style=""><code class="literal">HR</code></td><td style=""><code class="literal">org.eclipse.virgo.apps.repository.core</code></td></tr><tr><td style=""><code class="literal">KE</code></td><td style=""><code class="literal">org.eclipse.virgo.kernel.core</code></td></tr><tr><td style=""><code class="literal">KS</code></td><td style=""><code class="literal">org.eclipse.virgo.kernel.services</code></td></tr><tr><td style=""><code class="literal">OF</code></td><td style=""><code class="literal">org.eclipse.virgo.kernel.osgi</code></td></tr><tr><td style=""><code class="literal">RP</code></td><td style=""><code class="literal">org.eclipse.virgo.repository</code></td></tr><tr><td style=""><code class="literal">TC</code></td><td style=""><code class="literal">org.eclipse.virgo.web.tomcat</code></td></tr><tr><td style=""><code class="literal">UR</code></td><td style=""><code class="literal">org.eclipse.virgo.kernel.userregion</code></td></tr><tr><td style=""><code class="literal">WE</code></td><td style=""><code class="literal">org.eclipse.virgo.web.core</code></td></tr></tbody></table></div><p>

 </p><p>
 The four-digit numbers identify the message text (with placeholders for inserted values). These are not listed here, but can be discovered by examining the files called
 <code class="literal">EventLogMessages.properties</code>, found in the relevant packages.
 </p><p>
 The single-digit level code is one of:
 </p><div class="informaltable"><table style="border: none;"><colgroup><col><col></colgroup><tbody><tr><td style=""><code class="literal">E</code></td><td style="">Error level: enabled if level is <code class="literal">ERROR</code>.</td></tr><tr><td style=""><code class="literal">W</code></td><td style="">Warning level: enabled if level is <code class="literal">WARNING</code> or above.</td></tr><tr><td style=""><code class="literal">I</code></td><td style="">Info level: enabled if level is <code class="literal">INFO</code> or above.</td></tr><tr><td style=""><code class="literal">D</code></td><td style="">Debug level: enabled if level is <code class="literal">DEBUG</code> or above.</td></tr><tr><td style=""><code class="literal">T</code></td><td style="">Trace level: always enabled.</td></tr></tbody></table></div><p>
 There are never two messages with the same prefix and number, but with different levels.
 </p></div></div><div class="appendix" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="known-issues"></a>Appendix&nbsp;B.&nbsp;Known Issues</h2></div></div></div><p>This section describes known issues that you might run into, along with corresponding workarounds.  </p><p>For the full list of known issues, see <a class="ulink" href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;order=Importance;classification=RT;product=Virgo" target="_top">Virgo bugs in Eclipse Bugzilla</a>.  The bugs are organised by component as well as by release.  You can also use bugzilla to enter a new issue if you cannot find an existing issue that describes the problem you are running into, but it's probably worth asking on the <a class="ulink" href="http://www.eclipse.org/forums/index.php?t=thread&amp;frm_id=159" target="_top">Virgo community forum</a> first.</p><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="known-issues-firewall-timeout"></a>B.1&nbsp;Timeout During Startup Due to Firewall Settings</h2></div></div></div><p>
 			The VWS will fail to start correctly if it is prevented from
 			connecting to needed ports by the firewall. Typically this manifests
 			as error <code class="literal">SPPM0003E</code> . Configuring the firewall to
 			allow the VWS process to bind to the necessary ports will prevent
 			this error from occurring.
 		</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="known-issues-perm-gen-sun-vm"></a>B.2&nbsp;OutOfMemoryError: PermGen space running on Sun VM</h2></div></div></div><p>
 			As a result of Sun Java bug
 			<a class="ulink" href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4957990" target="_top">4957990</a>,
 			the Virgo Web Server may consume more PermGen space than expected when running with the
 			server HotSpot compiler. This problem may be resolved by configuring the
 			<code class="literal">JAVA_OPTS</code> environment variable to specify an increased
 			<code class="literal">MaxPermSize</code>, for example <code class="literal">-XX:MaxPermSize=128M</code>.
 		</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="alternate-serviceability-work"></a>B.3&nbsp;Alternate <code class="literal">serviceability</code> and <code class="literal">work</code> Directories</h2></div></div></div><p>
 			Although an alternate <code class="literal">config</code> directory may be specified on startup, there is no way to specify
 			alternate <code class="literal">serviceability</code> or <code class="literal">work</code> directories. This is covered by
 			<a class="ulink" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=307737" target="_top">bug 307737</a> which also describes a workaround.
 		</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="web-application-context-configuration"></a>B.4&nbsp;Web Application Context Configuration File Copying</h2></div></div></div><p>If a web application, packaged as an archive rather than a directory, includes context configuration in <code class="literal">META-INF/context.xml</code>,
 		Virgo copies this file to <code class="literal">$SERVER_HOME/config/[enginename]/[hostname]/[contextpath].xml</code>.
 		If the application is redeployed, the copy of the context configuration overrides any updated context configuration included in
 		<code class="literal">META-INF/context.xml</code>. To use the updated context configuration, the user must delete the copy of the file before redeploying.
 		This is covered by
 			<a class="ulink" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=328683" target="_top">bug 328683</a>.
 		</p></div></div><div class="appendix" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="furtherreading"></a>Appendix&nbsp;C.&nbsp;
 		Further Reading
 	</h2></div></div></div><p>
 		<a class="ulink" href="../../virgo-programmer-guide/html/index.html" target="_top">
 			Virgo Web Server Programmer Guide
 		</a>
 	</p><p>
 		<a class="ulink" href="http://static.springframework.org/spring/docs/2.5.x/reference/index.html" target="_top">
 			Spring Framework Reference Guide
 		</a>
 	</p><p>
 		<a class="ulink" href="http://static.springframework.org/osgi/docs/current/reference/html/" target="_top">
 			Spring Dynamic Modules Reference Guide
 		</a>
 	</p><p>
 		<a class="ulink" href="http://logback.qos.ch/manual" target="_top">
 			The Logback Manual
 		</a>
 	</p></div></div><!--Begin LoopFuse code--><script src="http://loopfuse.net/webrecorder/js/listen.js" type="text/javascript"></script><script type="text/javascript">
 			_lf_cid = "LF_48be82fa";
 			_lf_remora();
 		</script><!--End LoopFuse code--></body></html>