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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>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 <[email protected](mailto: >>>> [email protected])> 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 >>>> >>>> >>>> >>> >> >
