Why are uses constraints violated when both chains end in the same bundle?

Question

I have four bundles, each containing only a manifest. The bundles are

app which imports com.example.foo.fragment and com.example.bar
foo which exports com.example.foo;uses:=com.example.foo.cfg
foo.fragment which is a fragment attached to foo that exports com.example.foo.fragment and com.example.foo.fragment.cfg;uses:=com.example.foo.fragment
bar which exports com.example.bar and imports com.example.foo

Bundle-level dependency graph:

app -> bar
|       |
|       v
|      foo
|       |
v       v
foo.fragment

When I install these bundles all at once in JBoss AS 7.2, they work just fine. But if I install the app bundle after the others, either for the first time or after successfully starting and then uninstalling it, the following uses constraint violation occurs:

Caused by: org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to resolve resource com.example.app [HostBundleRevision[com.example.app:0.0.
0]] because it is exposed to package 'com.example.foo.fragment' from resources com.example.foo [HostBundleRevision[com.example.foo:0.0.0]] and com.example.foo [HostBund
leRevision[com.example.foo:0.0.0]] via two dependency chains.

Chain 1:
  com.example.app [HostBundleRevision[com.example.app:0.0.0]]
    import: null
     |
    export: osgi.wiring.package=com.example.foo.fragment
  com.example.foo [HostBundleRevision[com.example.foo:0.0.0]]

Chain 2:
  com.example.app [HostBundleRevision[com.example.app:0.0.0]]
    import: null
     |
    export: osgi.wiring.package=com.example.bar; uses:=com.example.foo
  com.example.bar [HostBundleRevision[com.example.bar:0.0.0]]
    import: null
     |
    export: osgi.wiring.package=com.example.foo; uses:=com.example.foo.fragment
    export: osgi.wiring.package=com.example.foo.fragment
  com.example.foo [HostBundleRevision[com.example.foo:0.0.0]]
        at org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1142)
        at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:197)
        at org.jboss.osgi.resolver.felix.StatelessResolver.resolve(StatelessResolver.java:56)
        at org.jboss.osgi.framework.internal.ResolverImpl.resolveAndApply(ResolverImpl.java:137)
        at org.jboss.as.osgi.service.BundleLifecycleIntegration$BundleLifecycleImpl.activateDeferredPhase(BundleLifecycleIntegration.java:296)
        ... 31 more

The full manifests are:

app.jar/META-INF/MANIFEST.MF
----------------------------
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName: com.example.app
Import-Package: com.example.foo.fragment,com.example.bar
----------------------------
foo.jar/META-INF/MANIFEST.MF
----------------------------
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName: com.example.foo
Export-Package: com.example.foo;uses:="com.example.foo.cfg"
-------------------------------------
foo.fragment.jar/META-INF/MANIFEST.MF
-------------------------------------
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName: com.example.foo.fragment
Fragment-Host: com.example.foo
Export-Package: com.example.foo.fragment,com.example.foo.cfg;uses:="co
 m.example.foo.fragment"
----------------------------
bar.jar/META-INF/MANIFEST.MF
----------------------------
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName: com.example.bar
Export-Package: com.example.bar;uses:="com.example.foo"
Import-Package: com.example.foo

I have not been able to reproduce the above error in standalone Apache Felix 4.2.1.

What is the cause of this behaviour? If I delete the Fragment-Host: com.example.foo row from the foo.fragment manifest, I can reinstall app just fine without errors. Is this a bug in JBoss AS 7.2?

I agree this is pretty weird. I'm tempted to call this a bug in the JBoss AS framework implementation, in which case it should be reported on the JBoss mailing list and/or issue tracker. — Neil Bartlett
After monkeying around with it a bit, I noticed that this only occurs if my application is not deployed when JBoss starts up. Maybe there is, after all, another bundle exporting org.hibernate.annotations, and the OSGi platform resolves that as the dependency of the Spring ORM bundle if the OSGi platform starts up without my application. Then I deploy my application, and OSGi fails to resolve it because it is not compatible with the org.hibernate.annotations bundle resolved to the Spring ORM bundle. Does that sound feasible? — Emil Lundberg
I have now also started a discussion in the JBoss community: community.jboss.org/thread/229824 — Emil Lundberg
@NeilBartlett I just figured out the answer to question 2: the bundle exporting org.hibernate.annotations is a fragment with Fragment-Host: com.springsource.org.hibernate. — Emil Lundberg
This looks like a bug. Fragment bundles are supposed to be act as if they are part of their host bundle.It looks like in some cases JBoss is treating the fragment as a separate bundle when performing the classpath consistency check. — jgibson

user3555572 user3555572 · Accepted Answer · 2015-01-28T07:31:12

You don't have to import foo.fragment in app your dependency will resolve from foo. so just remove that dependency and re-deploy that. This issue is because of cyclic dependency.

Why are uses constraints violated when both chains end in the same bundle?

1 Answers