In the context of Virgo Server for Apache Tomcat, deploying refers to installing an artifact to the server and then starting it to make it available to users. Typically, when you install an artifact, VTS automatically starts it as long as the server is able to successfully resolve all its dependencies. For this reason, the terms deploying and installing are often used interchangeably.
You deploy artifacts to Virgo Server for Apache Tomcat using either the hot-deploy directory on the file system or by using the Admin Console. The artifacts that you can deploy to VTS are:
![]() | Note |
---|---|
This section currently is ONLY relevant for Virgo Nano. |
Virgo Nano Web supports deployment of WAR files which are transformed into Web Application Bundles. This process involves automatic creation of an OSGi manifest with all relevant OSGi header plus the very important Web-ContextPath header. Its value defines how the deployed WAR file can be requested. There is a limitation about this process that the automatic generation only creates a flat context path which equals the name of your WAR file. Virgo Nano Web supports generation of a nested one.
In order to benefit from this flexibility all you need to do is just to add hashes '#' to your WAR file name in the places where you want to have slashes in your web context path. Here is an example:
myWarFile.war would result into "/myWarFile" web context path
my#War#File.war would result into "/my/War/File" web context path
The symbolic name of the resulting WAB file is the same as the WAR file name but the hashes '#' are replaced with dots '.'.
![]() | Note |
---|---|
This section currently is ONLY relevant for Virgo Nano. |
To hot deploy an artifact initially in bulk mode, copy it into the pickup directory (by default $SERVER_HOME/pickup
) and start up the server. Upon this startup all the artifacts in the pickup
directory will get first installed and resolved and only then they will be started.
This solves the problem where artifacts depend on each other and when not in bulk mode the install order is not guaranteed therefore errors could occur.
This is only available as part of the initial scan of the pickup
directory. Subsequently it goes back to the known mode of single file handled at a time.
prompt$ cd /home/applications prompt$ cp BundleA.jar $SERVER_HOME/pickup prompt$ cp BundleWithDependencyOnA.jar $SERVER_HOME/pickup prompt$ cd $SERVER_HOME/bin prompt$ ./startup.sh
When the server is started, artifacts are hot deployed and messages similar to the following appear in the log file:
[2009-12-10 06:41:01.021] fs-watcher <HD0001I> Hot deployer processing 'INITIAL' event for file 'BundleA.jar; BundleWithDependencyOnA.jar; '. [2009-12-10 06:41:01.087] fs-watcher <DE0000I> Installing bundle 'BundleA' version '0.0.0'. [2009-12-10 06:41:01.274] fs-watcher <DE0001I> Installed bundle 'BundleA' version '0.0.0'. [2009-12-10 06:41:01.087] fs-watcher <DE0000I> Installing bundle 'BundleWithDependencyOnA' version '0.0.0'. [2009-12-10 06:41:01.274] fs-watcher <DE0001I> Installed bundle 'BundleWithDependencyOnA' version '0.0.0'. [2009-12-10 06:41:01.397] fs-watcher <DE0004I> Starting bundle 'BundleA' version '0.0.0'. [2009-12-10 06:41:01.550] start-signalling-1 <DE0005I> Started bundle 'BundleA' version '0.0.0'. [2009-12-10 06:41:01.397] fs-watcher <DE0004I> Starting bundle 'BundleWithDependencyOnA' version '0.0.0'. [2009-12-10 06:41:01.550] start-signalling-1 <DE0005I> Started bundle 'BundleWithDependencyOnA' version '0.0.0'.
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.
If there are no problems, Virgo Nano automatically starts the artifacts so that they are immediately available to users.
Bulk deployment can be disabled and reverted back to the old one-file-at-a-time processing by removing this line from $SERVER_HOME/configuration/config.ini
:
org.eclipse.virgo.fschecker.initialEventMode=bulk
To hot deploy an artifact, copy it into the pickup directory (by default $SERVER_HOME/pickup
):
prompt$ cd /home/applications prompt$ cp helloWorld.war $SERVER_HOME/pickup
When the artifact is hot deployed, messages similar to the following appear in the log file:
[2009-12-10 06:41:01.021] fs-watcher <HD0001I> Hot deployer processing 'CREATED' event for file 'helloWorld.war'. [2009-12-10 06:41:01.087] fs-watcher <DE0000I> Installing bundle 'helloWorld' version '0.0.0'. [2009-12-10 06:41:01.274] fs-watcher <DE0001I> Installed bundle 'helloWorld' version '0.0.0'. [2009-12-10 06:41:01.397] fs-watcher <DE0004I> Starting bundle 'helloWorld' version '0.0.0'. [2009-12-10 06:41:01.414] Thread-3 <WE0000I> Starting web bundle 'helloWorld' version '0.0.0' with context path '/helloWorld'. [2009-12-10 06:41:01.537] Thread-3 <WE0001I> Started web bundle 'helloWorld' version '0.0.0' with context path '/helloWorld'. [2009-12-10 06:41:01.550] start-signalling-1 <DE0005I> Started bundle 'helloWorld' version '0.0.0'.
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.
If there are no problems, VTS automatically starts the artifact so that it is immediately available to users.
The Admin Console allows you to upload a file, which will be deployed automatically, from your local file system to the Virgo Server for Apache Tomcat. As soon as Virgo Server for Apache Tomcat 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.
See Installing a New Artifact for details about using the Admin Console to install (deploy) an artifact. See The Web Admin Console for general information about the Admin Console.
When you deploy an artifact, either using hot-deployment or the Admin Console, Web Server copies the file to its work directory (SERVER_HOME/work
) 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 Server for Apache Tomcat starts the artifact.
Because of all these additional internal activities, you should NOT simply copy the artifact into the work
directory and assume it will be deployed, because Virgo Server for Apache Tomcat will not do so.
When deploying bundles that have dependencies, it is important that you deploy them in the correct order. Virgo Server for Apache Tomcat honors this ordering when it redeploys the artifacts on startup.
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 cp
command, provides no guarantee of ordering.
Artifacts may be shared by plans. Sharing occurs when a plan is deployed which references an artifact that was previously deployed or is a child artifact of a plan that was previously deployed. Sharing also occurs when an artifact is deployed which is already a child of a deployed plan, but in this case the shared artifact may not appear as a top-level artifact, for example, in the Admin Console, in the shell, and in JMX.
Sharing is taken into account when artifacts are stopped. A shared artifact is stopped only when all the artifacts referencing the shared artifact have been stopped and, if the shared artifact was deployed in its own right, the artifact itself has been stopped.