Difference between revisions of "Scout/HowTo/3.8/Using JRE 1.6 with its packaged javax and w3c.org classes"

Latest revision as of 10:20, 7 May 2012

The Scout documentation has been moved to https://eclipsescout.github.io/. Many times people ask why they have to add bundles such as javax.xml or org.w3c.dom, ... to their products even though they are using a JRE 1.6. An example: Plug-In org.apache.batik.dom contains an import dependency to org.w3c.dom and org.w3c.dom.events. Both bundles can be found on the Eclipse Orbit Download page.

When running a product / application with these bundles (batik 1.7) in jre 1.5 you simply add the bundle javax.xml and org.w3c.dom.events and you are done.

But when running the same thing with a jre 1.6 you will most probably run into a runtime error "Loader Constraint Violation" for the class org.w3c.dom.events.Event. This is due to the fact that the osgi class loading tree found the class in the jre 1.6 (which since then includes all that stuff) bootclass path and later-on in the bundle org.w3c.dom.events. These two classes might be identical but have different class loader sources, which is a conflict.

The solution with jre 1.6 is NOT to add bundles with classes of the extended JRE but adding a fragment to system.bundle. In our example: Do not add the bundle javax.xml and org.w3c.dom.events. Add a fragment say "jre16.fragment" with the following structure:

jre16.fragment
  META-INF
    MANIFEST.MF

The MANIFEST.MF is as follows.

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Packages included in JRE1.6+ (W3C, XML, Activator)
Bundle-SymbolicName: jre16.fragment
Bundle-Version: 1.0.0.qualifier
Fragment-Host: system.bundle
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Export-Package: javax.activation,
 javax.transaction,
 javax.transaction.xa,
 javax.xml;version="1.3.0",
 javax.xml.bind;version="1.3.0",
 javax.xml.bind.annotation;version="1.3.0",
 javax.xml.bind.annotation.adapters;version="1.3.0",
 javax.xml.bind.attachment;version="1.3.0",
 javax.xml.bind.helpers;version="1.3.0",
 javax.xml.bind.util;version="1.3.0",
 javax.xml.crypto;version="1.3.0",
 javax.xml.crypto.dom;version="1.3.0",
 javax.xml.crypto.dsig;version="1.3.0",
 javax.xml.crypto.dsig.dom;version="1.3.0",
 javax.xml.crypto.dsig.keyinfo;version="1.3.0",
 javax.xml.crypto.dsig.spec;version="1.3.0",
 javax.xml.datatype;version="1.3.0",
 javax.xml.namespace;version="1.3.0",
 javax.xml.parsers;version="1.3.0",
 javax.xml.soap;version="1.3.0",
 javax.xml.stream;version="1.3.0",
 javax.xml.stream.events;version="1.3.0",
 javax.xml.stream.util;version="1.3.0",
 javax.xml.transform;version="1.3.0",
 javax.xml.transform.dom;version="1.3.0",
 javax.xml.transform.sax;version="1.3.0",
 javax.xml.transform.stax;version="1.3.0",
 javax.xml.transform.stream;version="1.3.0",
 javax.xml.validation;version="1.3.0",
 javax.xml.ws;version="1.3.0",
 javax.xml.ws.handler;version="1.3.0",
 javax.xml.ws.handler.soap;version="1.3.0",
 javax.xml.ws.http;version="1.3.0",
 javax.xml.ws.soap;version="1.3.0",
 javax.xml.ws.spi;version="1.3.0",
 javax.xml.ws.wsaddressing;version="1.3.0",
 javax.xml.xpath;version="1.3.0",
 org.w3c.dom;version="3.0.0",
 org.w3c.dom.bootstrap;version="3.0.0",
 org.w3c.dom.css;version="3.0.0",
 org.w3c.dom.events;version="3.0.0",
 org.w3c.dom.html;version="3.0.0",
 org.w3c.dom.ls;version="3.0.0",
 org.w3c.dom.ranges;version="3.0.0",
 org.w3c.dom.stylesheets;version="3.0.0",
 org.w3c.dom.traversal;version="3.0.0",
 org.w3c.dom.views;version="3.0.0",
 org.w3c.dom.xpath;version="3.0.0",
 org.xml.sax;version="1.3.4",
 org.xml.sax.ext;version="1.3.4",
 org.xml.sax.helpers;version="1.3.4"

That way the osgi is satisfied since the import dependencies of the batik plugin is met. And on runtime the classes are found directly in the JRE 1.6

@@ Line 1: / Line 1: @@
 {{ScoutPage|cat=HowTo 3.8}}
+Many times people ask why they have to add bundles such as javax.xml or org.w3c.dom, ... to their products even though they are using a JRE 1.6.
-Many times people ask me why they have to add bundles such as javax.xml or org.w3c.dom, ... to their products even though they are using a JRE 1.6.
 An example: Plug-In org.apache.batik.dom contains an import dependency to org.w3c.dom and org.w3c.dom.events.
-Both bundles can be found on the eclipse Orbit download page.
+Both bundles can be found on the [http://download.eclipse.org/tools/orbit/downloads/ Eclipse Orbit Download page].
-When running a product / application with these bundles (batik 1.7) in jre 1.5 you simply add the bundle javax.xml and org.w3c.dom.events and are done.
+When running a product / application with these bundles (batik 1.7) in jre 1.5 you simply add the bundle javax.xml and org.w3c.dom.events and you are done.
 But when running the same thing with a jre 1.6 you will most probably run into a runtime error "Loader Constraint Violation" for the class org.w3c.dom.events.Event.
@@ Line 11: / Line 10: @@
 These two classes might be identical but have different class loader sources, which is a conflict.
-The solution with jre 1.6 is NOT to add bundles with classes of the extended jre but adding a fragment to system.bundle.
+The solution with jre 1.6 is NOT to add bundles with classes of the extended JRE but adding a fragment to system.bundle.
 In our example: Do not add the bundle javax.xml and org.w3c.dom.events.
 Add a fragment say "jre16.fragment" with the following structure:
@@ Line 82: / Line 81: @@
 </source>
-That way the osgi is satisfied since the import dependencies of the batik plugin is met. And on runtime the classes are found directly in the jre 1.6
+That way the osgi is satisfied since the import dependencies of the batik plugin is met. And on runtime the classes are found directly in the JRE 1.6

Breadcrumbs

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.

Difference between revisions of "Scout/HowTo/3.8/Using JRE 1.6 with its packaged javax and w3c.org classes"

Latest revision as of 10:20, 7 May 2012