2012/5/10 Daniel Kulp <dk...@apache.org>: > > We discussed a while ago how the Camel CXF component's modes don't really > "match" what CXF can provide. It currently has two modes: > > 1) Message mode - it provides the full message kind of as a stream. > However, it specifically DISABLES much of the CXF processing of the message. > > 2) Payload - allows CXF to process it, but only provides the body. > > > However, in CXF, "Message Mode" really means access to the whole message, > but also processed and verified by CXF. Thus, there is a mismatch between > the two semantics of Message mode. There is also no easy way in Camel to > have the equivalent of the CXF Message mode.
Hi Dan, You mean there is no easy way to add the removed interceptors back in for the camel's MESSAGE mode. A weird way that might work would be to insert an interceptor bean into the existing phase and let this interceptor dynamically insert the other interceptors. In any case, I would also like to have an out-of-the-box CXF message mode. > > What I'd LIKE to do is: > > 1) Introduce a new "RAW" mode which is the current Message mode. Likely > for now, the two would just be aliases of each other, but I'd prefer to > promote usage of the new RAW mode name to keep it clear that it's not the > same as the CXF message mode. > > 2) Introduce a new mode that would mimic the CXF Message mode. Just not > sure what to call it. PROCESSED_MESSAGE? Thoughts? If we call the current MESSAGE mode the RAW mode in the future, we can call the new CXF interceptor-aware mode as the MESSAGE mode (or CXF_MESSAGE mode). PROCESSED_MESSAGE doesn't sound good because it's not obvious what it is. regards, aki > > For Camel 3.0, I think I'd change MESSAGE to map to the new > PROCESSED_MESSAGE to keep semantics similar. Not something to do now > though. > > Thoughts? > > -- > Daniel Kulp > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com >
