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)) -
On Fri, Jun 22, 2012 at 10:41 PM, Sergey Zhemzhitsky szh.s...@gmail.com 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
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 6:33 AM, Sergey Zhemzhitsky szh.s...@gmail.com 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:
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 szh.s...@gmail.com
wrote:
Hello, guys,
I agree that if the camel-core could be enhanced to
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
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.
+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
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
ch...@die-schneider.net wrote:
+1
I like that aproach. It would make the OSGi services component a lot
simpler.
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
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
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
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
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
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
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
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
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
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
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
On Wed, May 30, 2012 at 8:41 PM, Sergey Zhemzhitsky szh.s...@gmail.com 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
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 szh.s...@gmail.com
wrote:
Hi Claus,
The component
On Tue, May 22, 2012 at 7:57 PM, szh.s...@gmail.com 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 -
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
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,
references are perfect if you have a
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:
What exactly are you trying to achieve? You just want to try to talk
to OSGi services? Can't you just do that with references and
beanRef?
On Tue, May 22, 2012 at 1:57 PM, szh.s...@gmail.com wrote:
Hi gurus,
Recently I've published camel component that uses OSGi services to
communicate
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
ja...@carmanconsulting.com 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
Do you use Blueprint?
On Wed, May 23, 2012 at 11:24 AM, Donald Whytock dwhyt...@gmail.com 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
ja...@carmanconsulting.com wrote:
What exactly are you
Hi James,
references 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
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
31 matches
Mail list logo
