There is a long history to the boot delegation story.  In OSGI R3 chapter 
4.7 the specification makes it very clear that a bundle classloader *must* 
delegate to the system classloader first.  As you may or may not know 
Eclipse used to have its own runtime platform that also had a similar 
model where the system classloader was always delegated to first.  Then in 
Eclipse 3.0 a decision was made to move to OSGi.  At the time R4 was a 
long ways off.

Eclipse pushed forward in the Equinox project and started adding 
requirements for R4 and implemented an OSGi Framework based on OSGi R3 + 
extensions needed by Eclipse for the Eclipse 3.0 release.  At the time 
Eclipse 3.0 was released OSGi R4 was still a long ways out *and* CPEG had 
not decided to change the rules of boot delegation yet.  Some time late in 
the OSGi R4 development cycle it was decided that the OSGi framework 
needed to isolate bundles from the system classloader.  It was decided 
that every package *must* be imported (using Import-Package, or 
Require-Bundle) in order to load a class out side of a bundles private 
class space except for the java.* packages which *must* only come from the 
boot classloader.

This was a rather radical change IMHO, but I do think it is a good idea 
because it does allow for additional packages to be managed by the 
framework.  Using the old model the packages provided by the VM would 
*always* be loaded first over any package in a bundle, thus preventing a 
bundle from really exporting their own version of the package.

Unfortunately this change to boot delegation has serious backwards 
compatibility issues for stack products running on top of Eclipse. 
Remember the Equinox team has no control over what products do and the 
Equinox team cannot easily force them to change.  In many cases the 
Eclipse teams are completely unaware of who is using the platform.  The 
Equinox team tried very hard to be a "strict" OSGi R4 framework out of the 
box in the Eclipse 3.1 release, but ran into many issues where bundles did 
not work because they assumed the Framework would always delegate to boot 
first (after all that is what the R3 spec says right?).

For the Eclipse 3.3 release we are once again trying to disable 
bootdelegation=* (see 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=162231).  This attempt is 
adding a last resort boot delegation, but this change still is causing us 
a significant amount of issues (most of which we are working through).  If 
we change Equinox to be "strict" WRT boot delegation then a true riot will 
occur among the community expecting each version of Eclipse to be 
backwards compatible with the last (the Equinox team experienced this in 
Eclipse 3.1 when it was tried).

Tom




Niclas Hedhman <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED]
03/20/2007 06:30 AM
Please respond to
OSGi Developer Mail List <[email protected]>


To
OSGi Developer Mail List <[email protected]>
cc

Subject
Re: [osgi-dev] Interoperability problems...







On Tuesday 20 March 2007 16:31, Peter Kriens wrote:
> So a bundle that uses javax.swing and does not import is a faulty
> bundle. However, it should run when the
> org.osgi.framework.bootdelegation is set to *.

Is it only me that think that it is extremely bad that the reference
implementation(!) accepts faulty bundles??
Shouldn't it at least be that the bootdelegation is default 'none'?

We can't assume that everyone will rely on tooling to get things right. I
 have now several times been involved in locating this kind of problems in
 customer bundles, and the problem will only increase with more OSGi
 adopters. I will continue to claim to customers that this is an Equinox 
bug.

Furthermore; Export-Package of the system bundle also seems inconclusive
between implementations. I think the specification should be very 
specific.
Using text "the Framework must explicitly export relevant packages from 
the
parent class loader" is IMHO far too vague. And also, the specification 
does
not mention what the default value for org.osgi.framework.system.packages
really is,and since the specification says
"All other packages available through the parent class loader must be 
hidden
from executing bundles."
which to me isn't very ambiguous, i.e. no automatic exposure of JDK 
packages,
and Equinox indeed export JDK packages by default, the only 'loop hole' 
that
Equinox is "exploiting" is that the org.osgi.framework.system.packages
property's default value is not defined in the spec.



Btw,
According to
http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc.isv/

reference/misc/runtime-options.html

One should use the osgi.java.profile.bootdelegation property.

Both

  java -Dosgi.java.profile.bootdelegation=none \
       -jar $EQ/plugins/org.eclipse.osgi_3.3.0.v20070208.jar \
       -clean \
       -console

and

  java -Dosgi.java.profile.bootdelegation=ignore \
       -Dorg.osgi.framework.bootdelegation=""  \
       -jar $EQ/plugins/org.eclipse.osgi_3.3.0.v20070208.jar \
       -clean \
       -console

still let my bundle use the javax.swing package...


Cheers
--
Niclas Hedhman, Software Developer

I  live here; http://tinyurl.com/2qq9er
I  work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev

_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev

Reply via email to