Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Equinox » How to diagnose why a system bundle fragment is not getting attached?
How to diagnose why a system bundle fragment is not getting attached? [message #900471] Tue, 07 August 2012 08:42 Go to next message
Sahoo Missing name is currently offline Sahoo Missing nameFriend
Messages: 26
Registered: July 2009
Junior Member
Hi,

We have a few framework extension bundles in GlassFish and for some reason they are not getting attached any more. I am using Equinox 3.6.1. It was working fine until we upgraded some regular bundles. They all work fine on Felix platform. I suspect I am facing the issue mentioned in [1]. There is no mention of a bug in [1]. Does anyone know what's the bug corresponding to the issue raised in [1]?

I don't see how to go about diagnose this issue. I have enabled org.eclipse.osgi/debug=true and org.eclipse.osgi/resolver/debug = true, but the output is so huge that I don't know what to look for. I would appreciate if someone can tell me how to go about analysing the issue.

Thanks,
Sahoo

[1] http://www.eclipse.org/forums/index.php/mv/msg/40006/131080/#msg_131080
Re: How to diagnose why a system bundle fragment is not getting attached? [message #900641 is a reply to message #900471] Tue, 07 August 2012 22:05 Go to previous messageGo to next message
Sahoo Missing name is currently offline Sahoo Missing nameFriend
Messages: 26
Registered: July 2009
Junior Member
Any clue?
Re: How to diagnose why a system bundle fragment is not getting attached? [message #900724 is a reply to message #900641] Wed, 08 August 2012 10:02 Go to previous messageGo to next message
Sahoo Missing name is currently offline Sahoo Missing nameFriend
Messages: 26
Registered: July 2009
Junior Member
Upgrading to Equinox 3.8 didn't make much difference.
Re: How to diagnose why a system bundle fragment is not getting attached? [message #900755 is a reply to message #900724] Wed, 08 August 2012 12:11 Go to previous messageGo to next message
Thomas Watson is currently offline Thomas WatsonFriend
Messages: 437
Registered: July 2009
Senior Member
The first thing I would do is run with the osgi> console and run the 'diag <fragment bundle id>' command. That should help give some idea of why the fragment could not resolve. Does your fragment specify a Bundle-RequiredExecutionEnvironment header? Can you post the headers of the fragment here?
Re: How to diagnose why a system bundle fragment is not getting attached? [message #900839 is a reply to message #900755] Wed, 08 August 2012 16:54 Go to previous messageGo to next message
Sahoo Missing name is currently offline Sahoo Missing nameFriend
Messages: 26
Registered: July 2009
Junior Member
None of my framework extension bundles get attached. Bundle #33 is one of them. None of them use RequiredExecutionEnvironment. Here is what surprises me. I see a regular bundle (#160) has not been resolved as well and I do feel that's affecting resolution of these framework extension bundles. You will find details about both the bundles in the attached output.txt file. It also contains details about specific Equinox flags that I use.

Can you explain why bundle #160 is not getting wired to bundle #3 for javax.xml.bind? I start bundle #3 upfront since it is one of our endorsed bundles, that way I expect its packages to be preferred over system bundle packages for all endorsed packages. In fact, if I now try to start 160, it gets wired. So, I don't understand why it initially gets the "uses constraint" error.

Secondly, do you know about the issue reported in the earlier thread that I referenced in my initial posting?

Thanks,
Sahoo
  • Attachment: output.txt
    (Size: 12.36KB, Downloaded 150 times)
  • Attachment: config.ini
    (Size: 10.66KB, Downloaded 78 times)
Re: How to diagnose why a system bundle fragment is not getting attached? [message #900969 is a reply to message #900839] Thu, 09 August 2012 09:07 Go to previous messageGo to next message
Sahoo Missing name is currently offline Sahoo Missing nameFriend
Messages: 26
Registered: July 2009
Junior Member
The steps to reproduce won't take more than 5 minutes as stated below:

1. Download latest GlassFish 4.0-SNAPSHOT from [1]. This URL may change with time. So, adjust the URL if need be by visiting [2] and selecting the latest zip there.

2. Let's say you unzip it in /tmp. Then a directory like /tmp/glassfish3/glassfish/... gets created.

3. Start your Equinox using the previously uploaded config.ini

4. Install GlassFish like this:
install file:/tmp/glassfish3/glassfish/modules/glassfish.jar

5. start <above bundle id>

6. See list of all INSTALLED bundles.

Thanks,
Sahoo

[1] https://maven.java.net/content/repositories/snapshots/org/glassfish/main/distributions/glassfish/4.0-SNAPSHOT/glassfish-4.0-20120809.051119-488.zip
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 Go to previous message
Thomas Watson is currently offline Thomas WatsonFriend
Messages: 437
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
Previous Topic:P2 : programatic update of bundles : error with singleton
Next Topic:unable to use secure storage with headless antRunner app
Goto Forum:
  


Current Time: Sat Dec 20 21:02:15 GMT 2014

Powered by FUDForum. Page generated in 0.02186 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software