+1 for the refactoring of camel-cxf in Camel 3.0. I think we could put the camel-cxf-transport into CXF, as it is mainly used for CXF. And the component just have the dependency of camel-core.
For the other cxf-x components we may do some clean up work at the same time. -- Willem Jiang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://www.fusesource.com | http://www.redhat.com Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English) http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese) Twitter: willemjiang Weibo: 姜宁willem Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Friday, January 11, 2013 at 6:02 PM, Claus Ibsen wrote: > On Thu, Jan 10, 2013 at 4:58 PM, Daniel Kulp <dk...@apache.org > (mailto:dk...@apache.org)> wrote: > > > > On Jan 10, 2013, at 4:37 AM, Charles Moulliard <ch0...@gmail.com > > (mailto: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 > > > (mailto: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 (mailto:cib...@redhat.com) > Web: http://fusesource.com > Twitter: davsclaus > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen
