Why does Findbugs JSR305 break OSGi package export of javax.annotations in RedHat/JBoss Fuse 6.3.0? - osgi

We need FindBugs JSR305 as a dependency and we deploy it as a wrapped OSGi bundle to Fuse 6.3.0. At first it looks like everything is fine and the components are working well. But after a restart, many bundles that depend on javax.annoation API are not starting anymore. We found out, that the javax.annoation API Bundle that comes with the Fuse installation does not export the package javax.annoation after the restart. Although the bundle of the javax.annotation API starts without errors and exports other packages.
The error occurs with RedHat Fuse 6.3.0.475 and the corresponding Karaf 2.4.0.redhat-630475.
We already tried the ServiceMix JSR305 Bundle from Maven Repository, but it exports the javax.annotation in version 1.1.0 and we need version 3.0.2. Maybe this is a mistake too, because I would expect an export of javax.annotation 3.0.2 from the bundle version 3.0.2_1.
Manifest-Version: 1.0
Bnd-LastModified: 1493877706145
Build-Jdk: 1.8.0_111
Built-By: jbonofre
Bundle-Description: This OSGi bundle wraps jsr305 1.1.0 jar file.
Bundle-DocURL: http://www.apache.org/
Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt
Bundle-ManifestVersion: 2
Bundle-Name: Apache ServiceMix :: Bundles :: jsr305
Bundle-SymbolicName: org.apache.servicemix.bundles.jsr305
Bundle-Vendor: The Apache Software Foundation
Bundle-Version: 3.0.2.1
Created-By: Apache Maven Bundle Plugin
Export-Package: javax.annotation;version="1.1.0";uses:="javax.annotation.meta",javax.annotation.concurrent;version="1.1.0",javax.annotation.meta;version="1.1.0";uses:="javax.annotation"
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.5))"
Tool: Bnd-3.2.0.201605172007
Reproduction
Setup a new Fuse 6.3.0 installation. With "pacakges:exports | grep javax.annoation;" you can find out that javax.annoation is exported in version 1.0.0 from System Bundle and in version 1.2.0 from javax.annoation API.
JBossFuse:karaf#root> packages:exports | grep javax.annotation\;
0 javax.annotation; version=1.0.0
60 javax.annotation; version=1.2.0
Now install FindBugs JSR305 as a wrapped OSGi bundle to the instance. There are three exports of the javax.annotation package now including version 3.0.2 of the FindBugs JSR305 bundle and everything is working.
JBossFuse:karaf#root> packages:exports | grep javax.annotation\;
0 javax.annotation; version=1.0.0
60 javax.annotation; version=1.2.0
294 javax.annotation; version=3.0.2
Now restart the instance via admin script or "dev:restart" and after the instance is up again you will see some broken bundles, because javax.annoation API stopped to export version 1.2.0 of the javax.annotation package.
JBossFuse:karaf#root> packages:exports | grep javax.annotation\;
0 javax.annotation; version=1.0.0
294 javax.annotation; version=3.0.2
If you try the same with a fresh Fuse 7.0.0 installation, which runs with Karaf 4.2.0 and where javax.annotation API is still included, the error will not occur. It also works with Fuse 7.7.0, but there javax.annotation API is not included anymore and the java.annotation packages are exported just from Sytem Bundle.

I had the same problem (and yes - in JBoss Fuse). After upgrading to Zookeeper 3.4.14 we had this in mvn dependency:tree:
[INFO] | \- org.apache.zookeeper:zookeeper:jar:3.4.14:compile
[INFO] | +- org.slf4j:slf4j-log4j12:jar:1.7.10:compile
[INFO] | +- com.github.spotbugs:spotbugs-annotations:jar:3.1.9:compile
[INFO] | | \- com.google.code.findbugs:jsr305:jar:3.0.2:compile
Findbugs library is simply broken:
JBossFuse:karaf#root> install mvn:com.google.code.findbugs/jsr305/3.0.2
Bundle ID: 295
JBossFuse:karaf#root> headers 295
FindBugs-jsr305 (295)
---------------------
Archiver-Version = Plexus Archiver
Created-By = Apache Maven Bundle Plugin
Manifest-Version = 1.0
Bnd-LastModified = 1490936130302
Build-Jdk = 1.8.0_101
Built-By = lan
Tool = Bnd-2.1.0.20130426-122213
Bundle-License = http://www.apache.org/licenses/LICENSE-2.0.txt
Bundle-ManifestVersion = 2
Bundle-SymbolicName = org.jsr-305
Bundle-Version = 3.0.2
Bundle-Name = FindBugs-jsr305
Bundle-Description = JSR305 Annotations for Findbugs
Export-Package =
javax.annotation;uses:=javax.annotation.meta;version=3.0.2,
javax.annotation.concurrent;version=3.0.2,
javax.annotation.meta;uses:=javax.annotation;version=3.0.2
because it exports javax.annotation package with non existing version. If you check JSR 250, Common Annotations for the JavaTM Platform, its version should be 1.3 and it matches the versions from Maven Central.
In our case, we've changed activemq-osgi to import javax.annotation;version="[1,4)" instead of just javax.annotation, so maven-bundle-plugin didn't generate bad javax.annotation;version="[3,4)".
But IMO, findbugs should NOT use javax.annotation package at all...

