This section describes the provisioning repository feature of Virgo Web Server, the reasons for using it, and how to configure it.
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.
The way you express this dependency depends on the artifact. For example, a plan is by definition a list of dependent bundles.
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 Import-Package
, Import-Bundle
, or Import-Library
manifest header in the MANIFEST.MF
file of your application. The Import-Package
header is standard to OSGi; Import-Bundle
and Import-Library
, however, are specific to Virgo Web Server.
For additional details about the creation and usage of libraries, as well as general information about dependencies, see Programmer’s Guide.
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:
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’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.
The provisioning repository for a particular instance of Virgo Web Server can include artifacts in the following general locations:
external
directories that adhere to a specified search pattern and are scanned by VWS just on a clean startup, or watched
directories that point to a single directory location and which VWS scans on a regular basis.
You configure the provisioning repository using the $SERVER_HOME/config/org.eclipse.virgo.repository.properties
file.
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 $SERVER_HOME/config/org.eclipse.virgo.repository.hosted.properties
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.
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.
When you first install Virgo Web Server, the local provisioning repository is located at $SERVER_HOME/repository
by default and consists of two main directories: ext
and usr
. The ext
directory contains artifacts supplied with the Virgo Web Server and usr
contains artifacts supplied by the user.
To install an artifact into the default repository, simply copy it into the $SERVER_HOME/repository/usr
directory.
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: $SERVER_HOME/config/org.eclipse.virgo.repository.properties
.
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.
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 my-exciting-bundle.2.1.0.jar
.
For watched repositories, such as $SERVER_HOME/repository/usr
, the Virgo Web Server automatically detects changes
at runtime, thereby avoiding the need to restart the VWS.
Of specific relevance during development is picking up changes to an application’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.