camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Dynamic list of consumers for the same route
Date Wed, 23 May 2012 16:50:49 GMT

OSGi services can be used without even restarting the container or camel contexts.
As by spec. invocation of OSGi service happens synchronously in the same thread, so there
no problems with transactions.

You only have to publish you consumer side into the OSGi registry somehow (please, feel free
try my osgi services component, that is discussed in another thread), next you will only have
to add
new producing sides that will send messages to this published into the OSGi registry consuming

Again, with osgi services component you can achieve this in the following way:

Consuming side:

Producing side:

At any time later just deploy a bundle with another producing side


> Yeah, it might be better to just have manual restarts, since they may
> be in the middle of some db changes and the routes would be restarting
> themselves multiple times (perhaps with half-baked config).  Sounds
> like you've got it under control.  Please report back to let us know
> how things went and so other might be able to learn from this cool
> example!

> On Wed, May 23, 2012 at 10:22 AM, Christian Schneider
> <> wrote:
>> Yes .. that is what I intended to do. As the deployment is in OSGi I plan to
>> use the config admin service integration in blueprint.
>> So the bundle restarts automatically on config changes. If the config has to
>> be in DB then I think it is good enough if the admin restarts the bundle by
>> hand when
>> the db changes. Changes are typically expected when deployments change.
>> Christian
>> Am 23.05.2012 16:04, schrieb James Carman:
>>> Yeah, sorry, didn't understand what you were trying to do.  Perhaps you
>>> can
>>> programmatically stop/restart your camel context at runtime based on some
>>> sort of event (database changes?).  Then, your route builder would read
>>> the
>>> information from the database to dynamically configure your routes?
>>> On May 23, 2012 9:38 AM, "Christian Schneider"<>
>>> wrote:
>>>> Topics would not help in my case.
>>>> The use case here is to have kind of a generic engine that can route
>>>> between queues with config from a db or file.
>>>> Christian
>>>> Am 23.05.2012 15:10, schrieb James Carman:
>>>>> Are you in need of a topic rather than a queue?
>>>>> On Wed, May 23, 2012 at 8:13 AM, Christian Schneider
>>>>> <>   wrote:
>>>>>> The problem is that the from endpoints are not known at compile time
>>>>>> and
>>>>>> can
>>>>>> change at any time.
>>>>>> Besides that we need transactionality. Not sure if seda provides
>>>>>> Christian
>>>>>> Am 23.05.2012 13:41, schrieb Serkan Eryilmaz:
>>>>>>> Couldn't you just create a seda queue once (that is your logic
>>>>>>> and
>>>>>>> then for each jms queue that gets added you redirect it to that
>>>>>>> queue ?
>>>>>>> On 05/23/2012 01:03 PM, Christian Schneider wrote:
>>>>>>>> I would like to listen to a list of jms queues and for each
queue do
>>>>>>>> the
>>>>>>>> same route.
>>>>>>>> Currently I use a RouteBuilder that gets the jms endpoint
uri in its
>>>>>>>> constructor and builds the route. This routebuilder is then
>>>>>>>> once for
>>>>>>>> each jms endpoint and the
>>>>>>>> route is added each time to the context. This works but I
wonder if
>>>>>>>> we
>>>>>>>> can do this in a generic way. For the producer side we have
>>>>>>>> recipientlist where you can give it a list of endpoints to
send to.
>>>>>>>> How about a component that can create consumers from a list
of uris
>>>>>>>> separated by comma? Would there be a general interest in
such a
>>>>>>>> thing?
>>>>>>>> Do we
>>>>>>>> perhaps have a similar thing that I just overlooked?
>>>>>>>> Christian
>>>>>> --
>>>>>> Christian Schneider
>>>>>> Open Source Architect
>>>>>> Talend Application Integration Division
>>>> --
>>>> Christian Schneider
>>>> Open Source Architect
>>>> Talend Application Integration Division
>> --
>> Christian Schneider
>> Open Source Architect
>> Talend Application Integration Division

Best regards,

View raw message