On Thu, Jan 10, 2013 at 4:58 PM, Daniel Kulp <dk...@apache.org> wrote: > > On Jan 10, 2013, at 4:37 AM, Charles Moulliard <ch0...@gmail.com> wrote: >> I don't find info about this dataFormat (CXF_MESSAGE) in CXF. Does it exist >> ? > > Yes it exists, but I'm really not exactly happy about how it works. I'd > like to kind of "redo" it, but it would require a lot of internal CXF changes > which I haven't had time to figure all out either. >
I wonder if we should consider putting camel-cxf up for refactor or rewrite for Camel 3.0 ? In the past we have rewritten components, eg such as the file and ftp components. And the JMS got some bigger refactorings as well etc. I am saying this as camel-cxf may have gotten a bit big, and there is maybe overlap with functionality in CXF itself, that is better handled by CXF than in camel-cxf. Also I wonder if its possible to separate camel-cxf into WS and RS. So people doing either one, have a lighter component. And possible if some shared code is needed we can have a camel-cxf-core. Most noticeable is the RS part where people who is looking for a simple RS may go for camel-restlet over camel-cxf. Though its not all just because of the code. But another point is the camel-cxf documents is a bit of "mess". So maybe with a clean slate, we can both do new documents and new components that is lighter and easier to use, as well people can easier slice and dice so if they only do RS or WS. Any thoughts? > Basically: > > MESSAGE/RAW mode sucks from a CXF standpoint as pretty much all the CXF > processing is bypassed. (that's the problem you saw) What's super confusing > about it is that is also REMOVES things that the user may be relying on (like > the SAAJ interceptors) that then can result in very strange error messages. > (again what you saw) Really, I'm unsure why you wouldn't just use a pure > HTTP component for most of this OTHER than for the WSDL generation, but even > that is kind of doable if you have a static WSDL pre-generated. In any > case, my gut feeling is that a pure http component would perform slightly > better. For the most part, the advantage of this over the other two modes > is performance though. Keeps the raw byte streaming, very little processing. > > PAYLOAD does allow all of the proper CXF processing. Using StAX, it can also > do a lot of "xml streaming", but XML streaming is much slower than byte > streaming due to the parsing and such. HOWEVER, PAYLOAD just gives the > contents of the Body. If you need to route the soap headers and attachments > and such along as well, you need to do more work. > > I was hoping that CXF_MESSAGE could be somewhere in the middle where you > could have CXF process everything correctly, but still be able to route on > the full message. HOWEVER, with the way CXF works internally, we have to > build up a full SAAJ model in this case. Thus, ALL of the streaming does not > work in CXF_MESSAGE mode. This is what I was hoping to somehow change, but > would require a ton of work in CXF. :-( I'd like to be able to optimize > this isn't something closer to how the PAYLOAD mode works with the XML > streaming, but definitely requires a lot of work in CXF first. > > That said, when using WS-Security, we have to build the full SAAJ model > anyway so the broken streaming wouldn't be an issue. > > > Dan > > > >> On Thu, Jan 10, 2013 at 8:43 AM, Willem jiang <willem.ji...@gmail.com>wrote: >> >>> CXF_MESSAGE >> >> >> >> >> -- >> Charles Moulliard >> Apache Committer / Sr. Enterprise Architect (RedHat) >> Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com > > -- > Daniel Kulp > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > -- Claus Ibsen ----------------- Red Hat, Inc. FuseSource is now part of Red Hat Email: cib...@redhat.com Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
