On 3/24/07, Dan Diephouse <[EMAIL PROTECTED]> 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("foo.bar.any { |i| i.cheese == 'edam'
}")).to(anotherURI).
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
it...
--
James
-------
http://radio.weblogs.com/0112098/
