You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Jason Pell <ja...@pellcorp.com> on 2013/04/12 06:55:13 UTC
Re: Spring integration
Changed the mailing list to something more appropriate...
After further thinking I realised that I don't actually want to do exactly
as what would be achieved with a spring int custom transport (at least not
the destination component)
First of all, all of my web service methods will be one way, so I don't
need to deal with a reply to channel or anything.
What I actually want to do is this:
CLIENT
-----------------------------------------------------------------
jaxws:client -> spring integration channel -> https
This could be achieved with a custom conduit with a client address of:
spring-int://channel/somechannel
The end of the channel would need to be a outgoing http outgoing gateway or
something.
However if I instead implemented:
spring integration gateway (implementing the service interface) -> spring
integration channel -> jaxws:client
I would not have to worry about a http outgoing gateway
ENDPOINT (SERVICE)
--------------------------------------------------------------
For Service:
jaxws:endpoint -> spring integration pollable channel -> service impl
This would not be catered for by a destination as I still want to use the
Jetty front end for the jaxws:endpoint but instead of passing the call
directly onto the service impl, I want it to be stored into a message
channel and at some later point the service impl would be executed.
CUSTOM SERVICE ACTIVATOR / MESSAGE HANDLER
------------------------------------------------------------------------------------
So really what I need to do in both cases I think is a custom message
handler that can figure out what service method to implement based on the
message and header content. Since I will be persisting to a db in the
integration channel I will also need to figure out how to either unmarshal
the correct JAXB from the serialised XML or instead use java serialisation
of the jaxb objects. Then I will need an enhanced service activator that
can execute the correct method on the jaxws:client or the service impl as
appropriate.
On Fri, Apr 12, 2013 at 1:26 PM, Jason Pell <ja...@pellcorp.com> wrote:
> I can see what you were getting at, and that certainly makes sense. I
> guess I can model this on the camel transport.
>
>
> http://camel.apache.org/better-jms-transport-for-cxf-webservice-using-apache-camel.html
> http://camel.apache.org/camel-transport-for-cxf.html
>
> I might spend some time on this and see how difficult it would be.
>
>
> On Fri, Apr 12, 2013 at 1:19 PM, Jason Pell <ja...@pellcorp.com> wrote:
>
>> Yes,
>>
>> I also realised my approach will not work for multiple methods as the
>> service-activator expects a method name. Back to doing more reading in the
>> spring integration docs and samples.
>>
>>
>>
>>
>> On Fri, Apr 12, 2013 at 1:06 PM, Willem jiang <wi...@gmail.com>wrote:
>>
>>> Yeah, you are not the first one who has this idea.
>>> I think the easiest way is implement a transport of sprint integration,
>>> you can setup the {Input|Output} channel for the conduit or destination.
>>> The difficult part could how to implement the CXF Continuation API with
>>> spring integration async support.
>>>
>>> BTW, CXF supports the Servlet3 async invocation API out of box.
>>>
>>> --
>>> Willem Jiang
>>>
>>> Red Hat, Inc.
>>> FuseSource is now part of Red Hat
>>> Web: http://www.fusesource.com | http://www.redhat.com
>>> Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/)
>>> (English)
>>> http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
>>> Twitter: willemjiang
>>> Weibo: 姜宁willem
>>>
>>>
>>>
>>>
>>>
>>> On Friday, April 12, 2013 at 8:27 AM, Jason Pell wrote:
>>>
>>> > Topics of interest.
>>> >
>>> >
>>> http://cxf.547215.n5.nabble.com/re-CXF-with-Sprint-Integration-td5501007.html
>>> >
>>> http://cxf.547215.n5.nabble.com/CXF-embedded-within-a-SpringIntegration-Context-td5158465.html
>>> >
>>> >
>>> > On Wed, Apr 10, 2013 at 8:25 PM, Jason Pell <jason@pellcorp.com(mailto:
>>> jason@pellcorp.com)> wrote:
>>> >
>>> > > Is there any plans to add namespace support for jaxws endpoint and
>>> client
>>> > > to spring integration?
>>> > >
>>> > > I am envisioning ability to define jaxws:client as a gateway with a
>>> queue
>>> > > channel in between to provide decoupling of client from transport
>>> > >
>>> > > And endpoint as a end of a channel - service activator maybe.
>>> > >
>>> > > There is camel support for cxf not sure how that works
>>> > >
>>> > > I am looking at using spring integration for async support rather
>>> than jms
>>>
>>>
>>>
>>
>
Re: Spring integration
Posted by Jason Pell <ja...@pellcorp.com>.
Some useful code from https://github.com/dturanski/method-aware-gateway to
add the method info the header to assist in the service activator.
On Tue, Apr 16, 2013 at 7:36 PM, Jason Pell <ja...@pellcorp.com> wrote:
> Anyway for anyone interested I got this working nicely for endpoint's so
> far - only those where the service interface has a void return - which is
> exactly what I was after.
>
> I have jaxws:endpoint -> spring-int:gateway -> message queue channel (with
> jdbc persistence) -> service impl working very nicely.
>
> I think there is a threading bug in the spring integration
> JdbcChannelMessageStore so I have created a local copy while awaiting a fix
> to be applied.
>
>
> https://github.com/pellcorp/cxf/tree/master/JavaFirst/src/test/java/com/pellcorp/spring/integration/queue/EndpointTest.java
>
> Cheers
> Jason
>
>
>
> On Fri, Apr 12, 2013 at 2:55 PM, Jason Pell <ja...@pellcorp.com> wrote:
>
>> Changed the mailing list to something more appropriate...
>>
>> After further thinking I realised that I don't actually want to do
>> exactly as what would be achieved with a spring int custom transport (at
>> least not the destination component)
>>
>> First of all, all of my web service methods will be one way, so I don't
>> need to deal with a reply to channel or anything.
>>
>> What I actually want to do is this:
>>
>> CLIENT
>> -----------------------------------------------------------------
>> jaxws:client -> spring integration channel -> https
>>
>> This could be achieved with a custom conduit with a client address of:
>> spring-int://channel/somechannel
>>
>> The end of the channel would need to be a outgoing http outgoing gateway
>> or something.
>>
>> However if I instead implemented:
>>
>> spring integration gateway (implementing the service interface) -> spring
>> integration channel -> jaxws:client
>>
>> I would not have to worry about a http outgoing gateway
>>
>> ENDPOINT (SERVICE)
>> --------------------------------------------------------------
>>
>> For Service:
>> jaxws:endpoint -> spring integration pollable channel -> service impl
>>
>> This would not be catered for by a destination as I still want to use the
>> Jetty front end for the jaxws:endpoint but instead of passing the call
>> directly onto the service impl, I want it to be stored into a message
>> channel and at some later point the service impl would be executed.
>>
>> CUSTOM SERVICE ACTIVATOR / MESSAGE HANDLER
>>
>> ------------------------------------------------------------------------------------
>>
>> So really what I need to do in both cases I think is a custom message
>> handler that can figure out what service method to implement based on the
>> message and header content. Since I will be persisting to a db in the
>> integration channel I will also need to figure out how to either unmarshal
>> the correct JAXB from the serialised XML or instead use java serialisation
>> of the jaxb objects. Then I will need an enhanced service activator that
>> can execute the correct method on the jaxws:client or the service impl as
>> appropriate.
>>
>>
>> On Fri, Apr 12, 2013 at 1:26 PM, Jason Pell <ja...@pellcorp.com> wrote:
>>
>>> I can see what you were getting at, and that certainly makes sense. I
>>> guess I can model this on the camel transport.
>>>
>>>
>>> http://camel.apache.org/better-jms-transport-for-cxf-webservice-using-apache-camel.html
>>> http://camel.apache.org/camel-transport-for-cxf.html
>>>
>>> I might spend some time on this and see how difficult it would be.
>>>
>>>
>>> On Fri, Apr 12, 2013 at 1:19 PM, Jason Pell <ja...@pellcorp.com> wrote:
>>>
>>>> Yes,
>>>>
>>>> I also realised my approach will not work for multiple methods as the
>>>> service-activator expects a method name. Back to doing more reading in the
>>>> spring integration docs and samples.
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Apr 12, 2013 at 1:06 PM, Willem jiang <wi...@gmail.com>wrote:
>>>>
>>>>> Yeah, you are not the first one who has this idea.
>>>>> I think the easiest way is implement a transport of sprint
>>>>> integration, you can setup the {Input|Output} channel for the conduit or
>>>>> destination.
>>>>> The difficult part could how to implement the CXF Continuation API
>>>>> with spring integration async support.
>>>>>
>>>>> BTW, CXF supports the Servlet3 async invocation API out of box.
>>>>>
>>>>> --
>>>>> Willem Jiang
>>>>>
>>>>> Red Hat, Inc.
>>>>> FuseSource is now part of Red Hat
>>>>> Web: http://www.fusesource.com | http://www.redhat.com
>>>>> Blog: http://willemjiang.blogspot.com (
>>>>> http://willemjiang.blogspot.com/) (English)
>>>>> http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
>>>>> Twitter: willemjiang
>>>>> Weibo: 姜宁willem
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Friday, April 12, 2013 at 8:27 AM, Jason Pell wrote:
>>>>>
>>>>> > Topics of interest.
>>>>> >
>>>>> >
>>>>> http://cxf.547215.n5.nabble.com/re-CXF-with-Sprint-Integration-td5501007.html
>>>>> >
>>>>> http://cxf.547215.n5.nabble.com/CXF-embedded-within-a-SpringIntegration-Context-td5158465.html
>>>>> >
>>>>> >
>>>>> > On Wed, Apr 10, 2013 at 8:25 PM, Jason Pell <jason@pellcorp.com(mailto:
>>>>> jason@pellcorp.com)> wrote:
>>>>> >
>>>>> > > Is there any plans to add namespace support for jaxws endpoint and
>>>>> client
>>>>> > > to spring integration?
>>>>> > >
>>>>> > > I am envisioning ability to define jaxws:client as a gateway with
>>>>> a queue
>>>>> > > channel in between to provide decoupling of client from transport
>>>>> > >
>>>>> > > And endpoint as a end of a channel - service activator maybe.
>>>>> > >
>>>>> > > There is camel support for cxf not sure how that works
>>>>> > >
>>>>> > > I am looking at using spring integration for async support rather
>>>>> than jms
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Spring integration
Posted by Jason Pell <ja...@pellcorp.com>.
Anyway for anyone interested I got this working nicely for endpoint's so
far - only those where the service interface has a void return - which is
exactly what I was after.
I have jaxws:endpoint -> spring-int:gateway -> message queue channel (with
jdbc persistence) -> service impl working very nicely.
I think there is a threading bug in the spring integration
JdbcChannelMessageStore so I have created a local copy while awaiting a fix
to be applied.
https://github.com/pellcorp/cxf/tree/master/JavaFirst/src/test/java/com/pellcorp/spring/integration/queue/EndpointTest.java
Cheers
Jason
On Fri, Apr 12, 2013 at 2:55 PM, Jason Pell <ja...@pellcorp.com> wrote:
> Changed the mailing list to something more appropriate...
>
> After further thinking I realised that I don't actually want to do exactly
> as what would be achieved with a spring int custom transport (at least not
> the destination component)
>
> First of all, all of my web service methods will be one way, so I don't
> need to deal with a reply to channel or anything.
>
> What I actually want to do is this:
>
> CLIENT
> -----------------------------------------------------------------
> jaxws:client -> spring integration channel -> https
>
> This could be achieved with a custom conduit with a client address of:
> spring-int://channel/somechannel
>
> The end of the channel would need to be a outgoing http outgoing gateway
> or something.
>
> However if I instead implemented:
>
> spring integration gateway (implementing the service interface) -> spring
> integration channel -> jaxws:client
>
> I would not have to worry about a http outgoing gateway
>
> ENDPOINT (SERVICE)
> --------------------------------------------------------------
>
> For Service:
> jaxws:endpoint -> spring integration pollable channel -> service impl
>
> This would not be catered for by a destination as I still want to use the
> Jetty front end for the jaxws:endpoint but instead of passing the call
> directly onto the service impl, I want it to be stored into a message
> channel and at some later point the service impl would be executed.
>
> CUSTOM SERVICE ACTIVATOR / MESSAGE HANDLER
>
> ------------------------------------------------------------------------------------
>
> So really what I need to do in both cases I think is a custom message
> handler that can figure out what service method to implement based on the
> message and header content. Since I will be persisting to a db in the
> integration channel I will also need to figure out how to either unmarshal
> the correct JAXB from the serialised XML or instead use java serialisation
> of the jaxb objects. Then I will need an enhanced service activator that
> can execute the correct method on the jaxws:client or the service impl as
> appropriate.
>
>
> On Fri, Apr 12, 2013 at 1:26 PM, Jason Pell <ja...@pellcorp.com> wrote:
>
>> I can see what you were getting at, and that certainly makes sense. I
>> guess I can model this on the camel transport.
>>
>>
>> http://camel.apache.org/better-jms-transport-for-cxf-webservice-using-apache-camel.html
>> http://camel.apache.org/camel-transport-for-cxf.html
>>
>> I might spend some time on this and see how difficult it would be.
>>
>>
>> On Fri, Apr 12, 2013 at 1:19 PM, Jason Pell <ja...@pellcorp.com> wrote:
>>
>>> Yes,
>>>
>>> I also realised my approach will not work for multiple methods as the
>>> service-activator expects a method name. Back to doing more reading in the
>>> spring integration docs and samples.
>>>
>>>
>>>
>>>
>>> On Fri, Apr 12, 2013 at 1:06 PM, Willem jiang <wi...@gmail.com>wrote:
>>>
>>>> Yeah, you are not the first one who has this idea.
>>>> I think the easiest way is implement a transport of sprint integration,
>>>> you can setup the {Input|Output} channel for the conduit or destination.
>>>> The difficult part could how to implement the CXF Continuation API with
>>>> spring integration async support.
>>>>
>>>> BTW, CXF supports the Servlet3 async invocation API out of box.
>>>>
>>>> --
>>>> Willem Jiang
>>>>
>>>> Red Hat, Inc.
>>>> FuseSource is now part of Red Hat
>>>> Web: http://www.fusesource.com | http://www.redhat.com
>>>> Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/)
>>>> (English)
>>>> http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
>>>> Twitter: willemjiang
>>>> Weibo: 姜宁willem
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Friday, April 12, 2013 at 8:27 AM, Jason Pell wrote:
>>>>
>>>> > Topics of interest.
>>>> >
>>>> >
>>>> http://cxf.547215.n5.nabble.com/re-CXF-with-Sprint-Integration-td5501007.html
>>>> >
>>>> http://cxf.547215.n5.nabble.com/CXF-embedded-within-a-SpringIntegration-Context-td5158465.html
>>>> >
>>>> >
>>>> > On Wed, Apr 10, 2013 at 8:25 PM, Jason Pell <jason@pellcorp.com(mailto:
>>>> jason@pellcorp.com)> wrote:
>>>> >
>>>> > > Is there any plans to add namespace support for jaxws endpoint and
>>>> client
>>>> > > to spring integration?
>>>> > >
>>>> > > I am envisioning ability to define jaxws:client as a gateway with a
>>>> queue
>>>> > > channel in between to provide decoupling of client from transport
>>>> > >
>>>> > > And endpoint as a end of a channel - service activator maybe.
>>>> > >
>>>> > > There is camel support for cxf not sure how that works
>>>> > >
>>>> > > I am looking at using spring integration for async support rather
>>>> than jms
>>>>
>>>>
>>>>
>>>
>>
>