> Yeah. > > BTW we could leave getIn() and getOut() & try implement the > ImmutableWrapper and CopyOnWriteFacade for In/Out respectively and try > them out inside the current API - before we go ahead with any kind of > renaming of getIn() and getOut(). >
> Maybe we could even keep getIn() / getOut() around for 2.0 (and zap in > 2.1) and leave deprecated and make them just delegate to the new > method names (say getInputMessage() and getMessage()). The deprecated > message could then describe how folks typically should switch > getIn()/getOut() to using getMessage() unless they really really want > the immutable input message getInputMessage(). > Brilliant idea and a good migration path as well. And it wont delay Camel 2.0 as much as a full blown migration would have done.
