You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Tam, William" <WT...@iona.com> on 2007/04/05 07:35:26 UTC
[CAMEL] camel-cxf
I've been looking at the Camel. It's pretty cool. I attached a patch
to the camel-cxf component which has a lot of "TODOs" but hopefully I
can start contributing. :-) 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.
- William
Re: [CAMEL] camel-cxf
Posted by James Strachan <ja...@gmail.com>.
Thanks for the patch! Applied and now the CxfInvokeTest works fine for
me, thanks!
BTW it seems that CXF depends on 2.0.5 of jaxb-impl which doesn't
appear in a repo I can see; for now I've hacked the camel poms to
exclude that and use a lower version.
On 4/6/07, William Tam <em...@gmail.com> wrote:
> Sorry about that. Here it is. If the attachment is still missing, it is a
> one liner.
>
> - <artifactId>cxf-rt-transports-http</artifactId>
> +
> <artifactId>cxf-rt-transports-http-jetty</artifactId>
>
> Thanks!
>
>
> On 4/6/07, James Strachan <ja...@gmail.com> wrote:
> > On 4/6/07, William Tam <em...@gmail.com> wrote:
> > > 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!
> >
> > A-ha! I wondered what it was. BTW I didn't see a patch attatched to
> > your mail? I tried adding jetty & cxf-rt-transports-http is already
> > in the pom.xml; so wasn't sure how to fix it as I still get
> >
> > java.lang.RuntimeException: Could not find destination factory for
> > transport http://schemas.xmlsoap.org/soap/http
> > at
> org.apache.cxf.binding.soap.SoapTransportFactory.getDestination
> (SoapTransportFactory.java:76)
> > at
> org.apache.cxf.endpoint.ServerImpl.<init>(ServerImpl.java:77)
> >
> > --
> >
> > James
> > -------
> > http://radio.weblogs.com/0112098/
> >
>
>
>
--
James
-------
http://radio.weblogs.com/0112098/
Re: [CAMEL] camel-cxf
Posted by William Tam <em...@gmail.com>.
Sorry about that. Here it is. If the attachment is still missing, it is a
one liner.
- <artifactId>cxf-rt-transports-http</artifactId>
+ <artifactId>cxf-rt-transports-http-jetty</artifactId>
Thanks!
On 4/6/07, James Strachan <ja...@gmail.com> wrote:
>
> On 4/6/07, William Tam <em...@gmail.com> wrote:
> > 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!
>
> A-ha! I wondered what it was. BTW I didn't see a patch attatched to
> your mail? I tried adding jetty & cxf-rt-transports-http is already
> in the pom.xml; so wasn't sure how to fix it as I still get
>
> java.lang.RuntimeException: Could not find destination factory for
> transport http://schemas.xmlsoap.org/soap/http
> at org.apache.cxf.binding.soap.SoapTransportFactory.getDestination(
> SoapTransportFactory.java:76)
> at org.apache.cxf.endpoint.ServerImpl.<init>(ServerImpl.java:77)
>
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
Re: [CAMEL] camel-cxf
Posted by James Strachan <ja...@gmail.com>.
On 4/6/07, William Tam <em...@gmail.com> wrote:
> 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!
A-ha! I wondered what it was. BTW I didn't see a patch attatched to
your mail? I tried adding jetty & cxf-rt-transports-http is already
in the pom.xml; so wasn't sure how to fix it as I still get
java.lang.RuntimeException: Could not find destination factory for
transport http://schemas.xmlsoap.org/soap/http
at org.apache.cxf.binding.soap.SoapTransportFactory.getDestination(SoapTransportFactory.java:76)
at org.apache.cxf.endpoint.ServerImpl.<init>(ServerImpl.java:77)
--
James
-------
http://radio.weblogs.com/0112098/
Re: [CAMEL] camel-cxf
Posted by William Tam <em...@gmail.com>.
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 <em...@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 <ja...@gmail.com> wrote:
> >
> > On 4/5/07, William Tam <em...@gmail.com> wrote:
> > > On 4/5/07, James Strachan < james.strachan@gmail.com> wrote:
> > >
> > > > On 4/5/07, Tam, William <WT...@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/
> >
>
>
Re: [CAMEL] camel-cxf
Posted by William Tam <em...@gmail.com>.
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 <ja...@gmail.com> wrote:
>
> On 4/5/07, William Tam <em...@gmail.com> wrote:
> > On 4/5/07, James Strachan <ja...@gmail.com> wrote:
> >
> > > On 4/5/07, Tam, William <WT...@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/
>
Re: [CAMEL] camel-cxf
Posted by James Strachan <ja...@gmail.com>.
On 4/5/07, William Tam <em...@gmail.com> wrote:
> On 4/5/07, James Strachan <ja...@gmail.com> wrote:
>
> > On 4/5/07, Tam, William <WT...@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/
Re: [CAMEL] camel-cxf
Posted by William Tam <em...@gmail.com>.
On 4/5/07, James Strachan <ja...@gmail.com> wrote:
> On 4/5/07, Tam, William <WT...@iona.com> wrote:
> > I've been looking at the Camel. It's pretty cool.
>
> Thanks! :)
>
>
> > 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.
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.
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 ?). 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).
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!
James
> -------
> http://radio.weblogs.com/0112098/
>
Re: [CAMEL] camel-cxf
Posted by James Strachan <ja...@gmail.com>.
On 4/5/07, Tam, William <WT...@iona.com> wrote:
> I've been looking at the Camel. It's pretty cool.
Thanks! :)
> 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.
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'
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).
--
James
-------
http://radio.weblogs.com/0112098/