Question

I am in a situation where my Felix OSGi container will not start properly after deploying groovy via:

obr:deploy “Groovy Scripting Languge”@1.7.3

Managed to deploy & got Groovy stuff running, until I did a restart on my OSGi container…then most of the bundles will not start. FWIW, I am pretty sure Groovy is not the cause even though there’s a typo in its bundle name. 🙂

After some troubleshooting, turning on Felix’s wire logging (thank god!), i noticed this (among all the other failed bundles, similar cause):

2011-04-03 16:26:43,108 DEBUG [FelixStartLevel] felix.wire - Candidate permutation failed due to a conflict between imports; will try another if possible. (org.apache.felix.framework.resolver.ResolveException: Unable to resolve module org.apache.felix.http.bundle [36.0] because it is exposed to package 'org.osgi.framework' from org.apache.felix.framework [0] and com.springsource.org.aspectj.tools [47.0] via two dependency chains.

Chain 1:
  org.apache.felix.http.bundle [36.0]
    import: (&(package=org.osgi.framework)(version>=1.3.0))
     |
    export: package=org.osgi.framework
  org.apache.felix.framework [0]

Chain 2:
  org.apache.felix.http.bundle [36.0]
    import: (&(package=org.osgi.service.log)(version>=1.3.0))
     |
    export: package=org.osgi.service.log; uses:=org.osgi.framework
  osgi.cmpn [15.0]
    import: (&(package=org.osgi.framework)(version>=1.5.0)(!(version>=2.0.0)))
     |
    export: package=org.osgi.framework
  com.springsource.org.aspectj.tools [47.0])

Seems like both o.a.felix.framework and c.s.o.aspectj.tools are exporting o.osgi.framework.

I am able to get things running again by removing bundle id 47 (c.s.o.aspectj.tools), but yet to check if there’s other implications. Feels wrong because I removed c.s.o.aspectj.tools but it was indicated as required (or optional) for Groovy by the OBR repository. In fact, it was installed via the obr:deploy command for Groovy.

Feels like c.s.o.aspectj.tools should not be exporting o.osgi.framework, but that’s just a guess as i do not use aspectj tools stuff.

Question: What is the proper way to resolve such issues without resorting to educated guesses?

Answer 1

You are right, c.s.o.aspectj.tools should not be export org.osgi.framework, but apparently it does. To be precise, I checked version 1.6.8, and that has the following export statement:

org.osgi.framework;version="1.6.8.RELEASE"

Furthermore, it does not import org.osgi.framework. This is plain wrong, and I’d say it’s worth a bugreport with the Spring team; if you export, you should usually import, and I can’t think of a valid reason to tag osg.osgi.framework with a different version than it actually has.

How can you get around this for now? The problem with the two resolution chains can be resolved by wiring both http and cmpn to the same framework package; perhaps even a simple osgi:refresh in the shell could help you, since the declared version (1.6.8.RELEASE) is within the import ranges of both http and cmpn, by accident.

If you don’t really need the aspectj stuff, I would leave it out.