framework bootdelegation insufficient

[JochenHiller]

Migrated from Eclipse Bugzilla #480172

Scott Lewis 2015-10-19 23:15:44 EDT

I have a bundle that uses javax.xml.parsers and org.xml.sax packages for xml parsing. It refuses to resolve on Concierge RC1 with the following exception:

Concierge> Exception in thread "main" org.osgi.framework.BundleException: Resolution failed [BundleRequirement{Import-Package javax.xml.parsers}]
at org.eclipse.concierge.Concierge.resolve(Concierge.java:2645)
at org.eclipse.concierge.BundleImpl$Revision.resolve(BundleImpl.java:188
1)
at org.eclipse.concierge.BundleImpl.activate(BundleImpl.java:532)
at org.eclipse.concierge.BundleImpl.start(BundleImpl.java:506)
at org.eclipse.concierge.BundleImpl.start(BundleImpl.java:444)
at org.eclipse.concierge.compat.service.XargsFileLauncher.processXargsInputStream(XargsFileLauncher.java:167)
at org.eclipse.concierge.compat.service.XargsFileLauncher.processXargsFile(XargsFileLauncher.java:68)
at org.eclipse.concierge.Concierge.doMain(Concierge.java:606)
at org.eclipse.concierge.Concierge.main(Concierge.java:525)

BTW, it would be very nice if this resolution exception were to also report the bundle that was being resolved.

javax.xml.parsers is part of the underlying VM and I believe exposed by including "javax.*" for the Constants.FRAMEWORK_BOOTDELEGATION property.

For example, Equinox seems to have this as the default:

org.osgi.framework.bootdelegation =
javax.,
org.ietf.jgss,
org.omg.,
org.w3c.,
org.xml.,
sun.,
com.sun.

Concierge seems to currently have this as it's boot delegation set:

  defaultProperties.setProperty(Constants.FRAMEWORK_BOOTDELEGATION,
          "java.*, sun.*, com.sun.*");

Would it be possible to add javax., and org.xml. to the Concierge default boot delegation? Or perhaps allow org.osgi.framework.bootdelegation to be somehow be configured to include these packages?

Here's what I would believe would do it for my use case:

  defaultProperties.setProperty(Constants.FRAMEWORK_BOOTDELEGATION,
          "java.*, sun.*, com.sun.*, javax.*, org.xml.*");

It's quite possible that org.w3c.* and org.omg.* should also be added, but I don't need them for my use case.

Thanks.

Comment 1 Jan S. Rellermeyer 2015-10-19 23:59:03 EDT

What you want is not boot delegation. However, this is a common misunderstanding. Boot delegation describes which packages are "silently" delegated to the parent classloader of the one that loaded the framework. This does not affect bundle resolution but only bundle classloaders trying to access specific classes without having an explicit import for the corresponding package.

The functionality that you are looking for is org.osgi.framework.system.packages (or, since you want to extend the default and not overwrite it, org.osgi.framework.system.packages.extra). This way you can tell Concierge which other packages you would like to be exported by the system bundle so that other bundles get resolved against them.

It is correct that Equinox has a different behavior since, if I remember correctly, it probes the JVM version and, with the help of internally stored profiles, exports a larger set of packages through the system bundle. We currently don't do that due to the overhead but I think the standard only asks for "reasonable defaults" so I would say what we do is sufficient and extra packages can always be configured.

Comment 2 Scott Lewis 2015-10-20 10:45:22 EDT (In reply to Jan S. Rellermeyer from comment #1)

It is correct that Equinox has a different behavior since, if I remember
correctly, it probes the JVM version and, with the help of internally stored
profiles, exports a larger set of packages through the system bundle. We
currently don't do that due to the overhead but I think the standard only
asks for "reasonable defaults" so I would say what we do is sufficient and
extra packages can always be configured.

But you do set sun.* and com.sun.*? Isn't that overhead too? Why would internal packages be preferred to something like xml processing (pretty common, no?)

In any event, I suppose you can choose whether boot delegation or system.packages...just some way is needed to add these packages. Is org.osgi.framework.system.packages.extra supported now?

Comment 3 Jan S. Rellermeyer 2015-10-20 11:15:21 EDT

But you do set sun.* and com.sun.*? Isn't that overhead too? Why would
internal packages be preferred to something like xml processing (pretty
common, no?)

You need these packages in the bootdelegation because some classes from java.* internally rely on them. They basically break if you don't delegate.

The overhead that I was talking about is not the delegation itself but keeping the "positive lists" of packages that can be exported on certain JVMs/versions.

In any event, I suppose you can choose whether boot delegation or
system.packages...just some way is needed to add these packages.

Well, as I said, the two options serve different purposes. If you application breaks at runtime because of ClassNotFound, you need bootdelegation. If it fails during resolve time because of a package that comes from the JVM, you need the system packages.

Is
org.osgi.framework.system.packages.extra supported now?

Yes, fully supported. I think the ".extra" version was introduced in one of the later R4s but this is the much more convenient way because you don't need to override the defaults.

Comment 4 Scott Lewis 2015-10-20 12:37:03 EDT

For sake of the Concierge's adoption, I suggest that you document as loudly as possible, and provide instructions WRT use of system.packages.*. Actually, it wouldn't hurt to provide examples and alternative startup configs.

Comment 5 Scott Lewis 2015-10-24 14:52:48 EDT

FWIW, I've been able to add o.o.f.s.packages.extra=javax.xml.parser,org.xml.sax and start/satisfy all of ECF RSA on Concierge RC1. I'll now attempt to run some simple Remote Services/RSA examples on various target platforms (e.g. raspberry pi) with one or more of the existing ECF providers (e.g. r-osgi, generic, jax-rs).

I would appreciate any documentation you might have on getting concierge to run properly on some recent version (hopefully) of Android. Note that since Proxy.newProxyInstance seems to be implemented/functioning on recent Android versions, most of the distribution providers should be able to create proxies. Since rosgi uses asm I expect there may be some additions or changes needed (although perhaps not).

Also FWIW, the RSA codebase (including one distribution provider) is < 1M of code (debug-enabled). There is some shrinking/refactoring that could occur to reduce that, and I will look into doing that.