activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William Tam" <email.w...@gmail.com>
Subject Re: [CAMEL] camel-cxf
Date Thu, 05 Apr 2007 19:51:48 GMT
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 <james.strachan@gmail.com> wrote:
>
> On 4/5/07, William Tam <email.wtam@gmail.com> wrote:
> > On 4/5/07, James Strachan <james.strachan@gmail.com> wrote:
> >
> > > On 4/5/07, Tam, William <WTAM@iona.com> 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/
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message