Blueprint service behavior,

[Ed Welch <ed...@edjusted.com>]

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

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? 

Thanks!

Ed Welch

Re: Blueprint service behavior,

[Charlie Mordant <cm...@gmail.com>]

Hi,

I think this is an expected behaviour, let me try to explain why:
While referencing your service, you're referencing one instance of it: the
consumer will not see a disapearance/update of it.
So you'll call the old service reference from A to B every time you'll call
it.

A workaround is to make a reference-listener instead of a direct reference,
so that unbind then bind hooks will be called.

Regards,

2015-01-02 15:39 GMT+01:00 Ed Welch <ed...@edjusted.com>:

> 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 issue.
>
> 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?
>
> Thanks!
>
> Ed Welch




-- 
Charlie Mordant

Full OSGI/EE stack made with Karaf:
https://github.com/OsgiliathEnterprise/net.osgiliath.parent