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 <[email protected]> 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 <[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 >>>>> >>>>> >>>>> >>>> >>> >> >
