Here is the link to the component: https://github.com/szhem/camel-osgi
> 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
>> <[email protected]> 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"<[email protected]>
>>>> 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
>>>>>> <[email protected]> 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:[email protected]
