camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Issue using camel-cxf and wss4j
Date Fri, 11 Jan 2013 10:02:58 GMT
On Thu, Jan 10, 2013 at 4:58 PM, Daniel Kulp <> wrote:
> On Jan 10, 2013, at 4:37 AM, Charles Moulliard <> 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 <>wrote:
>> --
>> Charles Moulliard
>> Apache Committer / Sr. Enterprise Architect (RedHat)
>> Twitter : @cmoulliard | Blog :
> --
> Daniel Kulp
> -
> Talend Community Coder -

Claus Ibsen
Red Hat, Inc.
FuseSource is now part of Red Hat
Twitter: davsclaus
Author of Camel in Action:

View raw message