On Thu, Jul 9, 2009 at 12:14 AM, Hadrian Zbarcea<hzbar...@gmail.com> wrote:
> Currently the Exchange has the following 4 apis that I think can be
> consolidated into 1 or 2 methods:
>
> Exchange newInstance();
+1 to remove
> Exchange copy();
+1 to keep
> Exchange newCopy(boolean handoverOnCompletion);
-1 = must keep as is
> void copyFrom(Exchange source);
+1 to remove
>
> I think both copyFrom(Exchange) and newInstance() could easily be replaced
> by copy(). The usage pattern is:
> Exchange e = source.newInstance();
> e.copyFrom(source);
> which is as good as
> Exchange e = source.copy();
>
> I believe newCopy(which is kinda ugly and only used in 4 places) can be
> consolidated with copy(), but I'd have to take a closer look. Its usage is
> not really consistent with the javadoc description (only used by wiretap,
> seda and ThreadsProcessor, not all of the components that do async
> messaging). Looking at the implementation in DefaultExchange, setting the
> CORRELATION_ID is already done by copy() and in 2 out of 4 calls it's
> invoked with handoverOnCompletion set to false.
newCopy is creating a new exchange with a copy of the payloads from
the source. The returned new Exchange do *not* have
the same exchange Id and Unit of Work as the source - as opposed to
regular copy(). Its a totally new exchange that is independent of the
source.
For instance it is used by wiretap to tap an exchange.
The handoverOnCompletion is needed when you "pass the token" of the
completion callbacks from one exchange
to another. For instance when you route over SEDA or use threads() DSL.
The classic example is routing from a FILE consumer where the on
completion callbacks is doing the *after* job of
moving the processed files to the .camel backup folder.
So the newCopy is needed and to work as is.
And I can only see that newCopy sets the correlation id
// set a correlation id so we can track back the original exchange
copy.setProperty(Exchange.CORRELATION_ID, this.getExchangeId());
This code is only in the newCopy method.
>
> I can't really see what the different semantic abstractions these methods
> represent (in spite of the javadoc comments) and I'd like this api cleanup
> to be done in 2.0 if you guys agree.
>
> Thoughts?
Now that Exchange is only implemented in DefaultExchange and its final
we can more easily do the API cleanup.
So yeah if the work can be done in timely manner. We should take 1-2
days at most. 2.0 must be released this month.
If not then mark the methods as @deprecated so we can remove them later.
Only issue there might be is that Endpoint have some createExchange
methods that might need the old code.
Maybe an issue here. But since we only got one instance of Exchange
now it should be much easier.
> Hadrian
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
