Virgo/Community/Migrating from 2.x to 3.0.0

DRAFT

XML Schemas

The plan schema has moved to Eclipse.org:

<plan ...
      xmlns="http://www.eclipse.org/virgo/schema/plan"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="
          http://www.eclipse.org/virgo/schema/plan
          http://www.eclipse.org/virgo/schema/plan/eclipse-virgo-plan.xsd">

However, the old schema is still supported, but may be discontinued in the future:

<plan ...
      xmlns="http://www.springsource.org/schema/dm-server/plan"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="
          http://www.springsource.org/schema/dm-server/plan 
          http://www.springsource.org/schema/dm-server/plan/springsource-dm-server-plan.xsd">

Declarative Services

Virgo now supports Declarative Services out-of-the-box, in both kernel and the user region. See bug 333474.

OSGi Log Service

Virgo now supports the OSGi Log Service out-of-the-box, in both kernel and user region. See bug 342716.

Configuration Admin and Event Admin

Virgo switched from the Felix to the Equinox implementations of these services.

User Region

The following notes relate to the effects of bug 330776.

Rather than the user region being a nested OSGi framework, it is now a collection of bundles in the same OSGi framework as the kernel with isolation controlled by config/org.eclipse.virgo.kernel.userregion.properties. There is a single system bundle which resides in the kernel region. There is now no surrogate bundle (which used to have bundle id 1) to act as a kind of proxy for the kernel in the user region; instead user region bundles wire directly to kernel bundles for packages and services.

Framework properties are now specified only in lib/org.eclipse.virgo.kernel.launch.properties (although this may change in a future release) and must include org.osgi.framework.bsnversion=multiple for correct functioning of the user region.

Console Configuration

The old Equinox console is no longer supported, although you can enable it by using the osgi.console framework property.

See the User Guide for how to enable telnet and ssh consoles for both the kernel and user region.

Web

Web Application Bundle Manifest Headers

• Virgo previously added additional Manifest headers to Web Application Bundles to make them easier to develop. This support is being dropped in order to adhere strictly to the OSGi Web Applications specification. The major effect this will have is that you must now specify the following headers:
  • Bundle-ManifestVersion which must be set to 2
  • Bundle-SymbolicName
  • Bundle-Classpath header for classes in 'WEB-INF/classes' and any JARs in 'WEB-INF/lib', if needed.
  • Import-Package for any packages the web bundle needs.
  • Web-ContextPath

As a migration aid, the previous behaviour can be re-instated although this facility may be withdrawn in a future release. See "Configuring the Web Integration Layer" in the User Guide for details.

Module-Type Header Dropped

• The Module-Type header is no longer used to identify a bundle as a WAB, the presence of a Web-Contextpath header now does this, as per the specification.

Package Upgrades

• The version of the javax.portlet.* packages has changed from 2.0.0 to 2.0.0.v20110525
• The version of the javax.xml.rpc.* packages has changed from 1.1.0 to 1.1.0.v20110517
• The version of the org.apache.taglibs.* packages has changed from 1.1.2 to 1.1.2.v20110517
• The version of the org.apache.commons.fileupload.* packages has changed from 1.2.0 to 1.2.0.v20110525
• The version of the javax.servlet.* packages has changed from 2.5.0 to 3.0.0.v201103241009
• The version of the javax.servlet.jsp.* packages has changed from 2.1.0 to 2.2.0.v201103241009
• The version of the javax.annotation.* packages has changed from 1.0.0 to 1.1.0.v201105051105
• The version of the javax.el.* packages has changed from 1.0.0 to 2.2.0.v201105051105

• Tomcat version is changed from 6.0.* to 7.0.*

• JDT version is changed from 3.3.1.v_780_R33x to 3.6.1

Changed Bundle Symbolic Names

• The javax.servlet.* packages are now provided by a bundle with bundle symbolic name javax.servlet rather than com.springsource.javax.servlet.
• The javax.servlet.jsp.* packages are now provided by a bundle with bundle symbolic name javax.servlet.jsp rather than com.springsource.javax.servlet.jsp.
• The javax.annotation.* packages are now provided by a bundle with bundle symbolic name javax.annotation rather than com.springsource.javax.annotation
• The javax.el.* packages are now provided by a bundle with bundle symbolic name javax.el rather than com.springsource.javax.el

• Tomcat bundles symbolic names are changed from:
  • com.springsource.org.apache.catalina.springsource to com.springsource.org.apache.catalina
  • com.springsource.org.apache.catalina.ha.springsource to com.springsource.org.apache.catalina.ha
  • com.springsource.org.apache.catalina.tribes.springsource to com.springsource.org.apache.catalina.tribes
  • com.springsource.org.apache.coyote.springsource to com.springsource.org.apache.coyote
  • com.springsource.org.apache.el.springsource to com.springsource.org.apache.el
  • com.springsource.org.apache.jasper.springsource to com.springsource.org.apache.jasper
  • com.springsource.org.apache.juli.extras.springsource to com.springsource.org.apache.juli.extras

• Two additional bundles are provided:
  • com.springsource.org.apache.tomcat.api
  • com.springsource.org.apache.tomcat.util

• JDT bundle symbolic name is changed from org.eclipse.jdt.core to com.springsource.org.eclipse.jdt.core.compiler.batch

Reserved keywords in JSPs

EL 2.2 is now stricter about the use of Java reserved words as variable names in JSPs. e.g. import. See bug 346066.

Spring Framework

Spring Framework has been upgraded to 3.0.5. The version in the user region may be changed as describe in the FAQ.

Require-Bundle

The upgrade of Equinox to 3.7 made the processing of Require-Bundle stricter (see bug 343050). Matching attributes are now honoured. Previously matching attributes other than bundle-version were ignored.

So, for instance, the following header:

Require-Bundle: org.foo;version="[1,1.1)"

would often "work" because the version matching attribute was ignored. With Equinox 3.7 this will now cause a resolution failure. The fix is to use the correct attribute:

Require-Bundle: org.foo;bundle-version="[1,1.1)"

Lazy Activation Bundles

Lazy activation was part of Eclipse before it was standardised in OSGi. Prior to this standard, Eclipse would automatically place a lazy start bundle into the "waiting for trigger class load mode" even if Bundle.start(useActivationPolicy) was not called. In order to continue supporting this mode Equinox has a compatibility configuration flag (osgi.compatibility.eagerStart.LazyActivation) which defaults to true. This means the framework will automatically call Bundle.start(START_ACTIVATION_POLICY) for all resolved bundles that have a lazy activation policy. This automatically places them into the STARTING state and waiting for a trigger class load.

This behaviour conflicted with the way bundles are deployed by Virgo. Virgo calls Bundle.start() which is equivalent to Bundle.start(0) which will ignore the activation policy and cause the bundle to be eagerly (and persistently) started.

To remove this conflict, Virgo now configures Equinox to conform to the OSGi specification to lazy activation by setting:

osgi.compatibility.eagerStart.LazyActivation=false

in lib/org.eclipse.virgo.kernel.launch.properties.