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 Fri, 06 Apr 2007 03:56:23 GMT
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.wtam@gmail.com> 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 <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