Home » Eclipse Projects » Equinox » How to diagnose why a system bundle fragment is not getting attached?
| | | | | |
Re: How to diagnose why a system bundle fragment is not getting attached? [message #901649 is a reply to message #900969] |
Mon, 13 August 2012 20:26 |
Thomas Watson Messages: 503 Registered: July 2009 |
Senior Member |
|
|
I took a look at your configuration and here is what I found:
In your case you have lots of bundles that are exporting "versioned" packages which are also exported by the system bundle (JRE) as "unversioned" packages. You also have some bundles that import such packages with no version ranges and some that do use version ranges. The bundles with no version ranges are free to wire to the system bundle "unversioned" exports. Unfortunately this leads to some uses constraint violations and a very large solution set. In my environment I am seeing this explode both the old equinox resolver and my new implementation which uses the felix resolver.
Did some of your bundles change to no longer use package version ranges? Or did you add new bundles that don't use package version ranges? In your Glassfish boot strap do you try to install and resolve a certain set of bundles that provide "versioned" packages that are also provided by the VM? I suspect it is working on felix because felix resolves bundles one at a time where equinox tries to resolve all unresolved bundles in one big bang. The one at a time approach allows your bundles that export "versioned" packages to resolve earlier and then their exports are preferred over the "unversioned" packages from the system bundle.
I did two things to confirm my theory. First of all I hacked the resolver to special case unversioned packages from the system bundle to not be preferred if there is a "versioned" package available from another bundle (even if that bundle is not currently resolved). This allowed you setup to resolve very fast because we simply selected the "correct" package first and that helped with the uses constraint violations.
Second, I modified your configuration to use the org.osgi.framework.system.packages property instead of the org.osgi.framework.system.packages.extra. The extra one appends all the packages on top of the packages the framework already has determined based on the execution environment. this lead to many duplicate exports by the system bundle. Next I removed the following packages from the system.packages list because you appear to be installing bundles that also export these packages and I assume you want these exports to be used over any provided by the VM:
javax.rmi.CORBA, \
org.omg.CORBA, \
org.omg.CORBA.DynAnyPackage, \
org.omg.CORBA.ORBPackage, \
org.omg.CORBA.TypeCodePackage, \
org.omg.CORBA.portable, \
org.omg.CORBA_2_3, \
org.omg.CORBA_2_3.portable, \
org.omg.CosNaming, \
org.omg.CosNaming.NamingContextExtPackage, \
org.omg.CosNaming.NamingContextPackage, \
org.omg.Dynamic, \
org.omg.DynamicAny, \
org.omg.DynamicAny.DynAnyFactoryPackage, \
org.omg.DynamicAny.DynAnyPackage, \
org.omg.IOP, \
org.omg.IOP.CodecPackage, \
org.omg.PortableInterceptor, \
org.omg.PortableInterceptor.ORBInitInfoPackage, \
org.omg.PortableServer, \
org.omg.PortableServer.CurrentPackage, \
org.omg.PortableServer.POAManagerPackage, \
org.omg.PortableServer.POAPackage, \
org.xml.sax.helpers
javax.annotation, \
javax.xml.bind, \
javax.xml.bind.annotation, \
javax.xml.bind.annotation.adapters, \
javax.xml.bind.attachment, \
javax.xml.bind.helpers, \
javax.xml.bind.util, \
javax.jws, \
javax.jws.soap, \
javax.xml.ws, \
javax.xml.ws.handler, \
javax.xml.ws.handler.soap, \
javax.xml.ws.http, \
javax.xml.ws.soap, \
javax.xml.ws.spi, \
javax.xml.ws.wsaddressing
This also allowed the setup to resolve very fast. Since you appear to have tight control over what the system bundle is allowed to export from the execution environment then I suggest you do not configure the system bundle to export packages which you want to override with packages exported by real bundles.
HTH
Tom
|
|
|
Goto Forum:
Current Time: Sun Apr 28 12:17:58 GMT 2024
Powered by FUDForum. Page generated in 0.03920 seconds
|