s message in context:
> http://camel.465427.n5.nabble.com/direct-vm-in-OSGI-how-to-handle-context-updates-tp5759259p5759438.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-
Red Hat, Inc.
Email: cib...@redhat.com
Twitter: davs
istry that does the wiring when it is needed.
Regards,
Thomas
--
View this message in context:
http://camel.465427.n5.nabble.com/direct-vm-in-OSGI-how-to-handle-context-updates-tp5759259p5759438.html
Sent from the Camel - Users mailing list archive at Nabble.com.
of
> the consumer is not forcing the producers to refresh as well. What do you
> think?
> Regards,
> Thomas
>
>
>
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/direct-vm-in-OSGI-how-to-handle-context-updates-tp57592
f the contexts
are ‘chained’ like in my example.
I suggest changing the behavior of the direct-vm component that a refresh of
the consumer is not forcing the producers to refresh as well. What do you
think?
Regards,
Thomas
--
View this message in context:
http://camel.465427.n5.nabble.com/direct-
is message in context:
> http://camel.465427.n5.nabble.com/direct-vm-in-OSGI-how-to-handle-context-updates-tp5759259p5759266.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-
Red Hat, Inc.
Email: cib...@redhat.com
Twitter: davsclaus
Blog
the files dynamically.
Regards,
Thomas
--
View this message in context:
http://camel.465427.n5.nabble.com/direct-vm-in-OSGI-how-to-handle-context-updates-tp5759259p5759266.html
Sent from the Camel - Users mailing list archive at Nabble.com.
ge one of the files...your lost ;)
>
> Any idea how I can handle updates on direct-vm 'chained' context/routes?
>
> Regards,
> Thomas
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/direct-vm-in-OSGI-how-to-handle-context-upda
one of the files...your lost ;)
Any idea how I can handle updates on direct-vm 'chained' context/routes?
Regards,
Thomas
--
View this message in context:
http://camel.465427.n5.nabble.com/direct-vm-in-OSGI-how-to-handle-context-updates-tp5759259.html
Sent from the Camel - Users mai
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 optio
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
> synchron
Thx for the response Raul.
If that does not work, the alternative is to use the transversal camel-NMR
component which is an OSGI service and will avoid that kind of issue.
Exchanges will be asynchronous by default. Even if you can turn out the
endpoint to synchronize the exchanges, this component s
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
Hi,
I've been investigating an issue in our application. It works on Karaf,
uses Blueprint and has a number of bundles that start Camel contexts. We
use direct-vm endpoints to send messages between contexts residing in
different bundles and use karaf start levels to enforce startup ordering.
13 matches
Mail list logo