Related

Karaf OSGI How to resolve a two dependency chain conflict for Google Guava

2.8 together with its cxf feature 3.3.5, with cxf-jaxrs which is installed as feature comes a dependency to Google Guava 20.0. I have my own project where I install a couple of jars via Karaf feature, among them a Google Guava 18.0. The bundle I want now to install has a Google Guava dependency for 18.0, however i get the following error:
Chain 1:
arcanite-core [arcanite-core [269](R 269.0)]
import: (&(osgi.wiring.package=com.google.common.collect)(version>=18.0.0)(!(version>=19.0.0)))
|
export: osgi.wiring.package: com.google.common.collect
com.google.guava [com.google.guava [253](R 253.0)]
Chain 2:
arcanite-core [arcanite-core [269](R 269.0)]
import: (&(osgi.wiring.package=com.querydsl.core)(version>=4.2.0)(!(version>=5.0.0)))
|
export: osgi.wiring.package=com.querydsl.core; uses:=com.google.common.collect
com.querydsl.core [com.querydsl.core [255](R 255.0)]
import: (&(osgi.wiring.package=com.google.common.collect)(version>=18.0.0))
|
export: osgi.wiring.package: com.google.common.collect
com.google.guava [com.google.guava [172](R 172.0)] Unresolved requirements: [[arcanite-core [269](R 269.0)] osgi.wiring.package; (&(osgi.wiring.package=com.querydsl.core)(version>=4.2.0)(!(version>=5.0.0)))]
In my imports for the project I have explicitly imported the 18.0 version:
<Import-Package>
...
com.google.common.collect;version="[18.0,19.0)",
*
<Import-Package>
How can I get rid of this conflict, is this really about having only one version of Guava in Karaf ( OSGI ), what am i doing wrong?
Ok that was a tricky one, as said the cxf-feature made up a dependecy to Guava 20.0.
Then installing my own feature with query-dsl and guvava 18.0 jar inside.
But the dependency querydsl to guava was not resolved according to maven, but according to the already existing guava in karaf so 20.0.
When i now install a bundle with query-dsl and guava 18.0 then there is the conflict.
In the end i removed 18.0 library from the feature and allowed a larger version range in my project:
...
com.google.common.collect;version="[18.0,23.0)",
*
And the conflict was gone, makes me wonder how would i specify such a dependency, here between querydsl and guava 18.0 in the feature.xml, if possible at all.

OSGi bundle export versioning

