With CXF 2.7.0 I managed to use server-side @UseAsyncMethod with client-side generated by cxf too (to have nio).
Just one remark though, i fell into this one with the AS JOnAS when using the client: https://issues.apache.org/jira/browse/XMLBEANS-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel CXF depends on xmlbeans 2.5.0 that includes :'( some org.x3c.dom (not all) classes and lead to many issues if : 1 - other version of xml-api is on classpath 2 - in the classpath order the war is before the other libraries Because some (not all) of xml-api's classes get "overriden" by the one packaged in xmlbean. No luck... That's my case, and i specifically want to invert the classpath order (my war first) in order not to be bothered by the packaged versions of CXF in the AS... According to the bug tracker xmlbeans >= 2.5.1 fixed this issue (simply removed the classes). I added an explicit dependency to xmlbeans 2.6.0 in my pom and everybody's happy again. Maybe it could be a solution to upgrade the version of the xmlbeans dependency in CXF ? Hope this explaination (I spend quite a bit of time clarifying this ^_^) will help fellows googlers. 2012/11/12 Gege <[email protected]>: > I sent the mail before finishing it ... > And so i wanted to conclude by saying that all that was left was doing > some introspection glue in order to map the object to a java method. > > But; yeah, there is some work to do before arriving to a "simple" > method call. But it might be re-usable. I'm surprised that it's not > already existing somewhere. > > 2012/11/12 Gege <[email protected]>: >>> That said, I'm really not a fan of Sun's provider based solution. The >>> provider stuff is "OK" but, to me, ignores many of the strengths of JAX-WS, >>> primarily the mapping to/from Java classes/interfaces and the easy >>> integration of JAXB types. I wanted something that mapped onto the JAX-WS >>> generated classes a bit easier but would also allow some level of code >>> first capability. >> >> I've been playing around with sun's Provider, the mapping to JAXB >> isn't *very* difficult if you do wsdl-first >> >> Create a context with the generated ObjectFactory class >> _jaxbContext = JAXBContext.newInstance(ObjectFactory.class); >> >> Then it's almost immediate to get the java objects : >> public void invoke(Source source, AsyncProviderCallback<Source> cbak, >> WebServiceContext ctxt) { >> JAXBElement jaxbRequest = (JAXBElement) >> _jaxbContext.createUnmarshaller().unmarshal(source); >> GetHelloWorldAsString getHelloWorldAsString = >> (GetHelloWorldAsString) jaxbRequest.getValue(); >> >> Then it's "almost" the same thing for the answer : >> >> GetHelloWorldAsStringResponse getHelloWorldAsStringResponse = >> objectFactory.createGetHelloWorldAsStringResponse(); >> getHelloWorldAsStringResponse.setReturn(/*somth*/); >> >> JAXBElement<GetHelloWorldAsStringResponse> jaxbResponse = >> objectFactory.createGetHelloWorldAsStringResponse(getHelloWorldAsStringResponse); >> >> ByteArrayOutputStream os = new ByteArrayOutputStream(); >> _jaxbContext.createMarshaller().marshal(jaxbResponse, os); >> ByteArrayInputStream is = new ByteArrayInputStream(os.toByteArray()); >> cbak.send(new StreamSource(is)); >> }
