On 8/3/12 09:18 , Pierre De Rop wrote:
Hi everyone;

I'm using Felix framework 4.0.2 and jdk 1.6.0-OpenSCG-Build-24, and I have
a problem with a legacy bundle from our product, which tries to load the
following JDK 1.6 packages using DynamicImport-Package: *:

org.w3c.dom.traversal
org.w3c.dom.ranges

(I know it is a bad practice to use such dynamic import but I can't modify
this old bundle ...)

So, everything was working fine until fwk 3.2.2, but since fwk 4.0.0, I
then have the following CNF:

java.lang.ClassNotFoundException: *** Package 'org.w3c.dom.traversal' is
not imported by bundle com.alcatel.as.legacybundle [67], nor is there any
bundle that exports package 'org.w3c.dom.traversal'. However, the class
'org.w3c.dom.traversal.DocumentTraversal' is available from the system
class loader. There are two fixes: 1) Add package 'org.w3c.dom.traversal'
to the 'org.osgi.framework.system.packages.extra' property and modify
bundle com.alcatel.as.legacybundle [67] to import this package; this causes
the system bundle to export class path packages. 2) Add package
'org.w3c.dom.traversal' to the 'org.osgi.framework.bootdelegation'
property; a library or VM bug can cause classes to be loaded by the wrong
class loader. The first approach is preferable for preserving modularity.
***

So, after investigation, it seems that these two packages are not
reexported anymore by system bundle since fwk 4.0.0 version; and I wonder
if this is intentional, or may be it's a regression ?

-> see default.properties from fwk 3.2.2: this file contains the list of
reexported jdk packages, including my two packages:

jre-1.6=, \
  ...
  org.w3c.dom.ranges; \
  org.w3c.dom.stylesheets; \
  org.w3c.dom.traversal; \
  ...

But since fwk 4.0.0, the two packages are not present anymore; however the
org.w3c.dom.traversal package is yet referenced in some "uses" clauses:

  
org.w3c.dom.ls;uses:="org.w3c.dom,org.w3c.dom.events,org.w3c.dom.traversal";version="0.0.0.1_006_JavaSE",
\

So; should I create a jira issue, or are these two packages considered as
internal jdk packages (not to be reexported) ?

It is intentional, they shouldn't be there since they are not part of the official JRE API. You could open an issue to remove them from the "uses" clauses, but those shouldn't cause any issue since they'll just be ignored.

If you need access to those packages, just modify the org.osgi.framework.system.packages.extra configuration property to include them in conf/config.properties.

-> richard


thanks, and kind regards;
/pierre


Reply via email to