camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eduard Hildebrandt" <>
Subject Re: Fwd: Using Apache Camel as Transport for Apache CXF with SOAP over JMS
Date Wed, 09 Jul 2008 11:11:36 GMT
Hi Willem,

thanks for applying the patch. One of my customers is planning to use
the next release of Apache Camel and CXF in production environment and
this was an important bugfix for them. I'm looking forward for Apache
Camel 1.4 :-)

I have some additional comments:

Using a byte-array as message body
("ex.getIn().setBody(outputStream.getBytes());") like I did  works for
in the demo. But as I mentioned before I think this is not an elegant
solution. What happens if my service implementation expects a

It should be possible to configure the message type (TextMessage,
BytesMessage, …) in JMS component. The current implementation can be
the default behaviour. But if the user configure a JMS message type
than the JMS component must convert the content in the requested
message type format.

FEATURE REQUEST #2 (depends on #1):
If the user specify TextMessage as JMS message type than it must be
possible to specify the encoding (UTF-8, ISO-8856-1, …) of the text
message. This feature is tricky because if the content is a byte array
then the JMS component does not know the current encoding of the data.
Maybe we need an additional property in Camel context that specifies
the encoding of the message content.

Let me know what you are thinking about this feature requests. If you
are interested I can try to implement these features and send you a

Best regards,


2008/7/9 Willem Jiang <>:
> Hi Eduard,
> I just applied the CXF part of patch in the Camel trunk, and I also did some
> refactoring work take the common expression codes as utile method in
> CxfSoapBinding.
> Thanks for your great demo, I take it as an integration test case for the
> CAMEL-686 :)
> We have some discussion about how to handle the protocol header here[1], you
> solution is very simple and effective for using camel transport in CXF. We
> may go further by thinking the use case in a more common way.
> Thought?
> [1]
> Willem.

View raw message