On Nov 12, 2012, at 5:07 PM, Gege <[email protected]> wrote: > 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.
Interesting. In theory, those classes are all provides by the system runtime since they've been built into the JDK for a long time. Thus, they should be pulled from there unless they are either endorsed via the normal endorse mechanisms or something explicitely sets some sort of parent last class loader and doesn't allow them to pass through. > 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 > ? I have no problem with updating the xmlbeans version. Running the tests now. Dan > > 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)); >>> } -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
