Christian, talking with the developer of that particular bundle, he says that
the jms-api is included in the bundle itself (jms-api-1.1-rev-1.jar in the
bundle). If fact, I don't see that our bundle is importing it at all:
osgi:headers 64
...
...
Bundle-Version = 1.0.0.SNAPSHOT
Bundle-ManifestVersion = 2
Bundle-ClassPath =
.,osgi-common-1.0.0-SNAPSHOT.jar,common-1.0.0-SNAPSHOT.jar,core-1.0.0-SNAPSHOT.jar,protobuf-java-2.4.
r305-1.3.9.jar,joda-time-1.6.2.jar,jms-api-1.1-rev-1.jar,qpid-client-0.10.rh9.jar,qpid-common-0.10.rh9.jar,backport-util
core-1.0.10.jar,mina-filter-ssl-1.0.10.jar,load-balancer-1.0.0-SNAPSHOT.jar,performance-monitor-1.0.0-SNAPSHOT.jar,clienmetrics-core-2.0.3.jar
Import-Package =
javax.management,
javax.naming,
javax.naming.spi,
javax.net.ssl,
javax.security.auth.callback,
javax.security.sasl,
javax.transaction.xa,
org.ietf.jgss,
org.osgi.framework;version="[1.5,2)",
org.osgi.service.cm;version="[1.3,2)",
org.slf4j;version="[1.6,2)",
sun.misc
Since that is the case, could this be the issue -- a jms inside the bundle,
and javax.jms being exported by another bundle?
If so, what are the possible resolutions? Seems that if it is provided
inside the bundle, it shouldn't be looking anyplace else to load it.
We are talking about breaking down the bundles further to make sure we DON'T
include things provided by the containers (like letting the javax.jms be
provided by another bundle instead of including the jar in our bundles) but
we just aren't there yet to do that.
--
View this message in context:
http://karaf.922171.n3.nabble.com/JMS-messaging-issue-tp3882408p3884256.html
Sent from the Karaf - User mailing list archive at Nabble.com.
