Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Virgo/Community/Migrating from 3.0.x to 3.5.0"

(Thread Context Class Loading with PARs and Scoped Plans)
Line 21: Line 21:
 
= Thread Context Class Loading with PARs and Scoped Plans=
 
= 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 bundle outside the PAR or scoped plan would see a TCCL of the calling bundle rather than of the synthetic context bundle. This problem is fixed in this release in [https://bugs.eclipse.org/bugs/show_bug.cgi?id=360965 bug 360965].
+
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 by [https://bugs.eclipse.org/bugs/show_bug.cgi?id=360965 bug 360965] in this release.
  
This change can impact certain applications. 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 that hit the same issue. See bug 368781 for [https://bugs.eclipse.org/bugs/show_bug.cgi?id=368781#c18 details] of the Greenpages fix.
+
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 that hit the same issue. See bug 368781 for [https://bugs.eclipse.org/bugs/show_bug.cgi?id=368781#c18 details] of the Greenpages fix.
  
 
= Transformer Signature  =
 
= Transformer Signature  =

Revision as of 12:20, 1 March 2012

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

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 by bug 360965 in this release.

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 that hit the same issue. See bug 368781 for details of the Greenpages 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

This will apply once bug 362095 is implemented.

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.

Copyright © Eclipse Foundation, Inc. All Rights Reserved.