I'm pretty new in osgi world, and probably missing something, and i'm having troubles exposing different versions of the same sevice for liferay.
Here is what i am trying to do (and sorry for my english):
I wrote a service, wrapped it in a bundle and successfully deployed it on osgi. My bnd.bnd file looks like this
Bundle-Name: it.peernetwork.lr.pilot.test-services
Bundle-SymbolicName: pilot--test-services
Bundle-Version: 7.1.0
Bundle-Activator: it.peernetwork.lr.pilot.testservices.impl.TestServicesActivator
Export-Package: it.peernetwork.lr.pilot.testservices
and, once packaged, the manifest file is like this
Manifest-Version: 1.0
Bnd-LastModified: 1542646653910
Bundle-Activator: it.peernetwork.lr.pilot.testservices.impl.TestServic
esActivator
Bundle-ClassPath: .,lib/pn--logger-7.1.0.jar,lib/pn--services-base-7.1
.0.jar,lib/pn--prop-files-7.1.0.jar,lib/gson-2.8.5.jar,lib/pn--expand
o-values-7.1.0.jar
Bundle-ManifestVersion: 2
Bundle-Name: it.peernetwork.lr.pilot.test-services
Bundle-SymbolicName: pilot--test-services
Bundle-Version: 7.1.0
Created-By: 1.8.0_191 (Oracle Corporation)
Export-Package: it.peernetwork.lr.pilot.testservices;version="7.1.0"
Import-Package: com.liferay.expando.kernel.exception;version="[1.0,2)"
,com.liferay.expando.kernel.model;version="[1.1,2)",com.liferay.expan
do.kernel.service;version="[1.1,2)",com.liferay.portal.kernel.excepti
on;version="[7.2,8)",com.liferay.portal.kernel.model;version="[2.0,3)
",it.peernetwork.lr.pilot.testservices,org.osgi.framework;version="[1
.8,2)"
Javac-Debug: on
Javac-Deprecation: off
Javac-Encoding: UTF-8
Private-Package: it.peernetwork.lr.pilot.test.services.impl,it.peernet
work.lr.pilot.testservices.impl,it.peernetwork.lr.pilot.testservices.
x,lib,it.peernetwork.lr.logger,it.peernetwork.lr.servicesbase,it.peer
network.lr.propfiles,it.peernetwork.lr.propfiles.utils,com.google.gso
n,com.google.gson.annotations,com.google.gson.internal,com.google.gso
n.internal.bind,com.google.gson.internal.bind.util,com.google.gson.in
ternal.reflect,com.google.gson.reflect,com.google.gson.stream,it.peer
network.lr.expandovalues
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
Tool: Bnd-3.2.0.201605172007
This manifest file declares
Export-Package: it.peernetwork.lr.pilot.testservices;version="7.1.0"
and i think this is correct.
Once deployed (successfully) i check the bundle state with the command bundle __BUNDLE_ID__ that gives me
pilot--test-services_7.1.0 [1014]
Id=1014, Status=ACTIVE Data Root=/home/ltrioschi/development/liferay-osgi/liferay-ce-portal-7.1.0-ga1/osgi/state/org.eclipse.osgi/1014/data
"Registered Services"
{it.peernetwork.lr.pilot.testservices.UselessService}={service.id=1607, service.bundleid=1014, service.scope=singleton}
No services in use.
Exported packages
it.peernetwork.lr.pilot.testservices; version="7.1.0"[exported]
Imported packages
com.liferay.expando.kernel.exception; version="1.0.0" <org.eclipse.osgi_3.10.200.v20150831-0856 [0]>
com.liferay.expando.kernel.model; version="1.1.0" <org.eclipse.osgi_3.10.200.v20150831-0856 [0]>
com.liferay.expando.kernel.service; version="1.1.0" <org.eclipse.osgi_3.10.200.v20150831-0856 [0]>
com.liferay.portal.kernel.exception; version="7.2.0" <org.eclipse.osgi_3.10.200.v20150831-0856 [0]>
com.liferay.portal.kernel.model; version="2.0.0" <org.eclipse.osgi_3.10.200.v20150831-0856 [0]>
org.osgi.framework; version="1.8.0" <org.eclipse.osgi_3.10.200.v20150831-0856 [0]>
No fragment bundles
No required bundles
Then i wrote a portlet that requires this service. The bnd.dnd file is
Bundle-Name: it.peernetwork.lr.pilot.test-portlet
Bundle-SymbolicName: pilot--test-portlet
Bundle-Version: 7.1.0
Import-Package: \
it.peernetwork.lr.pilot.testservices;version=[7.1.0],\
*
-metatype: *
And once deployed it loads correctly the service and uses it with no issues.
Now...my problem is i need a new version of the service, but i do not want to undeploy the current version.
So i wrote the new version of the service and the new bnd.bnd file is
Bundle-Name: it.peernetwork.lr.pilot.test-services
Bundle-SymbolicName: pilot--test-services
Bundle-Version: 7.1.1
Bundle-Activator: it.peernetwork.lr.pilot.testservices.impl.TestServicesActivator
Export-Package: it.peernetwork.lr.pilot.testservices
(the only difference is the Bundle-Version)
Once packaged the only difference in manifest file is the Export-Package line
Export-Package: it.peernetwork.lr.pilot.testservices;version="7.1.1"
and looks like it smoothly deploys on osgi
g! lb pilot
START LEVEL 20
ID|State |Level|Name
1014|Active | 10|it.peernetwork.lr.pilot.test-services (7.1.0)
1015|Active | 10|it.peernetwork.lr.pilot.test-services (7.1.1)
but with the command bundle ___NEW_BUNDLE_ID___ i get
No exported packages
instead of
Exported packages
it.peernetwork.lr.pilot.testservices; version="7.1.1"[exported]
(that i expected). It means (to me) that the bundle is deployed, but none of its services are exposed.
Then i updated my portlets bundle (bnd.bnd) this way
Bundle-Name: it.peernetwork.lr.pilot.test-portlet
Bundle-SymbolicName: pilot--test-portlet
Bundle-Version: 7.1.0
Import-Package: \
it.peernetwork.lr.pilot.testservices;version=[7.1.1],\
*
-metatype: *
(changed version in Import-Package) and deployed on osgi. Deploy was correct, but it still uses the old version of the services bundle (7.1.0) even if Import-Package declares version 7.1.1. It does not give error because of the "missing" requested service version.
Can someone give me some tips about what i am doing wrong?
Thanks in advance.
UPDATE 1
Dependencies in build.gradle file have been updated accordingly with the version specified in bnd.bnd.
UPDATE 2
#quatax
The updated portlet bundle's manifest file has Import-Package: it.peernetwork.lr.pilot.testservices;version="[7.1.1]" (followed by all other required imports)...seems correct to me...
UPDATE 3
#Neil Bartlett (Service version updated to 8.0.0)
I updated pilot--test-services bnd.bnd file setting Bundle-Version: 8.0.0.
The whole bnd.bnd file is
Bundle-Name: it.peernetwork.lr.pilot.test-services
Bundle-SymbolicName: pilot--test-services
Bundle-Version: 8.0.0
Bundle-Activator: it.peernetwork.lr.pilot.testservices.impl.TestServicesActivator
Export-Package: it.peernetwork.lr.pilot.testservices
Manifest file is
Manifest-Version: 1.0
Bnd-LastModified: 1543316524201
Bundle-Activator: it.peernetwork.lr.pilot.testservices.impl.TestServic
esActivator
Bundle-ClassPath: .,lib/pn--logger-7.1.0.jar,lib/pn--services-base-7.1
.0.jar,lib/pn--prop-files-7.1.0.jar,lib/gson-2.8.5.jar,lib/pn--expand
o-values-7.1.0.jar
Bundle-ManifestVersion: 2
Bundle-Name: it.peernetwork.lr.pilot.test-services
Bundle-SymbolicName: pilot--test-services
Bundle-Version: 8.0.0
Created-By: 1.8.0_191 (Oracle Corporation)
Export-Package: it.peernetwork.lr.pilot.testservices;version="8.0.0"
Import-Package: com.liferay.expando.kernel.exception;version="[1.0,2)"
,com.liferay.expando.kernel.model;version="[1.1,2)",com.liferay.expan
do.kernel.service;version="[1.1,2)",com.liferay.portal.kernel.excepti
on;version="[7.2,8)",com.liferay.portal.kernel.model;version="[2.0,3)
",it.peernetwork.lr.pilot.testservices,org.osgi.framework;version="[1
.8,2)"
Javac-Debug: on
Javac-Deprecation: off
Javac-Encoding: UTF-8
Private-Package: it.peernetwork.lr.pilot.test.services.impl,it.peernet
work.lr.pilot.testservices.impl,it.peernetwork.lr.pilot.testservices.
x,lib,it.peernetwork.lr.logger,it.peernetwork.lr.servicesbase,it.peer
network.lr.propfiles,it.peernetwork.lr.propfiles.utils,com.google.gso
n,com.google.gson.annotations,com.google.gson.internal,com.google.gso
n.internal.bind,com.google.gson.internal.bind.util,com.google.gson.in
ternal.reflect,com.google.gson.reflect,com.google.gson.stream,it.peer
network.lr.expandovalues
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
Tool: Bnd-3.2.0.201605172007
. When i deploy it it seems ok (starts and status is "Active"), but bundle ___ID___ says No exported packages
Then i updated pilot--test-portlet's build.gradle setting the correct version of the dependency (8.0.0). It's manifes file says Import-Package: it.peernetwork.lr.pilot.testservices;version="[8.0,9). When i deploy this package it does not start (status "Installed" and error Unresolved requirement: Import-Package: it.peernetwork.lr.pilot.testservices; version="[8.0.0,9.0.0)")
UPDATE 4 -- -- RESOLVED
Thank you very much #Neil. Thanks to your tips i solved my issue. The right advice was this.
Explicitally declaring
Import-Package: it.peernetwork.lr.pilot.testservices;version="[7.2,8)",\
*
in the pilot--test-services's bnd.bnd file (self import, with the opportune version range) makes osgi export correctly the package and loads the correct class instances when required.
The complete bnd.bnd file is
Bundle-Name: it.peernetwork.lr.pilot.test-services
Bundle-SymbolicName: pilot--test-services
Bundle-Version: 7.2.0
Bundle-Activator: it.peernetwork.lr.pilot.testservices.impl.TestServicesActivator
Export-Package: it.peernetwork.lr.pilot.testservices
Import-Package: it.peernetwork.lr.pilot.testservices;version="[7.2,8)",\
*
In pilot--test-portlet's build.gradle file i only had to update the dependency version
compileOnly group: "it.peernetwork.lr", name: "pilot--test-services", version: "7.2.0"
I tried with version 7.1.0, 7.2.0 and 8.0.0 and works smoothly. All "services" bundles are deployed on osgi. Deploying the portlet bundle with different dependency versions always takes the right service.
Thank you again.
I recommend deleting the Import-Package instruction from your bnd.bnd file for the pilot--test-portlet bundle. It is not necessary: bnd will generate all the imports you need based on the actual requirements in your code.
Your original bundle pilot--test-services both exports and imports the package it.peernetwork.lr.pilot.testservices. This is correct when your bundle makes use of the package itself in addition to exporting it. Therefore when you install both v7.1.0 and v7.1.1, the v7.1.0 bundle will import the package from the other version instead of exporting the older version. The pilot--test-portlet correctly imports from version 7.1.1.
In other words, everything here is working the way it should.

