Jump to: navigation, search

Virgo/Community/Migrating from 3.0.x to 3.5.0

Modified Directory Layout

Virgo's distributions will have a slightly modified directory layout from 3.5.0 onwards. It closely matches an Eclipse-like directory layout. This enables us to seamlessly provide p2 initial provisioning support to all Virgo distributions. The documentation will be thoroughly updated with all changes and the configuration impact on the server.

The main differences are:

  • relocated Virgo configuration directory (from /config to /configuration)
  • relocated Equinox configuration folder(from /work/osgi/configuration to /configuration) - this is where the framework stores its caches and other bundle data
  • relocated lib/kernel folder(from /lib/kernel to /plugins)
  • relocated java6-server.profile (from /lib to /configuration)

As as result all configuration files are now located in a single directory - /configuration This also brings changes to the OSGi configuration of the server previously found in lib/org.eclipse.virgo.kernel.launch.properties. It is now contained in the standard for Equinox config.ini file in the /configuration directory.

New Default Launcher

Equinox launcher is now the default Virgo Launcher. The consequences of this change are covered in Virgo's user guide in chapter 7 and chapter 7.8 cover the new launcher alone. Most of the startup options remain the same. Different are some of the options that the launcher can accept. The new ones provide means to configure a lot of the framework's internals right from the start.

A full list of the options that the Equinox Launcher recognizes is available at help.eclipse.org

Spring DM to Gemini Blueprint Upgrade

This section only applies once bug 317943 is implemented.

This release replaces Spring DM 1.2.1 with Gemini Blueprint 1.0.0.RELEASE. The behaviour is mostly backward compatible, but users should read the Gemini Blueprint migration notes.

One significant difference is that Gemini Blueprint does not attach a bean name service property to services constructed from anonymous inner beans ("inside" the <service> element).

The service scoping logic in the Virgo kernel was also tightened up as a consequence of this change of behaviour. A services published inside a PAR or scoped plan is now only available outside the scope if the service is a blueprint (application) context or if the service property org.eclipse.virgo.service.scope is set to global. In earlier releases, all services published in a scope without a bean name service property were also available outside the scope.

Thread Context Class Loading with PARs and Scoped Plans

As described in the Programmer Guide, Virgo creates a synthetic context bundle when a PAR or scoped plan is deployed. The purpose of this bundle is to provide a thread context class loader (TCCL) which can load all types belonging to packages exported by the bundles in the PAR or scoped plan. Unfortunately, in earlier releases, this synthetic context TCCL could be overridden by Spring DM so that a call to a bundle outside the PAR or scoped plan would see the TCCL of the calling bundle rather than of the synthetic context bundle. This problem is fixed in this release by bug 360965.

However, the fix can impact certain applications which were relying on the bug. For example, the Greenpages sample stopped working because a concrete datasource class could no longer be loaded via the TCCL. The solution was to move the bundle providing the concrete datasource class inside the Greenpages PAR. This seems like a general solution for applications with similar issues. See bug 368781 for details of the Greenpages problem and the fix.

Transformer Signature

Transformer services in Virgo 3.5.0 operate in terms of a directed acyclic graph of install artefacts instead of the tree which was used by Virgo 3.0.x.

If you provide a Transformer service, you'll need to rework it to implement the modified signature. For example, the WebTransformer.transform method was changed as follows:

public void transform(GraphNode<InstallArtifact> installGraph, InstallEnvironment installEnvironment) throws DeploymentException {
 installGraph.visit(new ExceptionThrowingDirectedAcyclicGraphVisitor<InstallArtifact, DeploymentException>() {

     public boolean visit(GraphNode<InstallArtifact> node) throws DeploymentException {
             InstallArtifact installArtifact = node.getValue();
             ...
     }
 });
}

Custom Logback Appenders

Bug 362095 moved Logback out of the Virgo medic core bundle. This impacts the way that custom appenders are specified.

Fragments containing custom Logback appenders now need to specify:

Fragment-Host: com.springsource.ch.qos.logback.classic

or (if you use the LogBack bundle from Orbit):

Fragment-Host: ch.qos.logback.classic

instead of:

Fragment-Host: org.eclipse.virgo.medic.core

Also note that the medic core bundle now sets logback.ignoreTCL to "true" in order to avoid an obscure classloading error in some tests. See bug 362095 for details.