Camel OSGi services component

[szh.subs]

Hi gurus,

Recently  I've  published  camel  component that uses OSGi services to
communicate between endpoints in different bundles.

Here is the link: https://github.com/szhem/camel-osgi
I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292

So I'd like to have some feedback if it seems to be useful.

Regards,
Sergey

[James Carman]

What exactly are you trying to achieve?  You just want to try to talk
to OSGi services?  Can't you just do that with <reference>s and
beanRef?

On Tue, May 22, 2012 at 1:57 PM,  <[hidden email]> wrote:

> Hi gurus,
>
> Recently  I've  published  camel  component that uses OSGi services to
> communicate between endpoints in different bundles.
>
> Here is the link: https://github.com/szhem/camel-osgi
> I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292
>
> So I'd like to have some feedback if it seems to be useful.
>
> Regards,
> Sergey
>
>

[Donald Whytock]

There are some, myself included, who, for whatever reason, don't use
Spring or Karaf.

Don

On Tue, May 22, 2012 at 3:19 PM, James Carman
<[hidden email]> wrote:

> What exactly are you trying to achieve?  You just want to try to talk
> to OSGi services?  Can't you just do that with <reference>s and
> beanRef?
>
> On Tue, May 22, 2012 at 1:57 PM,  <[hidden email]> wrote:
>> Hi gurus,
>>
>> Recently  I've  published  camel  component that uses OSGi services to
>> communicate between endpoints in different bundles.
>>
>> Here is the link: https://github.com/szhem/camel-osgi
>> I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292
>>
>> So I'd like to have some feedback if it seems to be useful.
>>
>> Regards,
>> Sergey
>>
>>

[James Carman]

Do you use Blueprint?

On Wed, May 23, 2012 at 11:24 AM, Donald Whytock <[hidden email]> wrote:

> There are some, myself included, who, for whatever reason, don't use
> Spring or Karaf.
>
> Don
>
> On Tue, May 22, 2012 at 3:19 PM, James Carman
> <[hidden email]> wrote:
>> What exactly are you trying to achieve?  You just want to try to talk
>> to OSGi services?  Can't you just do that with <reference>s and
>> beanRef?
>>
>> On Tue, May 22, 2012 at 1:57 PM,  <[hidden email]> wrote:
>>> Hi gurus,
>>>
>>> Recently  I've  published  camel  component that uses OSGi services to
>>> communicate between endpoints in different bundles.
>>>
>>> Here is the link: https://github.com/szhem/camel-osgi
>>> I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292
>>>
>>> So I'd like to have some feedback if it seems to be useful.
>>>
>>> Regards,
>>> Sergey
>>>
>>>

[szh.subs]

Hi James,

<reference>s are perfect if you have a single processor, if you have more than one processor that may come and go you
will have to write custom code to publish to all of these processors.

The main goal I was trying to achieve is to send an exchange to multiple osgi endpoints and to load balance between multiple
osgi endpoints which can be published at any time, so their URIs are not known at the deployment time.

The simple example is publishing messages to multiple systems.

Here is the route in the producing bundle:

from("direct:start").to("osgi:multicast:consumer")

In the consuming bundle 1 you declare the route to process the exchange like this

from("osgi:consumer").process(processorA);

If after the time you would like to subscribe the bundle B to the same exchanges, the only thing you have to do is to
deploy another bundle with route like this:

from("osgi:consumer").process(processorB);

Of course you can use jms topics or something like this but I suppose osgi component is more lightweight and does not involve
additional software. Moreover jms does not support aggregation strategies so you will have to complicate your route
with aggregate eip. For multicasting to multiple bundles you can also involve "vm" endpoints, but they don't support
synchronous multicasting, aggregation strategies, stopping on failures, etc.



> What exactly are you trying to achieve?  You just want to try to talk
> to OSGi services?  Can't you just do that with <reference>s and
> beanRef?

> On Tue, May 22, 2012 at 1:57 PM,  <[hidden email]> wrote:
>> Hi gurus,
>>
>> Recently  I've  published  camel  component that uses OSGi services to
>> communicate between endpoints in different bundles.
>>
>> Here is the link: https://github.com/szhem/camel-osgi
>> I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292
>>
>> So I'd like to have some feedback if it seems to be useful.
>>
>> Regards,
>> Sergey
>>
>>

