camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoni Myłka <>
Subject Re: direct-vm in OSGI
Date Wed, 06 Mar 2013 09:44:47 GMT
2013/3/6 Guillaume Nodet <>:
> On Wed, Mar 6, 2013 at 2:17 AM, Raúl Kripalani <> wrote:
>> Blueprint starts bundles asynchronously, which leads to the start level
>> not being honoured in most cases. And if it is honoured, it's by fluke and
>> not by design.
>> Aries Blueprint 0.4 introduces an option to make bundles start
>> synchronously [1] & [2], but it seems to be available only from Karaf 3.0.0
>> onwards.
> This is available in 2.3.x too fwiw.

Great! So a short-term workaround would be to upgrade from 2.2.9 to
2.3.1 and include the
in etc/

This is still not a real solution though.

>> Good news is that Spring DM *does* offer a way to make your bundles start
>> synchronously, thus honouring the start level. You need to add a
>> Spring-Context header to your OSGi MANIFEST, with the option
>> create-asynchronously=false. See [3] for more info. In practice, this
>> approach has worked nicely for me in extraordinary cases where observing
>> the start-level was critical.
>> Does that help?
> Another way would be to use OSGi services in order to make sure the route
> is not started before the other bundle is ready.
> This may need to be improved, and we could have the VM  component not fail
> in such a case, though the risk is really not keep  messages and run OOM.

First of all thanks very much for the responses, Let me summarize.

AFAIU I have the following options:

1. Use
OK but the doc makes no mention of the grace period. Moreover that
project seems dormant and it's part of the "official" distribution.

2. Use NMR:
I'd like a fully synchronous call with grace period. AFAIU NMR is
asynchronous by default. The 'synchronous' parameter can only be made
on the consumer URI. Does this mean that the same thread will push the
message from one bundle to the other?

3. Hack with camel-osgi
On the consumer side use
On the producer side use
<reference id="someId"
   filter="(endpointName=coolEndpoint)" />
and then in the bundle
<bean ref="someId" />

Seems OK - pushes the message from one bundle to another, uses the
grace period. The route I'm calling does a little transformation and
returns the message back - that's what I need (hence <bean> and not
<to>.) Is this likely to work? What about the Exchange.getContext()
method - an exchange is tied to a concrete context, isn't it?
direct-vm doesn't do anything with this, so perhaps it's not much of a

Antoni Myłka

View raw message