JMS messaging issue

[James Gartner]

Folks,
we have a load balancer bundle that works with JMS, and this works fine when installed into Eclipse Virgo.
I am trying to get this to run under Karaf with felix and equinox.  I am starting with equinox since it runs with that in Virgo.  After adding the features:install transacation (required by the bundle), I am seeing issues with it when starting,

 [org.osgi.service.cm.ManagedService, id=202, bundle=64]: Unexpected problem updating Configuration PID=com.test.load_balancer, factoryPID=null, bundleLocation=file:C:\Temp\osgi-load-balancer-1.0.0-SNAPSHOT.jar
java.lang.ClassCastException: org.apache.qpid.client.AMQConnectionFactory cannot be cast to javax.jms.ConnectionFactory

I'm not really sure how to go about debugging why this is the case and was hoping for some ideas, but also a general way to go about debugging these sorts of issues in the container (how to see exactly what jms bundle is providing for my bundle, ALL of the possible jms bundles in the container that are present, etc.?)

I don't have the source for this particular bundle (working on getting that) -- just the jar and config details to go by.

[cschneider]

Hi James,

as ActiveMQConnectionFactory implements ConnectionFactory this exception
typically means that there are two bundles that export the javax.jms
package.
Check what package:exports says and make sure there is only one bundle
exporting the package.

Btw. in karaf 3 there will be a bundle:diag command that among other
problems shows such duplicate exports.

Christian


Am 03.04.2012 23:11, schrieb James Gartner:

> Folks,
> we have a load balancer bundle that works with JMS, and this works fine when
> installed into Eclipse Virgo.
> I am trying to get this to run under Karaf with felix and equinox.  I am
> starting with equinox since it runs with that in Virgo.  After adding the
> features:install transacation (required by the bundle), I am seeing issues
> with it when starting,
>
>   [org.osgi.service.cm.ManagedService, id=202, bundle=64]: Unexpected problem
> updating Configuration PID=com.test.load_balancer, factoryPID=null,
> bundleLocation=file:C:\Temp\osgi-load-balancer-1.0.0-SNAPSHOT.jar
> java.lang.ClassCastException: org.apache.qpid.client.AMQConnectionFactory
> cannot be cast to javax.jms.ConnectionFactory
>
> I'm not really sure how to go about debugging why this is the case and was
> hoping for some ideas, but also a general way to go about debugging these
> sorts of issues in the container (how to see exactly what jms bundle is
> providing for my bundle, ALL of the possible jms bundles in the container
> that are present, etc.?)
>
> I don't have the source for this particular bundle (working on getting that)
> -- just the jar and config details to go by.
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/JMS-messaging-issue-tp3882408p3882408.html
> Sent from the Karaf - User mailing list archive at Nabble.com.

--

Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

[Claus Ibsen]

On Wed, Apr 4, 2012 at 12:16 AM, Christian Schneider
<[hidden email]> wrote:

> Hi James,
>
> as ActiveMQConnectionFactory implements ConnectionFactory this exception
> typically means that there are two bundles that export the javax.jms
> package.
> Check what package:exports says and make sure there is only one bundle
> exporting the package.
>
> Btw. in karaf 3 there will be a bundle:diag command that among other
> problems shows such duplicate exports.
>

I suggest to backport such a command to the Karaf 2.x line as well.
When people is hit by OSGi issues, they are really in trouble and can
have a hard time to figure out what and how to resolve that.
So any command that can help them is welcome. And ppl will be on the
Karaf 2.x for a long time. As people dont upgrade servers as frequent.

> Christian
>
>
> Am 03.04.2012 23:11, schrieb James Gartner:
>
>> Folks,
>> we have a load balancer bundle that works with JMS, and this works fine
>> when
>> installed into Eclipse Virgo.
>> I am trying to get this to run under Karaf with felix and equinox.  I am
>> starting with equinox since it runs with that in Virgo.  After adding the
>> features:install transacation (required by the bundle), I am seeing issues
>> with it when starting,
>>
>>  [org.osgi.service.cm.ManagedService, id=202, bundle=64]: Unexpected
>> problem
>> updating Configuration PID=com.test.load_balancer, factoryPID=null,
>> bundleLocation=file:C:\Temp\osgi-load-balancer-1.0.0-SNAPSHOT.jar
>> java.lang.ClassCastException: org.apache.qpid.client.AMQConnectionFactory
>> cannot be cast to javax.jms.ConnectionFactory
>>
>> I'm not really sure how to go about debugging why this is the case and was
>> hoping for some ideas, but also a general way to go about debugging these
>> sorts of issues in the container (how to see exactly what jms bundle is
>> providing for my bundle, ALL of the possible jms bundles in the container
>> that are present, etc.?)
>>
>> I don't have the source for this particular bundle (working on getting
>> that)
>> -- just the jar and config details to go by.
>>
>> --
>> View this message in context:
>> http://karaf.922171.n3.nabble.com/JMS-messaging-issue-tp3882408p3882408.html
>> Sent from the Karaf - User mailing list archive at Nabble.com.
>
>
>
> --
>
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>

--
Claus Ibsen
-----------------
CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

[James Gartner]

Thanks Christian.

I did this:
packages:exports | grep javax.jms,  and I get:

karaf@root> packages:exports | grep javax.jms
    96 javax.jms; version="1.1.0"

Looks like I have only one.  Also, even if there were multiple bundles exporting the javax.jms, I thought the whole point is that OSGi would only wire up ONE of them to my bundle that requires it, and then just use that?
My bundle is marked ACTIVE:
[  64] [Active     ] [            ] [   60] OSGi-Enabled MSP Load Balancer (1.0.0.SNAPSHOT)
so presumably, it has been resolved to one of the particular instances (if there were multiples of the package exporters).

If I just look for JMS:
karaf@root> packages:exports  | grep jms
    96 javax.jms; version="1.1.0"
    97 org.springframework.jms; version="3.0.6.RELEASE"
    97 org.springframework.jms.config; version="3.0.6.RELEASE"
    97 org.springframework.jms.connection; version="3.0.6.RELEASE"
    97 org.springframework.jms.core; version="3.0.6.RELEASE"
    97 org.springframework.jms.core.support; version="3.0.6.RELEASE"
    97 org.springframework.jms.listener; version="3.0.6.RELEASE"
    97 org.springframework.jms.listener.adapter; version="3.0.6.RELEASE"
    97 org.springframework.jms.listener.endpoint; version="3.0.6.RELEASE"
    97 org.springframework.jms.remoting; version="3.0.6.RELEASE"
    97 org.springframework.jms.support; version="3.0.6.RELEASE"
    97 org.springframework.jms.support.converter; version="3.0.6.RELEASE"
    97 org.springframework.jms.support.destination; version="3.0.6.RELEASE"

Could the springframework.jms be the "other" package?  Since I can't get rid of springframework (required for some of our services bundles), how do I resolve this? Should I explicitly import the springframework version?  OR just specify version to import as 3.0.6.RELEASE ??

[James Gartner]

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.

[cschneider]

That sounds familiar.

If one bundle includes e.g. javax.jms and another bundle wires it from a
normal jms spec bundle then these bundles can not exchange objects like
the ConnectionFactory.
In OSGi two classes are only the same if they have the same FQN and are
created by the same classloader. So the correct solution would be that
the bundle that includes the javax.jms should rather import the package
instead. Then OSGi will wire up things correctly.

Christian


Am 04.04.2012 16:25, schrieb James Gartner:

> 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.

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com