James, I saw a CxfInvokeTest failure after deleting my local repository. I attached a quick patch to pom.xml. It was caused by the recent separation of jetty from the cxf-rt-transports-http artifact. Thanks! - William
On 4/5/07, William Tam <[EMAIL PROTECTED]> wrote:
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/ >
