Christian,
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 are
no problems with transactions.
You only have to publish you consumer side into the OSGi registry somehow
(please, feel free to
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 side.
Again, with osgi services component you can achieve this in the following way:
Consuming side:
from("osgi:jmsProcessor").to("doSomethingUseful");
Producing side:
from("jms:queue1").to("osgi:jmsProcessor");
At any time later just deploy a bundle with another producing side
from("jms:queue2").to("osgi:jmsProcessor");
Regards,
Sergey
> 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
> <ch...@die-schneider.net> 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"<ch...@die-schneider.net>
>>> 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
>>>>> <ch...@die-schneider.net> 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 that.
>>>>>> Christian
>>>>>>
>>>>>> Am 23.05.2012 13:41, schrieb Serkan Eryilmaz:
>>>>>>
>>>>>>> Couldn't you just create a seda queue once (that is your logic route),
>>>>>>> and
>>>>>>> then for each jms queue that gets added you redirect it to that seda
>>>>>>> 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 created
>>>>>>>> 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 the
>>>>>>>> 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
>>>>>> http://www.liquid-reality.de
>>>>>>
>>>>>> Open Source Architect
>>>>>> Talend Application Integration Division http://www.talend.com
>>>>>>
>>>>>>
>>>> --
>>>> Christian Schneider
>>>> http://www.liquid-reality.de
>>>>
>>>> Open Source Architect
>>>> Talend Application Integration Division http://www.talend.com
>>>>
>>>>
>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
--
Best regards,
szh mailto:szh.s...@gmail.com
