Skip to main content

Notice: This Wiki is now read only and edits are no longer 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 2.x to 3.0.0"

(→‎Web)
(→‎XML Schemas)
 
(16 intermediate revisions by the same user not shown)
Line 3: Line 3:
 
= XML Schemas  =
 
= XML Schemas  =
  
−
The plan schema has moved to Eclipse.org, ...
+
The plan schema has moved to Eclipse.org:
  
−
= Virgo Startup =
+
  <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'''">
  
−
This is related to the result of bug 333474. Virgo now has dynamic startup - its base bundles do not require ordering anymore. This enables possible usage of other OSGi launchers.
+
However, the old schema is still supported, but may be discontinued in the future:
  
−
= Declarative Service support =
+
  <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'''">
  
−
This is related to the result of bug 333474. Virgo now supports Declarative services out-of-the-box, both in kernel and the user region.
+
= Declarative Services =
  
−
= Virgo Directory Layout  =
+
Virgo now supports Declarative Services out-of-the-box, in both kernel and the user region. See [https://bugs.eclipse.org/bugs/show_bug.cgi?id=333474 bug 333474].
  
−
Bug 324991 affects this.
+
= OSGi Log Service =
  
−
= Reserved keywords in JSPs =
+
Virgo now supports the OSGi Log Service out-of-the-box, in both kernel and user region. See [https://bugs.eclipse.org/bugs/show_bug.cgi?id=342716 bug 342716].
  
−
As bug 346066, EL 2.2 is now stricter about the use of Java reserved words as variable names in JSPs. e.g. import.
+
= Configuration Admin and Event Admin =
 +
 
 +
Virgo switched from the Felix to the Equinox implementations of these services.
  
 
= User Region  =
 
= User Region  =
Line 27: Line 39:
 
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.  
 
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 (this is subject to change) and must include org.osgi.framework.bsnversion=multiple for correct functioning of the user region.  
+
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.
  
−
There is now one OSGi console which can be enabled using the osgi.console framework property. This console can see all the bundles in the framework, although the vsh subcommand is limited to the user region bundles.  
+
= 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  =
 +
 +
== 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:
 
*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:
Line 42: Line 60:
 
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.
 
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.
 
*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.portlet.*'' packages has changed from ''2.0.0'' to ''2.0.0.v20110525''
Line 55: Line 75:
 
*The version of the ''javax.el.*'' packages has changed from ''1.0.0'' to ''2.2.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.*'' packages are now provided by a bundle with bundle symbolic name ''javax.servlet'' rather than ''com.springsource.javax.servlet''.
Line 61: Line 86:
 
*The ''javax.el.*'' packages are now provided by a bundle with bundle symbolic name ''javax.el'' rather than ''com.springsource.javax.el''
 
*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''
  
−
*Tomcat version is changed from ''6.0.*'' to ''7.0.*''
 
−
*Tomcat bundles symbolic names are changed from:
 
−
**''com.springsource.org.apache.catalina'' to ''com.springsource.org.apache.catalina.springsource''
 
−
**''com.springsource.org.apache.catalina.ha'' to ''com.springsource.org.apache.catalina.ha.springsource''
 
−
**''com.springsource.org.apache.catalina.tribes'' to ''com.springsource.org.apache.catalina.tribes.springsource''
 
−
**''com.springsource.org.apache.coyote'' to ''com.springsource.org.apache.coyote.springsource''
 
−
**''com.springsource.org.apache.el'' to ''com.springsource.org.apache.el.springsource''
 
−
**''com.springsource.org.apache.jasper'' to ''com.springsource.org.apache.jasper.springsource''
 
−
**''com.springsource.org.apache.juli.extras'' to ''com.springsource.org.apache.juli.extras.springsource''
 
 
*Two additional bundles are provided:
 
*Two additional bundles are provided:
 
**''com.springsource.org.apache.tomcat.api''
 
**''com.springsource.org.apache.tomcat.api''
 
**''com.springsource.org.apache.tomcat.util''
 
**''com.springsource.org.apache.tomcat.util''
  
−
 
−
*JDT version is changed from ''3.3.1.v_780_R33x'' to ''3.6.1''
 
 
*JDT bundle symbolic name is changed from ''org.eclipse.jdt.core'' to ''com.springsource.org.eclipse.jdt.core.compiler.batch''
 
*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 [https://bugs.eclipse.org/bugs/show_bug.cgi?id=346066 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 [http://wiki.eclipse.org/Virgo/FAQ#How_can_I_change_the_version_of_Spring_framework_in_the_user_region.3F FAQ].
 
= Require-Bundle  =
 
= Require-Bundle  =
  
Line 88: Line 117:
 
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:  
 
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:  
 
<pre>Require-Bundle: org.foo;bundle-version="[1,1.1)"</pre>
 
<pre>Require-Bundle: org.foo;bundle-version="[1,1.1)"</pre>
 +
 +
= 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.

Latest revision as of 12:13, 28 November 2011

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.

Retrieved from "https://wiki.eclipse.org/index.php?title=Virgo/Community/Migrating_from_2.x_to_3.0.0&oldid=280123"

This page was last modified 12:13, 28 November 2011 by Eclipsepedia anonymous user Unnamed Poltroon.

Back to the top