Hi James, Your manual application worked. Thanks! BTW, the CxfInvokeTest does pass if I do "mvn -Dtest=CxfInvokeTest test". You probably meant some other tests didn't pass. Anyways, now I understand where you are going with the LocalTransport stuff (which is awesome), I'll see if I can get it to work. Hopefully, we don't have to comment out those tests soon. I'd think LocalTransport is a logical starting point, too.. And yes - it is quite confusing. There are discussions going on in the dev list for improvement.
Regards, William On 4/5/07, James Strachan <[EMAIL PROTECTED]> wrote:
On 4/5/07, William Tam <[EMAIL PROTECTED]> wrote: > On 4/5/07, James Strachan <[EMAIL PROTECTED]> wrote: > > > On 4/5/07, Tam, William <[EMAIL PROTECTED]> wrote: > > > I attached a patch to > > > the camel-cxf component which has a lot of "TODOs" but hopefully I can > > start > > > contributing. J > > > > Great! :) BTW I seemed to have trouble applying the patch locally; am > > not sure why so I ended up applying a fair bit of the diffs by hand. > > It could be an effect of the fair bit of refactoring thats taken place > > lately on the core APIs of Camel - its now settled down finally. > > > > I'll apply shortly - just need a bit of feedback... > > > > > > > BTW, I am not sure we need to deal with Destination and > > > Conduit (transport) directly. I think we can use custom message > > observer > > > and interceptors in CXF to obtain messages at various phases of > > processing. > > > > Sounds cool. > > > > I'm still trying to grok your patches; it seems the producer side > > assumes that the message contains a method name & a List of parameters > > to invoke. One of the reasons for going with the LocalTransport was to > > try work at the messaging layer (rather than object invocation layer), > > so that a message could be a byte[] or Document or Source which then > > goes through the CXF SOAP binding before being turned into a method > > invocation etc. > > > > e.g. to be able to do things like, poll a file, turn the file into an > > XML Source then fire it into some CXF endpoint to deal with the XML > > data binding or SOAP handling etc. > > > I agree. I've added a TODO for it. :-) :) > Basically, we can skip those CXF interceptors that marshal an invocation > into > a XML doc and leaving the transport layer intact. CXF picks the right > transport > based on the transport address URL. To do that, we can create a custom CXF > client. The custom client will accept a XML source or inputstream, set the > input in > a CXF Message, initialize an outgoing interceptor chain, and fire off the > chain. Ah OK. So maybe we need a CXF client which just takes a CXF Exchange/Message? Then we can populate those from the Camel Exchange/Message and let the client figure out how to do the binding? Though we do have some nice type-conversion stuff in Camel which it'd be nice to use though :). It could end up being easier to do the transform/routing from an arbitrary XML document to a CXF invoke-endpoint in Camel maybe. > Likewise, on the consumer side, we may need to customize the in interceptor > chain that skips the unmarshalling in order to obtain XML source. E.g. A > Camel > consumer might want to transform/process the message received from a CXF > endpoint as a XML doc and send it to another endpoint. Agreed. > Though I see the merit in being able to just include a kinda > > invocation inside the message body then use CXF as a general purpose > > reflection type service. > > > > I'm wondering, should we have multiple CXF components & endpoints? Or > > maybe one CXF component which creates different kinds of endpoints > > based on the URI or something. As sometimes we'll be sending around > > chunks of XML; other times we'll be sending a List of arguments and a > > method name? So maybe we need different endpoints for 'method > > invocation-style' versus 'message endpoints' > > > Yeah, I think it makes sense to have multiple endpoints based on URI scheme. > (cxf-xxx ?). Yeah! I couldn't think of a good name - so for now I've committed your patch as cxf-invoke: URIs and used the prefix CxfInvoke[Component|Endpoint|Producer|Consumer]. Am sure we can come up with a much better naming convention than that & maybe unify the code a bit more etc. I had to do some manual application of your patch, so could you double check that I didn't miss any code please? It should all now be in svn. The CxfInvokeTest case doesn't pass yet mind you, so its still disabled in pom.xml :) Keep up the good work! :) > We also have to come up with a URI format for endpoints that > assocated with a WSDL (and to specify the service and port, etc). Agreed! I started a thread on the CXF list about URI formats to see if CXF could come up with a standard URI format we could reuse. > In terms of use cases; I'd like to be able to take Camel messages and > > bind them with CXF services; plus I'd also ultimately love to use CXF > > as a JAX-WS client on top of Camel message exchanges. So as well as > > having a Camel Component for CXF I see the need for a CXF transport > > using Camel (for embedding Camel inside CXF). > > > > -- > > > Way cool! :) What do you think is the best way of writing a CXF transport using Camel; I started trying to port the JMS one but ended up getting very confused; so am wondering if the Local transport might be better starting point? -- James ------- http://radio.weblogs.com/0112098/
