> 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'?
OSGi is free to set that property in the RI that it makes available. For
Eclipse use the setting of *, while less than optimal, is the least of two
evils.
> 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.
I certainly understand your point. Can you point us at a bug report? The
Equinox team can revisit this issue after 3.3 is released. In the
meantime, setting the system property according to your preferences should
allow you to immediately catch these issues.
> 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.
I don't the spec in front of me but as I recall there were really two
issues. Previously various frameworks varyingly left the framework's
parent classloader as the app classloader (whatever). This exposed random
unmanaged packages to all bundles to the exclusion of packages supplied in
bundles. So the "All other packages..." comment was added formalize the
problem and cover both classes available from the JRE and application
classpath.
Separate from that is the notion that there are certain cases where the
classes on the *boot* classpath must be explicitly exposed to bundle
classloaders. For example, some versions of the JRE generate reflection
optimizations such that after some number of executions (e.g., 50) the
class lib spontaneously decides that it needs to load a class from the
*boot* classpath but rather than using the boot classloader, it uses the
current classloader (e.g., the bundle classloader in the OSGi case). So
without bootdelegation=* the bundle would run and then fail.
> 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...
Feels like a bug either in the code or the doc. Please enter a bug report
in the Eclipse bugzilla under Eclipse/Equinox/Framework. A test case
would be super. Thanks
Jeff
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