--
Best regards,
 szh                            mailto:[hidden email]

[Michael Süess]

Hi


very cool component to implement the observer pattern in camel blueprint....


just a small question: how can i have a async calling of the listeners?
(mutlicast is sync per definition)?


On 23.05.2012 18:29, [hidden email] wrote:

> Hi James,
>
> <reference>s are perfect if you have a single processor, if you have more than one processor that may come and go you
> will have to write custom code to publish to all of these processors.
>
> The main goal I was trying to achieve is to send an exchange to multiple osgi endpoints and to load balance between multiple
> osgi endpoints which can be published at any time, so their URIs are not known at the deployment time.
>
> The simple example is publishing messages to multiple systems.
>
> Here is the route in the producing bundle:
>
> from("direct:start").to("osgi:multicast:consumer")
>
> In the consuming bundle 1 you declare the route to process the exchange like this
>
> from("osgi:consumer").process(processorA);
>
> If after the time you would like to subscribe the bundle B to the same exchanges, the only thing you have to do is to
> deploy another bundle with route like this:
>
> from("osgi:consumer").process(processorB);
>
> Of course you can use jms topics or something like this but I suppose osgi component is more lightweight and does not involve
> additional software. Moreover jms does not support aggregation strategies so you will have to complicate your route
> with aggregate eip. For multicasting to multiple bundles you can also involve "vm" endpoints, but they don't support
> synchronous multicasting, aggregation strategies, stopping on failures, etc.
>
>
>
>> What exactly are you trying to achieve?  You just want to try to talk
>> to OSGi services?  Can't you just do that with<reference>s and
>> beanRef?
>
>> On Tue, May 22, 2012 at 1:57 PM,<[hidden email]>  wrote:
>>> Hi gurus,
>>>
>>> Recently  I've  published  camel  component that uses OSGi services to
>>> communicate between endpoints in different bundles.
>>>
>>> Here is the link: https://github.com/szhem/camel-osgi
>>> I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292
>>>
>>> So I'd like to have some feedback if it seems to be useful.
>>>
>>> Regards,
>>> Sergey
>>>
>>>
>
>
>

--
Michael Sueess                           Senior Software Engineer

basis06 AG, Birkenweg 61, CH-3013 Bern - Fon [phone]
http://www.basis06.ch - source of smart business

Keine News verpassen? http://www.basis06.ch/newsletter-registration.html
Schon gebloggt? http://blog.basis06.ch

[szh.subs]

Hello Michael,

