JBossDeveloper

BTW, one nice side effect of the above change is that we can do away with the reply handler and and the consumer callback handler in our Camel pipeline.

Awesome work, Lukasz!  I'm going to post comments in phases here so that we can sort of build up from core.  Looking at the core diffs, I have the following feedback:

- I don't think there should be a setContext() on Message.  A context is created when the message is created and it is modified but not replaced.

- RemoteMessage should not extend DefaultMessage

- I couldn't figure out what the _scope field is used for in DefaultContext

- DefaultMessage copies all context headers and I think we decided it copies no context headers

- I would prefer it if we had a private instance variable in DefaultMessage which tracked whether it's been sent instead of checking for MESSAGE_ID header.  My reasoning there is that other state can be associated with the context besides MESSAGE_ID, so it's probably best just to keep the check private to our implementation.

- ExchangeImpl.initContentType(Message) appears to set the contract's input type for IN and OUT now?  I think we need to go back to two methods or have a conditional in this method based off exchange phase.  Also, small nit but the message reference doesn't have to come in as a parameter, I think we could use getMesssage() instead.

- I made an error in my prior post indicating that there was an Exchange.getContext(Scope scope), when Context itself is scope aware.  Not sure how I messed that up.  I like the idea of context as an abstraction over both scopes, so I'll need to ponder this a bit more. :-)

Overall, your changes look great and I think this will make things considerably easier.

I've been thinking about this quite a bit relative to our original goals around Context.  Scope was introduced to represent the lifecycle of state associated with an invocation (stored as context properties).  It was never intended to allow a given property to live simultaenously in multiple scopes.  In other words, Context has one bucket of properties and some properties in that bucket live longer than others.

I think there is only one Context.  We should not pass a separate context for message and exchange to context mappers.  You get a single context and for any property in that context there is a scope.  This is just from an API standpoint.  Underneath the covers, Camel exchange properties and message headers can be used to store the actual values.  A call to context.getProperty("foo") would look in message first, then in exchange scope.  A call to context.getProperty("foo", Scope.MESSAGE) would look directly in the message headers.  I would consider it rare and likely borderline buggy if a property existed in both scopes, so I'm just stating this so that we have a precedence rule.  When they do, the most specific setting (i.e. message) should be the one we go with.  Any context property returned has a scope associated with it as well, like we have today.

I believe that Message.getContext() should return the properties with Scope.MESSAGE for that specific message instance.  Any properties set on that Context instance are Scope.MESSAGE.  Attempting to set Scope.EXCHANGE properties should result in SwitchYardException to fail fast with a clear error.

Do we even need a ScopedContext?  Can the above methods just be on Context and you essentially have a wrapper object under the covers that represents ScopedContext?