cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Introducing Apache Camel (was Re: The implementation of a simple service routing. WAS: RE: Release Update)
Date Mon, 26 Mar 2007 14:55:30 GMT
On 3/24/07, Dan Diephouse <> wrote:
> Hiya James,
> This is very cool. I like the predicate/processor API a lot.

Thanks. FWIW we've nice scripting and XPath support now too...

from(someURI).filter(groovy(" { |i| i.cheese == 'edam'

> Can you explain more what you mean by "I'm just not sure yet in the
> CxfEndpoint how to bind inbound exchanges to the CXF bus and back again
> nicely".

I know the Bus API pretty well; I just don't know the internals of CXF
well enough yet to figure out how to wire Camel and CXF together
nicely. (I've bridged the Exchange/Message classes fine, its the
Channel/Service/Transport parts I've not yet figured out). More in
reply to Jervis's reply later...

Am thinking things we could do are...

* package up Camel as a transport in CXF (then CXF can reuse all the
various Camel transports and Camel can reuse CXF as a nice JAX-WS
typesafe-front end to Camel)
* allow Camel to invoke CXF services (for deploying JAX-WS services
inside Camel and using Camel to route between service implementations)

> Maybe part of the problem is message representation. What do we think of
> creating an XmlMessage which standardizes on using a Source object. Then
> people can write processors which can work for most XML things. CxfMessage
> could then extend XmlMessage.

Yeah; though I do quite like the CXF API where you ask for the body by
class; say as a DOM or Source and it does the right thing. The problem
with XML is that there's so many damn APIs and ways of working with



View raw message