How does OSGi bundle get started without Bundle-Activator

How can an OSGi bundle become active without Bundle-Activator in the MANIFEST-MF file? For example, Google guava can run as a bundle and become active in Karaf container but the MANIFEST-MF file doesn't include Bundle-Activator property.
Manifest-Version: 1.0
Bnd-LastModified: 1408992499326
Build-Jdk: 1.7.0-google-v6
Built-By: cgdecker
Bundle-Description: Guava is a suite of core and expanded libraries that
include utility classes, google's collections, io classes, and much
much more. Guava has only one code dependency - javax.annotation
, per the JSR-305 spec.
Bundle-DocURL: https://guava-libraries.googlecode.com/
Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt
Bundle-ManifestVersion: 2
Bundle-Name: Guava: Google Core Libraries for Java
Bundle-SymbolicName: com.google.guava
Bundle-Version: 18.0.0
Created-By: Apache Maven Bundle Plugin
Export-Package: com.google.common.net;uses:="javax.annotation,com.google
.common.base,com.google.common.hash,com.google.common.io,com.google.com
mon.primitives,com.google.common.collect,com.google.common.escape";vers
ion="18.0.0",com.google.common.html;uses:="com.google.common.escape,jav
ax.annotation";version="18.0.0",com.google.common.collect;uses:="com.go
ogle.common.base,javax.annotation,com.google.common.primitives,com.goog
le.common.math";version="18.0.0",com.google.common.primitives;uses:="co
m.google.common.base,javax.annotation,sun.misc";version="18.0.0",com.go
ogle.common.base;uses:="javax.annotation";version="18.0.0",com.google.c
ommon.escape;uses:="com.google.common.base,javax.annotation";version="1
8.0.0",com.google.common.cache;uses:="com.google.common.collect,com.goo
gle.common.util.concurrent,javax.annotation,com.google.common.base,com.
google.common.primitives,sun.misc";version="18.0.0",com.google.common.e
ventbus;uses:="com.google.common.collect,com.google.common.cache,javax.
annotation,com.google.common.base,com.google.common.util.concurrent,com
.google.common.reflect";version="18.0.0",com.google.common.util.concurr
ent;uses:="com.google.common.base,javax.annotation,com.google.common.co
llect,com.google.common.primitives,com.google.common.math";version="18.
0.0",com.google.common.hash;uses:="com.google.common.primitives,com.goo
gle.common.base,javax.annotation,com.google.common.math";version="18.0.
0",com.google.common.io;uses:="javax.annotation,com.google.common.base,
com.google.common.math,com.google.common.hash,com.google.common.collect
,com.google.common.primitives";version="18.0.0",com.google.common.xml;u
ses:="com.google.common.escape,javax.annotation";version="18.0.0",com.g
oogle.common.reflect;uses:="javax.annotation,com.google.common.base,com
.google.common.collect,com.google.common.primitives";version="18.0.0",c
om.google.common.math;uses:="com.google.common.base,com.google.common.p
rimitives,javax.annotation";version="18.0.0",com.google.common.annotati
ons;version="18.0.0"
Import-Package: javax.annotation;resolution:=optional,sun.misc;resolutio
n:=optional
Tool: Bnd-1.50.0
For one, there are also other means of starting a logic in a bundle, for example it could be Blueprint, or Declarative Services. But I doubt guava does have that,
so what you see here is a typical case.
An OSGi bundle usually follows the following steps:
a) installed
b) resolved
c) starting
d) active
e) stopping
f) uninstalled
This is for all bundles, only fragments will stay in the resolved state as a fragment bundle itself can't be started/activated.
If your bundle (or guava in this case) doesn't have an explicit Activator class which will be called in the active stage, the bundle still can be active.

