We can discuss some ideas at ApacheCon EU (I will be there). But we have to
make sure we share the content of our discussion afterwards here at this
list.
Looking forward to meeting you there...
Best,
Christian
Sent from a mobile device
Am 25.10.2012 15:55 schrieb "Christian Ohr" :
> I would ne
I would never dare to subvert the Camel community - in fact that's why
I started this thread here.
Christian
2012/10/25 Rob Davies :
> +1
>
>
>
> On 25 Oct 2012, at 12:44, Hadrian Zbarcea wrote:
>
>> There will be quite a few Camel committers at ACEU. Technical discussions
>> must be inclusive
+1
On 25 Oct 2012, at 12:44, Hadrian Zbarcea wrote:
> There will be quite a few Camel committers at ACEU. Technical discussions
> must be inclusive of the community and take place on this dev@ list though.
>
> Hadrian
>
>
> On 10/25/2012 03:47 AM, Christian Ohr wrote:
>> Let me quickly sum
There will be quite a few Camel committers at ACEU. Technical
discussions must be inclusive of the community and take place on this
dev@ list though.
Hadrian
On 10/25/2012 03:47 AM, Christian Ohr wrote:
Let me quickly summarize -
there appears to be quite some interest from the community (a
Let me quickly summarize -
there appears to be quite some interest from the community (and
apparently a number of homegrown solutions to fill the gap) and some
plans around a Message History EIP (at the bottom of
http://camel.apache.org/camel-30-roadmap.html) for a yet unscheduled
future Camel rel
I'm +1 for this feature and wouldn't mind helping out. We've done
something very similar to this at work and would very much like for it
to be "baked in" already for us.
On Wed, Oct 24, 2012 at 9:50 AM, Claus Ibsen wrote:
> On Wed, Oct 24, 2012 at 8:46 AM, Bengt Rodehav wrote:
>> I think this
Yeah
We also need this kind of message store right now.
Our need is claim-check, history, polling consumer and with random access.
I'd thought we'd try with MongoDB, because it fits our current use
case, if no camel component fits the bill.
But it would be nice to be able to leverage an "official"
On Wed, Oct 24, 2012 at 8:46 AM, Bengt Rodehav wrote:
> I think this is an excellent idea. We're using Camel as the basis for our
> integration platform and a message store is a mandatory component. We need:
>
> - To store all message traffic in order to have an audit trail. Both
> successful and
+1 for this feature. It is very much needed. Agree with Bengt's comments.
--
View this message in context:
http://camel.465427.n5.nabble.com/DISCUSS-Message-Store-tp5721454p5721503.html
Sent from the Camel Development mailing list archive at Nabble.com.
I think this is an excellent idea. We're using Camel as the basis for our
integration platform and a message store is a mandatory component. We need:
- To store all message traffic in order to have an audit trail. Both
successful and failed exchanges.
- To provide a certain level of manual retry.
There is a lots of way to implement to Message store.
Option1. If we treat is a first class of Camel, we could build up a set of API
to let aggregator or tracer to use. As it is common usage that we need to store
the exchange persistently, It make sense to provides such kind of API in Camel
as
Hi Christian,
You are correct about the fact that a Message Store is missing (kinda).
There are a few components that support a message store implementation
of sorts, as you mentioned. You are also correct that it should be a
first class citizen.
Practically, an endpoint that supports a poll
Hi everyone,
in the past I came several times across situations that required the
one or other kind of Message Store. I noticed that in Camel this
doesn't seem to be a "first class citizen" in the sense of a primary
architectural concept, which can be applied consistently whereever
needed.
In sho
13 matches
Mail list logo
