cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gege <geg...@gmail.com>
Subject Re: Asynchronous
Date Mon, 12 Nov 2012 22:07:12 GMT
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 <gegefr@gmail.com>:
> 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 <gegefr@gmail.com>:
>>> 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));
>> }

Mime
View raw message