OSGi two dependency chains - cannot resolve dependencies

We're using OSGi for a rest application using bdntools and eclipse. We've deployed the application and everything is working OK.
The run descriptor we were using was OK, but we've copied the run requirements to a new run descriptor and now we are unable to resolve the dependencies, caused by the following error:
Uses constraint violation.
Unable to resolve resource org.apache.felix.http.whiteboard [org.apache.felix.http.whiteboard ver=2.2.0]
because it is exposed to package 'javax.servlet' from resources
org.amdatu.multitenant.org.apache.felix.http.jetty [org.amdatu.multitenant.org.apache.felix.http.jetty ver=1.0.0]
and org.apache.felix.http.jetty [org.apache.felix.http.jetty ver=2.2.0] via two dependency chains.
We're having this problem more often, usually it is solved by creating a new run descriptor, but not this time..
Is this a bug in bndtools or are we doing something wrong? We also have the impression it might have something to do with multiple repositories.
Edit:
Here is the run descriptor and are the manifests of the bundles.
Run descriptor:
-runfw: org.apache.felix.framework;version='[4,5)'
-runee: JavaSE-1.7
-runsystemcapabilities: ${native_capability}
-resolve.effective: active
-runrequires: osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.shell)',\
osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.command)',\
osgi.identity;filter:='(osgi.identity=org.apache.felix.http.jetty)',\
osgi.identity;filter:='(osgi.identity=org.apache.felix.http.whiteboard)'
Manifest org.apache.felix.http.jetty:
Manifest-Version: 1.0
Export-Package: org.apache.felix.http.api;uses:="javax.servlet,org.osg
i.service.http";version="2.0.4",org.osgi.service.http;uses:="javax.se
rvlet.http,javax.servlet";version="1.2",javax.servlet.resources;versi
on="2.5",javax.servlet;version="2.5",javax.servlet.jsp.resources;vers
ion="2.5",javax.servlet.http;uses:="javax.servlet";version="2.5"
Built-By: fmeschbe
Tool: Bnd-0.0.357
Bundle-Name: Apache Felix Http Jetty
Created-By: Apache Maven Bundle Plugin
Bundle-Vendor: The Apache Software Foundation
DynamicImport-Package: org.osgi.service.cm;version=1.2
Build-Jdk: 1.6.0_13
Bundle-Version: 2.2.0
Bnd-LastModified: 1296053619491
Bundle-Activator: org.apache.felix.http.jetty.internal.JettyActivator
Bundle-ManifestVersion: 2
Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt
Bundle-Description: Apache Felix is an OSGi implementation.
Bundle-DocURL: http://www.apache.org/
Bundle-SymbolicName: org.apache.felix.http.jetty
Import-Package: javax.net.ssl;resolution:=optional,javax.security.cert
;resolution:=optional,javax.servlet;resolution:=optional;version="2.5
",javax.servlet.http;resolution:=optional;version="2.5",javax.servlet
.jsp.resources;resolution:=optional;version="2.5",javax.servlet.resou
rces;resolution:=optional;version="2.5",javax.xml.parsers;resolution:
=optional,org.apache.felix.http.api;resolution:=optional;version="2.0
",org.osgi.framework;resolution:=optional;version="1.3",org.osgi.serv
ice.http;resolution:=optional;version="1.2",org.osgi.service.log;reso
lution:=optional;version="1.3",org.osgi.util.tracker;resolution:=opti
onal;version="1.3",org.slf4j;resolution:=optional,org.xml.sax;resolut
ion:=optional,org.xml.sax.helpers;resolution:=optional
Manifest org.amdatu.multitenant.org.apache.felix.http.jetty:
Manifest-Version: 1.0
Bnd-LastModified: 1338812262683
Build-Jdk: 1.6.0_32
Built-By: ?
Bundle-Activator: org.amdatu.tenant.adapter.MultiTenantBundleActivator
Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.html
Bundle-ManifestVersion: 2
Bundle-Name: Amdatu Web - Multi-Tenant HttpService
Bundle-SymbolicName: org.amdatu.multitenant.org.apache.felix.http.jetty
Bundle-Version: 1.0.0
Created-By: Apache Maven Bundle Plugin
Embed-Dependency: *;scope=compile;inline=true
Embed-Transitive: false
Export-Package: org.apache.felix.http.api;uses:="javax.servlet,org.osgi.
service.http";version="2.0.4",org.osgi.service.http;uses:="javax.servle
t.http,javax.servlet";version="1.2",javax.servlet.resources;version="2.
5",javax.servlet;version="2.5",javax.servlet.jsp.resources;version="2.5
",javax.servlet.http;uses:="javax.servlet";version="2.5"
Import-Package: javax.net.ssl;resolution:=optional,javax.security.cert;r
esolution:=optional,javax.servlet;resolution:=optional;version="2.5",ja
vax.servlet.http;resolution:=optional;uses:="javax.servlet";version="2.
5",javax.servlet.jsp.resources;resolution:=optional;version="2.5",javax
.servlet.resources;resolution:=optional;version="2.5",javax.xml.parsers
;resolution:=optional,org.amdatu.tenant;version="[1.0,2)",org.amdatu.te
nant.adapter;version="[1.0,2)",org.apache.felix.http.api;resolution:=op
tional;uses:="javax.servlet,org.osgi.service.http";version="2.0",org.os
gi.framework;resolution:=optional;version="1.3",org.osgi.service.cm;res
olution:=optional;version="1.2",org.osgi.service.http;resolution:=optio
nal;uses:="javax.servlet.http,javax.servlet";version="1.2",org.osgi.ser
vice.log;resolution:=optional;version="1.3",org.osgi.util.tracker;resol
ution:=optional;version="1.3",org.slf4j;resolution:=optional,org.xml.sa
x;resolution:=optional,org.xml.sax.helpers;resolution:=optional
Tool: Bnd-1.50.0
X-MultiTenant-Binding: PLATFORM
X-MultiTenant-Bundle-Activator: org.apache.felix.http.jetty.internal.Jet
tyActivator
X-MultiTenant-Scope: (&(objectClass=org.osgi.service.log.LogService)(|(o
rg.amdatu.tenant.pid=%TENANTPID%)(!(org.amdatu.tenant.pid=*))))
X-MultiTenant-Version: 1
Whiteboard manifest:
Manifest-Version: 1.0
Bnd-LastModified: 1386080857007
Build-Jdk: 1.7.0_40
Built-By: jawi
Bundle-Activator: org.apache.felix.http.whiteboard.internal.WhiteboardAc
tivator
Bundle-Description: Apache Felix is an OSGi implementation.
Bundle-DocURL: http://www.apache.org/
Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt
Bundle-ManifestVersion: 2
Bundle-Name: Apache Felix Http Whiteboard
Bundle-SymbolicName: org.apache.felix.http.whiteboard
Bundle-Vendor: The Apache Software Foundation
Bundle-Version: 2.2.2
Created-By: Apache Maven Bundle Plugin
Embed-Dependency: org.apache.felix.http.base;inline=org/apache/felix/htt
p/base/internal/AbstractActivator*.class|org/apache/felix/http/base/int
ernal/logger/*
Export-Package: org.apache.felix.http.whiteboard;version="1.0"
Implementation-Title: Apache Felix Http Whiteboard
Implementation-Vendor: The Apache Software Foundation
Implementation-Vendor-Id: org.apache.felix
Implementation-Version: 2.2.2
Import-Package: javax.servlet,javax.servlet.http,org.apache.felix.http.a
pi;version="[2.0,3)",org.osgi.framework;version="[1.5,2)",org.osgi.serv
ice.http;version="[1.2,2)",org.osgi.service.log;version="[1.3,2)",org.o
sgi.util.tracker;version="[1.4,2)"
Specification-Title: Apache Felix Http Whiteboard
Specification-Vendor: The Apache Software Foundation
Specification-Version: 2.2.2
Tool: Bnd-1.50.0
OK, there seems to be a bug (in my opinion) in the repositories.bnd. It seems that the amdatu release repository needs to be above dependencies and snapshots.. The following changes solved the bug:
-plugin:\
aQute.bnd.deployer.repository.LocalIndexedRepo; name=Release; local=${workspace}/cnf/releaserepo;pretty=true,\
aQute.bnd.deployer.repository.LocalIndexedRepo; name=Local; local=${workspace}/cnf/localrepo;pretty=true,\
aQute.bnd.deployer.repository.FixedIndexedRepo; name=Bndtools Hub; locations=https://github.com/bndtools/bundle-hub/raw/master/index.xml.gz,\
aQute.bnd.deployer.repository.FixedIndexedRepo; name=Amdatu Dependencies; locations=http://repository.amdatu.org/dependencies/index.xml.gz,\
aQute.bnd.deployer.repository.FixedIndexedRepo; name=Amdatu Snapshots; locations=http://repository.amdatu.org/snapshot/index.xml.gz,\
aQute.bnd.deployer.repository.FixedIndexedRepo; name=Amdatu Release; locations=http://repository.amdatu.org/release/index.xml.gz,\
aQute.lib.deployer.FileRepo; name=Build; location=${workspace}/cnf/buildrepo
-releaserepo: Release
.
-plugin:\
aQute.bnd.deployer.repository.LocalIndexedRepo; name=Release; local=${workspace}/cnf/releaserepo;pretty=true,\
aQute.bnd.deployer.repository.LocalIndexedRepo; name=Local; local=${workspace}/cnf/localrepo;pretty=true,\
aQute.bnd.deployer.repository.FixedIndexedRepo; name=Bndtools Hub; locations=https://github.com/bndtools/bundle-hub/raw/master/index.xml.gz,\
aQute.bnd.deployer.repository.FixedIndexedRepo; name=Amdatu Release; locations=http://repository.amdatu.org/release/index.xml.gz,\
aQute.bnd.deployer.repository.FixedIndexedRepo; name=Amdatu Dependencies; locations=http://repository.amdatu.org/dependencies/index.xml.gz,\
aQute.bnd.deployer.repository.FixedIndexedRepo; name=Amdatu Snapshots; locations=http://repository.amdatu.org/snapshot/index.xml.gz,\
aQute.lib.deployer.FileRepo; name=Build; location=${workspace}/cnf/buildrepo
-releaserepo: Release
The problem here is happening because the javax.servlet is available from resources
org.amdatu.multitenant.org.apache.felix.http.jetty org.amdatu.multitenant.org.apache.felix.http.jetty ver=1.0.0 and org.apache.felix.http.jetty org.apache.felix.http.jetty ver=2.2.0 so the module org.apache.felix.http.whiteboard does not know which javax.servlet to wire with. you could solve the problem by removing the duplication.

BND puts the same package to both export and import sections of manifest.mf

I have a Vaadin application, which I'm trying to build as a set of OSGI bundles using Maven + BND.
I can't deploy the bundles To Apache Felix because some dependencies can't be resolved.
Apache Felix complains that can't find package XYZ required by bundle "A", although this package is defined in this same bundle!!
I looked at the MANIFEST.MF file generated by Maven + BND and saw that the package (XYZ) from this bundle is added to both "import" and "export" sections. I understand why "export", but why "import"?? Why is the bundle trying to import its own package?
my MANIFEST.MF
Manifest-Version: 1.0
Export-Package: myexample.admin;uses:="com.vaadin.ui,myexample.webshared,
com.vaadin.terminal,myexample.mvc.view.impl,
myexample.mvc.model,myexample.mvc.renderer.map.impl,
myexample.mvc.renderer,myexample.mvc.model.impl,myexample.util"
Built-By: ask
Tool: Bnd-0.0.384
Bundle-Name: admin
Created-By: 1.6.0_21 (Sun Microsystems Inc.)
Bundle-Version: 0
Build-Jdk: 1.6.0_26
Bnd-LastModified: 1315674240833
Bundle-ManifestVersion: 2
Import-Package: myexample.admin;version="1.0",myexample.mvc.model,
myexample.mvc.model.impl,myexample.mvc.renderer,
myexample.mvc.renderer.map.impl,myexample.mvc.view.impl,
myexample.util,myexample.webshared,com.vaadin.terminal,com.vaadin.ui
Bundle-SymbolicName: admin
Include-Resource: ..\classes
Originally-Created-By: Apache Maven Bundle Plugin
This is correct behaviour. The explanation is in section 3.5.6 of the OSGi core specification.
Regarding the unresolved error from Felix... this must be related to something else. Please post the actual error message.
Niel is, of course correct. To be honest though, I've been very successful with using the noimports:=true to get around this. In my applications, I usually have the following in my maven-bundle-plugin section:
<Export-package>*;noimports:=true</export-package>
This results in all of your packages being exported into OSGi, and none of them will appear in your import-package section. If you only need a couple of your exported packages to not appear in your import-package section, you can set the noimports flag for each individual package. Lastly, this syntax is from BND, so it should also work in your .bnd files.

Resources