To  call  the  listeners asynchronously you can use the following uri:
osgi:multicast:myEndpoint?parallelProcessing=true.  Here  is some docs
about    predefined    parameters    for   osgi:multicast   producers:
https://github.com/szhem/camel-osgi#multicasting-to-multiple-osgi-bundles.
Note  that  the  caller  thread will still wait until all messages has
been processed, as this is the behavior of the MulticastProcessor that
is   used  internally.  I  suppose  that  support  of  fire-and-forget
behavior (i.e. one-way sending) may be pretty useful.
The   parameters   are   almost   identical   to  multicast  eip  ones
(http://camel.apache.org/multicast.html#Multicast-Options)

Regards,
Sergey



> Hi


> very cool component to implement the observer pattern in camel blueprint....


> just a small question: how can i have a async calling of the listeners?
> (mutlicast is sync per definition)?

> On 23.05.2012 18:29, [hidden email] wrote:
>> Hi James,
>>
>> <reference>s are perfect if you have a single processor, if you have more than one processor that may come and go you
>> will have to write custom code to publish to all of these processors.
>>
>> The main goal I was trying to achieve is to send an exchange to multiple osgi endpoints and to load balance between multiple
>> osgi endpoints which can be published at any time, so their URIs are not known at the deployment time.
>>
>> The simple example is publishing messages to multiple systems.
>>
>> Here is the route in the producing bundle:
>>
>> from("direct:start").to("osgi:multicast:consumer")
>>
>> In the consuming bundle 1 you declare the route to process the exchange like this
>>
>> from("osgi:consumer").process(processorA);
>>
>> If after the time you would like to subscribe the bundle B to the same exchanges, the only thing you have to do is to
>> deploy another bundle with route like this:
>>
>> from("osgi:consumer").process(processorB);
>>
>> Of course you can use jms topics or something like this but I suppose osgi component is more lightweight and does not involve
>> additional software. Moreover jms does not support aggregation strategies so you will have to complicate your route
>> with aggregate eip. For multicasting to multiple bundles you can also involve "vm" endpoints, but they don't support
>> synchronous multicasting, aggregation strategies, stopping on failures, etc.
>>
>>
>>
>>> What exactly are you trying to achieve?  You just want to try to talk
>>> to OSGi services?  Can't you just do that with<reference>s and
>>> beanRef?
>>
>>> On Tue, May 22, 2012 at 1:57 PM,<[hidden email]>  wrote:
>>>> Hi gurus,
>>>>
>>>> Recently  I've  published  camel  component that uses OSGi services to
>>>> communicate between endpoints in different bundles.
>>>>
>>>> Here is the link: https://github.com/szhem/camel-osgi
>>>> I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292
>>>>
>>>> So I'd like to have some feedback if it seems to be useful.
>>>>
>>>> Regards,
>>>> Sergey
>>>>
>>>>
>>
>>
>>

[Claus Ibsen-2]

On Tue, May 22, 2012 at 7:57 PM,  <[hidden email]> wrote:

> Hi gurus,
>
> Recently  I've  published  camel  component that uses OSGi services to
> communicate between endpoints in different bundles.
>
> Here is the link: https://github.com/szhem/camel-osgi
> I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292
>
> So I'd like to have some feedback if it seems to be useful.
>
> Regards,
> Sergey
>
>

Sergey at first glance this seem really useful. Good work.
Is there any missing functionality / features / tests etc?




--
Claus Ibsen
-----------------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

[szh.subs]

Hi Claus,

The  component  can  be  used right now without any additions, but I'd
like to include some integration tests which will check that:

1. Any camel processor (even not included into the camel route) can be
published into the OSGi service registry to process exchanges.

2. Multiple producers can send exchanges to one/many consumers.

Everything  should  work out of the box, but the samples can be rather
useful.

Also  I'd  like  to  update  docs with the samples based on the points
above.

One more interesting thing is investigating into whether the component
can be integrated with DOSGi easily, but I suppose it can be postponed
a little bit as it's not very important, but rather useful feature.

Regards,
Sergey

> On Tue, May 22, 2012 at 7:57 PM,  <[hidden email]> wrote:
>> Hi gurus,
>>
>> Recently  I've  published  camel  component that uses OSGi services to
>> communicate between endpoints in different bundles.
>>
>> Here is the link: https://github.com/szhem/camel-osgi
>> I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292
>>
>> So I'd like to have some feedback if it seems to be useful.
>>
>> Regards,
>> Sergey
>>
>>

> Sergey at first glance this seem really useful. Good work.
> Is there any missing functionality / features / tests etc?

[Claus Ibsen-2]

On Wed, May 30, 2012 at 8:41 PM, Sergey Zhemzhitsky <[hidden email]> wrote:

> Hi Claus,
>
> The  component  can  be  used right now without any additions, but I'd
> like to include some integration tests which will check that:
>
> 1. Any camel processor (even not included into the camel route) can be
> published into the OSGi service registry to process exchanges.
>
> 2. Multiple producers can send exchanges to one/many consumers.
>
> Everything  should  work out of the box, but the samples can be rather
> useful.
>
> Also  I'd  like  to  update  docs with the samples based on the points
> above.
>
> One more interesting thing is investigating into whether the component
> can be integrated with DOSGi easily, but I suppose it can be postponed
> a little bit as it's not very important, but rather useful feature.
>

Yeah I suggest to get those pieces implemented first.

DOSGi can come later.
For example CXF supports DOSGi, as well Fuse Fabric.

> Regards,
> Sergey
>
>> On Tue, May 22, 2012 at 7:57 PM,  <[hidden email]> wrote:
>>> Hi gurus,
>>>
>>> Recently  I've  published  camel  component that uses OSGi services to
>>> communicate between endpoints in different bundles.
>>>
>>> Here is the link: https://github.com/szhem/camel-osgi
>>> I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292
>>>
>>> So I'd like to have some feedback if it seems to be useful.
>>>
>>> Regards,
>>> Sergey
>>>
>>>
>
>> Sergey at first glance this seem really useful. Good work.
>> Is there any missing functionality / features / tests etc?
>

--
Claus Ibsen
-----------------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

[szh.subs]

Hi Claus,

Recently docs and integration tests of the component have been updated.
I suppose it's ready for now and all missing pieces and features can be added later.


Regards,
Sergey

> On Wed, May 30, 2012 at 8:41 PM, Sergey Zhemzhitsky <[hidden email]> wrote:
>> Hi Claus,
>>
>> The  component  can  be  used right now without any additions, but I'd
>> like to include some integration tests which will check that:
>>
>> 1. Any camel processor (even not included into the camel route) can be
>> published into the OSGi service registry to process exchanges.
>>
>> 2. Multiple producers can send exchanges to one/many consumers.
>>
>> Everything  should  work out of the box, but the samples can be rather
>> useful.
>>
>> Also  I'd  like  to  update  docs with the samples based on the points
>> above.
>>
>> One more interesting thing is investigating into whether the component
>> can be integrated with DOSGi easily, but I suppose it can be postponed
>> a little bit as it's not very important, but rather useful feature.
>>

> Yeah I suggest to get those pieces implemented first.

> DOSGi can come later.
> For example CXF supports DOSGi, as well Fuse Fabric.

>> Regards,
>> Sergey
>>
>>> On Tue, May 22, 2012 at 7:57 PM,  <[hidden email]> wrote:
>>>> Hi gurus,
>>>>
>>>> Recently  I've  published  camel  component that uses OSGi services to
>>>> communicate between endpoints in different bundles.
>>>>
>>>> Here is the link: https://github.com/szhem/camel-osgi
>>>> I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292
>>>>
>>>> So I'd like to have some feedback if it seems to be useful.
>>>>
>>>> Regards,
>>>> Sergey
>>>>
>>>>
>>
>>> Sergey at first glance this seem really useful. Good work.
>>> Is there any missing functionality / features / tests etc?
>>

[Claus Ibsen-2]

Hi

We are in the process of getting Camel 2.10 done and released.

Your component looks interesting but I would like more time to look
into it, and also for the SMX / Karaf team to take a look at was, as
its OSGi based.
And I wonder if the scheme name of osgi is a good name, as osgi is a broad term?

We can surely introduce this component in a patch release of 2.10 if
there is no changes to the camel-core.
And also at 2.11. But if all is well, then I dont see an issue to
introduce it in 2.10.1. We have done this in the past adding new
components to a patch release.



On Sat, Jun 2, 2012 at 6:37 PM, Sergey Zhemzhitsky <[hidden email]> wrote:

> Hi Claus,
>
> Recently docs and integration tests of the component have been updated.
> I suppose it's ready for now and all missing pieces and features can be added later.
>
>
> Regards,
> Sergey
>
>
>> On Wed, May 30, 2012 at 8:41 PM, Sergey Zhemzhitsky <[hidden email]> wrote:
>>> Hi Claus,
>>>
>>> The  component  can  be  used right now without any additions, but I'd
>>> like to include some integration tests which will check that:
>>>
>>> 1. Any camel processor (even not included into the camel route) can be
>>> published into the OSGi service registry to process exchanges.
>>>
>>> 2. Multiple producers can send exchanges to one/many consumers.
>>>
>>> Everything  should  work out of the box, but the samples can be rather
>>> useful.
>>>
>>> Also  I'd  like  to  update  docs with the samples based on the points
>>> above.
>>>
>>> One more interesting thing is investigating into whether the component
>>> can be integrated with DOSGi easily, but I suppose it can be postponed
>>> a little bit as it's not very important, but rather useful feature.
>>>
>
>> Yeah I suggest to get those pieces implemented first.
>
>> DOSGi can come later.
>> For example CXF supports DOSGi, as well Fuse Fabric.
>
>
>
>>> Regards,
>>> Sergey
>>>
>>>> On Tue, May 22, 2012 at 7:57 PM,  <[hidden email]> wrote:
>>>>> Hi gurus,
>>>>>
>>>>> Recently  I've  published  camel  component that uses OSGi services to
>>>>> communicate between endpoints in different bundles.
>>>>>
>>>>> Here is the link: https://github.com/szhem/camel-osgi
>>>>> I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292
>>>>>
>>>>> So I'd like to have some feedback if it seems to be useful.
>>>>>
>>>>> Regards,
>>>>> Sergey
>>>>>
>>>>>
>>>
>>>> Sergey at first glance this seem really useful. Good work.
>>>> Is there any missing functionality / features / tests etc?
>>>
>

--
Claus Ibsen
-----------------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

[Jean-Baptiste Onofré]

Hi guys,

I will take a look. Agree with you that osgi name is not the best name.

Thanks
Regards
JB

On 06/07/2012 09:32 AM, Claus Ibsen wrote:

> Hi
>
> We are in the process of getting Camel 2.10 done and released.
>
> Your component looks interesting but I would like more time to look
> into it, and also for the SMX / Karaf team to take a look at was, as
> its OSGi based.
> And I wonder if the scheme name of osgi is a good name, as osgi is a broad term?
>
> We can surely introduce this component in a patch release of 2.10 if
> there is no changes to the camel-core.
> And also at 2.11. But if all is well, then I dont see an issue to
> introduce it in 2.10.1. We have done this in the past adding new
> components to a patch release.
>
>
>
> On Sat, Jun 2, 2012 at 6:37 PM, Sergey Zhemzhitsky<[hidden email]>  wrote:
>> Hi Claus,
>>
>> Recently docs and integration tests of the component have been updated.
>> I suppose it's ready for now and all missing pieces and features can be added later.
>>
>>
>> Regards,
>> Sergey
>>
>>
>>> On Wed, May 30, 2012 at 8:41 PM, Sergey Zhemzhitsky<[hidden email]>  wrote:
>>>> Hi Claus,
>>>>
>>>> The  component  can  be  used right now without any additions, but I'd
>>>> like to include some integration tests which will check that:
>>>>
>>>> 1. Any camel processor (even not included into the camel route) can be
>>>> published into the OSGi service registry to process exchanges.
>>>>
>>>> 2. Multiple producers can send exchanges to one/many consumers.
>>>>
>>>> Everything  should  work out of the box, but the samples can be rather
>>>> useful.
>>>>
>>>> Also  I'd  like  to  update  docs with the samples based on the points
>>>> above.
>>>>
>>>> One more interesting thing is investigating into whether the component
>>>> can be integrated with DOSGi easily, but I suppose it can be postponed
>>>> a little bit as it's not very important, but rather useful feature.
>>>>
>>
>>> Yeah I suggest to get those pieces implemented first.
>>
>>> DOSGi can come later.
>>> For example CXF supports DOSGi, as well Fuse Fabric.
>>
>>
>>
>>>> Regards,
>>>> Sergey
>>>>
>>>>> On Tue, May 22, 2012 at 7:57 PM,<[hidden email]>  wrote:
>>>>>> Hi gurus,
>>>>>>
>>>>>> Recently  I've  published  camel  component that uses OSGi services to
>>>>>> communicate between endpoints in different bundles.
>>>>>>
>>>>>> Here is the link: https://github.com/szhem/camel-osgi
>>>>>> I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292
>>>>>>
>>>>>> So I'd like to have some feedback if it seems to be useful.
>>>>>>
>>>>>> Regards,
>>>>>> Sergey
>>>>>>
>>>>>>
>>>>
>>>>> Sergey at first glance this seem really useful. Good work.
>>>>> Is there any missing functionality / features / tests etc?
>>>>
>>
>
>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com

[szh.subs]

Hello everybody,

Thanks for considering the component.

>> osgi name is not the best name
I suppose the name should be short, should prevent misunderstandings about the environment where it can be used,
possibly it should describe what the component is supposed to do.

Although osgi is widely-used term, it seems to be ok in the context of a camel components in my opinion.

Among the possible alternatives like dynamic-service, service, osgi, osgi-service, whiteboard, osgi-whiteboard, etc.,
I would give the first place to osgi (for brevity) and the second - to osgi-service (for descriptiveness).

If you have any other ideas of how the component should be named, please share them.

Regards,
Sergey

> Hi guys,

> I will take a look. Agree with you that osgi name is not the best name.

> Thanks
> Regards
> JB

> On 06/07/2012 09:32 AM, Claus Ibsen wrote:
>> Hi
>>
>> We are in the process of getting Camel 2.10 done and released.
>>
>> Your component looks interesting but I would like more time to look
>> into it, and also for the SMX / Karaf team to take a look at was, as
>> its OSGi based.
>> And I wonder if the scheme name of osgi is a good name, as osgi is a broad term?
>>
>> We can surely introduce this component in a patch release of 2.10 if
>> there is no changes to the camel-core.
>> And also at 2.11. But if all is well, then I dont see an issue to
>> introduce it in 2.10.1. We have done this in the past adding new
>> components to a patch release.
>>
>>
>>
>> On Sat, Jun 2, 2012 at 6:37 PM, Sergey Zhemzhitsky<[hidden email]>  wrote:
>>> Hi Claus,
>>>
>>> Recently docs and integration tests of the component have been updated.
>>> I suppose it's ready for now and all missing pieces and features can be added later.
>>>
>>>
>>> Regards,
>>> Sergey
>>>
>>>
>>>> On Wed, May 30, 2012 at 8:41 PM, Sergey Zhemzhitsky<[hidden email]>  wrote:
>>>>> Hi Claus,
>>>>>
>>>>> The  component  can  be  used right now without any additions, but I'd
>>>>> like to include some integration tests which will check that:
>>>>>
>>>>> 1. Any camel processor (even not included into the camel route) can be
>>>>> published into the OSGi service registry to process exchanges.
>>>>>
>>>>> 2. Multiple producers can send exchanges to one/many consumers.
>>>>>
>>>>> Everything  should  work out of the box, but the samples can be rather
>>>>> useful.
>>>>>
>>>>> Also  I'd  like  to  update  docs with the samples based on the points
>>>>> above.
>>>>>
>>>>> One more interesting thing is investigating into whether the component
>>>>> can be integrated with DOSGi easily, but I suppose it can be postponed
>>>>> a little bit as it's not very important, but rather useful feature.
>>>>>
>>>
>>>> Yeah I suggest to get those pieces implemented first.
>>>
>>>> DOSGi can come later.
>>>> For example CXF supports DOSGi, as well Fuse Fabric.
>>>
>>>
>>>
>>>>> Regards,
>>>>> Sergey
>>>>>
>>>>>> On Tue, May 22, 2012 at 7:57 PM,<[hidden email]>  wrote:
>>>>>>> Hi gurus,
>>>>>>>
>>>>>>> Recently  I've  published  camel  component that uses OSGi services to
>>>>>>> communicate between endpoints in different bundles.
>>>>>>>
>>>>>>> Here is the link: https://github.com/szhem/camel-osgi
>>>>>>> I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292
>>>>>>>
>>>>>>> So I'd like to have some feedback if it seems to be useful.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Sergey
>>>>>>>
>>>>>>>
>>>>>
>>>>>> Sergey at first glance this seem really useful. Good work.
>>>>>> Is there any missing functionality / features / tests etc?
>>>>>
>>>
>>
>>
>>

[Christian Schneider]

Hi Sergey,

the component looks pretty good already. There is one thing though I
would like to discuss.

More or less the core of this component is the OSGi service we use to
communicate between the bundles. You currently use the camel Processor
interface for this.

While this is quite suitable for pure camel to camel communication I
wonder if we could come up with an interface that is not tied to camel.
The Processor interfaces indirectly references a lot of the camel core
code. I wonder if we could design a simple self contained interface that
would also be reuseable for other projects to do a generic communication
with camel.

Christian


Am 22.05.2012 19:57, schrieb [hidden email]:

> Hi gurus,
>
> Recently  I've  published  camel  component that uses OSGi services to
> communicate between endpoints in different bundles.
>
> Here is the link: https://github.com/szhem/camel-osgi
> I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292
>
> So I'd like to have some feedback if it seems to be useful.
>
> Regards,
> Sergey
>
>

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

[Charles Moulliard]

Excellent remark Christian.

I have also another concern regrading to the component which is :  "Does it
support TX propagation with or without Spring ?"

https://issues.apache.org/jira/browse/CAMEL-5368
https://issues.apache.org/jira/browse/CAMEL-5292

On Wed, Jun 20, 2012 at 10:36 AM, Christian Schneider <
[hidden email]> wrote:

> Hi Sergey,
>
> the component looks pretty good already. There is one thing though I would
> like to discuss.
>
> More or less the core of this component is the OSGi service we use to
> communicate between the bundles. You currently use the camel Processor
> interface for this.
>
> While this is quite suitable for pure camel to camel communication I
> wonder if we could come up with an interface that is not tied to camel. The
> Processor interfaces indirectly references a lot of the camel core code. I
> wonder if we could design a simple self contained interface that would also
> be reuseable for other projects to do a generic communication with camel.
>
> Christian
>
>
> Am 22.05.2012 19:57, schrieb [hidden email]:
>
>> Hi gurus,
>>
>> Recently  I've  published  camel  component that uses OSGi services to
>> communicate between endpoints in different bundles.
>>
>> Here is the link: https://github.com/szhem/**camel-osgi<https://github.com/szhem/camel-osgi>
>> I've already raised JIRA issue - https://issues.apache.org/**
>> jira/browse/CAMEL-5292 <https://issues.apache.org/jira/browse/CAMEL-5292>
>>
>> So I'd like to have some feedback if it seems to be useful.
>>
>> Regards,
>> Sergey
>>
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>

[Guillaume Nodet]

I'm a bit skeptic about this component.
It seems at first glance that if conflates a few things like osgi
service access, multicast, etc...
If the goal is to do inter-bundle communication, the new component
coming from CAMEL-5370 should already do that and I don't really see
the need for the component.
For the multicast, using a dynamic recipient list coupled with
direct-vm should work.

On Tue, May 22, 2012 at 7:57 PM,  <[hidden email]> wrote:

> Hi gurus,
>
> Recently  I've  published  camel  component that uses OSGi services to
> communicate between endpoints in different bundles.
>
> Here is the link: https://github.com/szhem/camel-osgi
> I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292
>
> So I'd like to have some feedback if it seems to be useful.
>
> Regards,
> Sergey
>
>

--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

[szh.subs]

Hello Charles,

The component does not contain any transaction-specific or spring-specific logic.

Handling of transactions should be done using transactional-client (http://camel.apache.org/transactional-client.html) EIP.

Basically, if you need to call the consuming bundles in a transaction started by a producing bundle, everything should
work out of the box, as OSGi guaranties that the services are invoked synchronously in the same thread.

If you have to support different propagations for different bundles, like this

from("direct:start").id("producer").transacted("PROPAGATION_REQUIRED").to("osgi:multicast:consumer");
from("osgi:consumer").id("consumer1").transacted("PROPAGATION_REQUIRES_NEW").to("mock:consumer1");
from("osgi:consumer").id("consumer2").transacted("PROPAGATION_SUPPORTS").to("mock:consumer2");

you have to export the transaction manager as OSGi service from the producing bundle, and import it in all the
consuming bundles to configure org.apache.camel.spring.spi.SpringTransactionPolicy'es properly.
Currently I'm considering to implement an integration test to show how to do that.

Regards,
Sergey

> Excellent remark Christian.

> I have also another concern regrading to the component which is :  "Does it
> support TX propagation with or without Spring ?"

> https://issues.apache.org/jira/browse/CAMEL-5368
> https://issues.apache.org/jira/browse/CAMEL-5292

> On Wed, Jun 20, 2012 at 10:36 AM, Christian Schneider <
> [hidden email]> wrote:

>> Hi Sergey,
>>
>> the component looks pretty good already. There is one thing though I would
>> like to discuss.
>>
>> More or less the core of this component is the OSGi service we use to
>> communicate between the bundles. You currently use the camel Processor
>> interface for this.
>>
>> While this is quite suitable for pure camel to camel communication I
>> wonder if we could come up with an interface that is not tied to camel. The
>> Processor interfaces indirectly references a lot of the camel core code. I
>> wonder if we could design a simple self contained interface that would also
>> be reuseable for other projects to do a generic communication with camel.
>>
>> Christian
>>
>>
>> Am 22.05.2012 19:57, schrieb [hidden email]:
>>
>>> Hi gurus,
>>>
>>> Recently  I've  published  camel  component that uses OSGi services to
>>> communicate between endpoints in different bundles.
>>>
>>> Here is the link: https://github.com/szhem/**camel-osgi<https://github.com/szhem/camel-osgi>
>>> I've already raised JIRA issue - https://issues.apache.org/**
>>> jira/browse/CAMEL-5292 <https://issues.apache.org/jira/browse/CAMEL-5292>
>>>
>>> So I'd like to have some feedback if it seems to be useful.
>>>
>>> Regards,
>>> Sergey
>>>
>>>
>>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
>>

[szh.subs]

Hello Christian,

Firstly I thought about some kind of indirect dependency on camel, but I suppose that such
an indirection will complicate the component with copying of headers, bodies, properties,
etc. from and to a camel exchange in case of duplication of camel exchange api
(lightweight analogues of camel exchanges).

The self contained interface will be provided as some kind of additional module of the component,
so there will be a dependency on the component and in my opinion there is no a big difference
between depending on the camel api or the camel component api.

What do you think about something like a bean binding (http://camel.apache.org/bean-binding.html)
from the consumer side? In that case almost any interface can be used as published OSGi service to
process exchanges.

Regards,
Sergey

> Hi Sergey,

> the component looks pretty good already. There is one thing though I
> would like to discuss.

> More or less the core of this component is the OSGi service we use to
> communicate between the bundles. You currently use the camel Processor
> interface for this.

> While this is quite suitable for pure camel to camel communication I
> wonder if we could come up with an interface that is not tied to camel.
> The Processor interfaces indirectly references a lot of the camel core
> code. I wonder if we could design a simple self contained interface that
> would also be reuseable for other projects to do a generic communication
> with camel.

> Christian

> Am 22.05.2012 19:57, schrieb [hidden email]:
>> Hi gurus,
>>
>> Recently  I've  published  camel  component that uses OSGi services to
>> communicate between endpoints in different bundles.
>>
>> Here is the link: https://github.com/szhem/camel-osgi
>> I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292
>>
>> So I'd like to have some feedback if it seems to be useful.
>>
>> Regards,
>> Sergey
>>
>>

[szh.subs]

Hi Guillaume,

Of course if there is more convenient way to communicate between
bundles there is no need in the component. On the moment of development
of this component there were multiple ways to do that, for instance:

1. jms component which is rather heavyweight to do inter-bundle communication in the same jvm.
2. vm component which is asynchronous and does not support transactions
3. nmr component which can be used in synchronous mode, but does not support pub-sub, although it
   does not prevent user from registering multiple consuming endpoints with the same name, so the
   messages are sent only to the first registered nmr-consumer.

The new direct-vm component solves the issue with transactions (like synchronous nmr does) but it does not
support pub-sub too.

To use a dynamic recipient list it's necessary to have some kind of custom code that will resolve
addresses of recipients at runtime. In such a case syncronous nmr can be used as well. The benefit of
OSGi services is that this is a standard functionality of OSGi runtime and even OSGi api predisposed
to work with an array of them. Furthermore you will get all the benefits of OSGi services, i.e.
dynamism, priorities, etc.

It would be nice if direct-vm allowed to configure pub-sub with all the options of multicast processor.

Regards,
Sergey

> I'm a bit skeptic about this component.
> It seems at first glance that if conflates a few things like osgi
> service access, multicast, etc...
> If the goal is to do inter-bundle communication, the new component
> coming from CAMEL-5370 should already do that and I don't really see
> the need for the component.
> For the multicast, using a dynamic recipient list coupled with
> direct-vm should work.

> On Tue, May 22, 2012 at 7:57 PM,  <[hidden email]> wrote:
>> Hi gurus,
>>
>> Recently  I've  published  camel  component that uses OSGi services to
>> communicate between endpoints in different bundles.
>>
>> Here is the link: https://github.com/szhem/camel-osgi
>> I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292
>>
>> So I'd like to have some feedback if it seems to be useful.
>>
>> Regards,
>> Sergey
>>
>>