Hi guys,
I like the idea with URIs like that
"direct-vm:/endpoint/topicName/subTopicName/subSubTopicName?params".
So as Guillaume said the recipient list can be retrieved using something like
xpath or even ant-style expressions
recipientList(directVm("/endpoint/*/subTopicName/subSubTopicName"))
Yes, or something even more flexible such as
to("direct-vm:/parent/child")
and for the expression, a simple xpath like:
from("foo:bar").recipientList(directVm("/parent/*"))
or
/parent//*
Just a thought though, not sure if that's really needed.
On Sat, Jun 23, 2012 at 9:18 AM, Claus Ibsen
On Fri, Jun 22, 2012 at 10:41 PM, Sergey Zhemzhitsky wrote:
> Hello Guillaume,
>
> I suppose static method to retrieve consumers that can be filtered by a custom
> expression will be quite enough.
>
Yeah that may be a good idea and fairly easy to implement.
The regular direct component could in
Hello Guillaume,
I suppose static method to retrieve consumers that can be filtered by a custom
expression will be quite enough.
Regards,
Sergey
> On Fri, Jun 22, 2012 at 6:33 AM, Sergey Zhemzhitsky
> wrote:
>> Hello, guys,
>>
>> I agree that if the camel-core could be enhanced to achieve eas
On Fri, Jun 22, 2012 at 6:33 AM, Sergey Zhemzhitsky wrote:
> Hello, guys,
>
> I agree that if the camel-core could be enhanced to achieve easy cross-context
> communication in the single JVM it would be fine.
Claus committed the direct-vm component recently which is part of 2.10:
http://camel.
Hello, guys,
I agree that if the camel-core could be enhanced to achieve easy cross-context
communication in the single JVM it would be fine.
In that case I would not tire the core to OSGi anyhow to be really
environment-independent.
I suppose that camel context could be published into the JNDI
Agree, I think that enhancing the existing could achieve this.
Regards
JB
On 06/21/2012 08:51 AM, Guillaume Nodet wrote:
That's really my main goal. If we fit into what already exists more,
we'll be able to better leverage everything.
On Thu, Jun 21, 2012 at 8:48 AM, Christian Schneider
wro
That's really my main goal. If we fit into what already exists more,
we'll be able to better leverage everything.
On Thu, Jun 21, 2012 at 8:48 AM, Christian Schneider
wrote:
> +1
>
> I like that aproach. It would make the OSGi services component a lot
> simpler.
>
>
> from("foo:bar").recipientLi
+1
I like that aproach. It would make the OSGi services component a lot simpler.
from("foo:bar").recipientList(osgiServices("myldapfilter"))
I guess we can use a similar aproach to achieve load balancing. Not sure if the
example below already would work but I am sure we could make it work this
Sergey,
I agree on Guillaume remark. We should improve what we have in camel
project instead of creating a new component. There is a new one "direct-vm"
which has been created in camel 2.10 (camel-core) to support communication
over camelContext when the camel routes runs in the same JVM. Personal
Yeah, and I agree leveraging OSGi services for that is a good idea.
That's not really what I'm concerned about.
The goal is to have a way to multicast a message to a set of endpoint
which will be discovered at runtime, and that's not really OSGi
specific (though the fact that OSGi has a service re
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
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 analog
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 sta
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 compon
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 S
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 suitab
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-use
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 als
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 ter
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
> wrote:
>> Hi Claus,
>>
>> The component can be u
On Wed, May 30, 2012 at 8:41 PM, Sergey Zhemzhitsky 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 i
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 produce
On Tue, May 22, 2012 at 7:57 PM, 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.apach
Hello Michael,
To call the listeners asynchronously you can use the following uri:
osgi:multicast:myEndpoint?parallelProcessing=true. Here is some docs
aboutpredefinedparametersfor osgi:multicast producers:
https://github.com/szhem/camel-osgi#multicasting-to-multiple-osgi-bund
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, szh.s...@gmail.com wrote:
Hi James,
s are perfect if you have a single processo
Hi James,
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
Do you use Blueprint?
On Wed, May 23, 2012 at 11:24 AM, Donald Whytock 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
> wrote:
>> What exactly are you trying to achieve? You just want to
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
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 s and
> beanRef?
>
> On Tue, May
What exactly are you trying to achieve? You just want to try to talk
to OSGi services? Can't you just do that with s and
beanRef?
On Tue, May 22, 2012 at 1:57 PM, wrote:
> Hi gurus,
>
> Recently I've published camel component that uses OSGi services to
> communicate between endpoints in di
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 f
31 matches
Mail list logo
