karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ed Welch" ...@edjusted.com>
Subject Blueprint service behavior,
Date Fri, 02 Jan 2015 14:39:44 GMT
I've encountered a scenario which I'm hoping someone can help me understand better, and see
if there is a problem or some kind of workaround I can implement.  

Lets say I have 3 bundles A,B,C

A uses a service provided by B, B uses a service provided by C:

A <- B <- C

My application is initiated by a JMS message received by bundle A, which calls the service
exported by B, which calls the service exported by C.

This all works perfectly, until.....

I am using the Karaf bundle:watch feature (which is fantastic) and I re-build bundle B.

Karaf sees the change and does an update on bundle B.

When the next JMS message comes into A, it calls the service exported by B

And i've seen two distinct failures, and I haven't really been able to pin down how to uniquely
replicate each.

When A tries to call B, I sometimes get:

getService() returned null for [interface exported by B] 

but also, more strangely, sometimes the call from A->B works, and when B->C is called
I get: 

An Unexpected Error Occurred: org.osgi.service.blueprint.container.ServiceUnavailableException:
The Blueprint container is being or has been destroyed: [interface exported by C, which is
consumed by B]

I was under the impression that the Blueprint service proxies would handle this kind of bundle
update for me, but no matter how many times i've tried this, the only way i can get it to
successfully work after bundle B is updated, is to refresh bundle A.

I'm running Karaf 3.0.2 (with a patched org.apache.karaf.bundle.core jar file provided by
Jean-Baptiste from this thread: http://karaf.922171.n3.nabble.com/karaf-3-0-2-bundle-watch-not-working-td4035923.html
which makes the watch feature work in 3.0.2)
On Java 8 update 25 (32bit), Windows 7

I'm really looking for two things, someone confirming this behavior is expected, and not an

And if this is the expected behavior, is there a way I can automatically trigger the refresh
of bundle A when bundle B is updated by bundle:watch? 


Ed Welch
View raw message