On 9/18/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> I think we should keep the seda component somehow, but change itssemantic
> (and name) so that it becomes a "in memory queue", like
> JMS without persistence and all. I think it still can be quite handy for
> unit testing, demos, etc
>
I think we should keep the seda component somehow, but change itssemantic
(and name) so that it becomes a "in memory queue", like
JMS without persistence and all. I think it still can be quite handy for
unit testing, demos, etc
Btw, if we introduce thread pools, i'm a bit worried about the e
FYI: I've opened and started to work on
http://issues.apache.org/activemq/browse/CAMEL-149
to add that .thread() method.
On 9/1/07, Brian McCallister <[EMAIL PROTECTED]> wrote:
> * Corollary -- the seda component should go away and be replaced with
> a thread pool policy. This should be done as a
On Sep 7, 2007, at 2:45 PM, Brian McCallister wrote:
Just to clarify your saying that the core components / processors
should invoke other processors using the async API, not to cause
async
processing to start occuring, but to handle the case where the
invoked component does complete the pro
On Sep 7, 2007, at 1:50 PM, Hiram Chirino wrote:
On 9/3/07, Brian McCallister <[EMAIL PROTECTED]> wrote:
On Sep 3, 2007, at 5:50 AM, James Strachan wrote:
* Async exchange handling should always be assumed.
I'm not totally sure about this one. One of the reasons JBI is so
complex to work
On 9/3/07, Brian McCallister <[EMAIL PROTECTED]> wrote:
>
> On Sep 3, 2007, at 5:50 AM, James Strachan wrote:
>
> >> * Async exchange handling should always be assumed.
> >
> > I'm not totally sure about this one. One of the reasons JBI is so
> > complex to work with is that it assumes all the hard
On 9/3/07, Brian McCallister <[EMAIL PROTECTED]> wrote:
>
> On Sep 3, 2007, at 8:33 AM, James Strachan wrote:
>
> > BTW aint it sad that still clogging / log4j / jdk 5 logging et al
> > don't do nice colour coding?
>
> Easy to add ansi escape chars in the pattern ;-)
Lets do it! :)
--
James
On Sep 3, 2007, at 8:33 AM, James Strachan wrote:
BTW aint it sad that still clogging / log4j / jdk 5 logging et al
don't do nice colour coding?
Easy to add ansi escape chars in the pattern ;-)
On 9/3/07, Brian McCallister <[EMAIL PROTECTED]> wrote:
>
> On Sep 3, 2007, at 5:50 AM, James Strachan wrote:
>
> > So there's some magic; just like there is in Rails; if you wanna grok
> > that magic, its pretty straightforward to look into (and am sure we
> > can do a better job of visualising th
On 9/3/07, Brian McCallister <[EMAIL PROTECTED]> wrote:
>
> On Sep 3, 2007, at 7:07 AM, Hadrian Zbarcea wrote:
>
> > On the CAMEL-84 topic, I think returning null is a valid normal
> > case, not an exceptional one. If a null is an acceptable answer is
> > imho for the caller to decide (which is wh
On Sep 3, 2007, at 5:50 AM, James Strachan wrote:
So there's some magic; just like there is in Rails; if you wanna grok
that magic, its pretty straightforward to look into (and am sure we
can do a better job of visualising the magic - e.g. like above,
generating reports for type conversions, co
On Sep 3, 2007, at 7:07 AM, Hadrian Zbarcea wrote:
On the CAMEL-84 topic, I think returning null is a valid normal
case, not an exceptional one. If a null is an acceptable answer is
imho for the caller to decide (which is what the JournalEndpoint in
jpa does already).
Actually, the exce
On Sep 3, 2007, at 5:50 AM, James Strachan wrote:
* Async exchange handling should always be assumed.
I'm not totally sure about this one. One of the reasons JBI is so
complex to work with is that it assumes all the hard stuff is always
the case. e.g. if you want to use transactions, being as
On the CAMEL-84 topic, I think returning null is a valid normal case,
not an exceptional one. If a null is an acceptable answer is imho for
the caller to decide (which is what the JournalEndpoint in jpa does
already).
Throwing an exception instead of returning null would also force the
calle
On 9/2/07, Brian McCallister <[EMAIL PROTECTED]> wrote:
> As I am wrapping up a project which uses Cameland Hiram asked me to
> send my feedback to the list so... :-)
Awesome - feedback == good!
> Firstly, Camel has proven really nice to work with for the most part.
> It simplified a much nastie
As I am wrapping up a project which uses Cameland Hiram asked me to
send my feedback to the list so... :-)
Firstly, Camel has proven really nice to work with for the most part.
It simplified a much nastier first take on my project!
So, to the details:
* The async exchange stuff in trunk is
16 matches
Mail list logo
