I met another "issue".
I was editing my WSDL and wsdl2java stopped generating asynchronous client apis.
I added a bindings.xml file for wsdl2java with
<enableAsyncMapping>true</enableAsyncMapping>.
It does not solves anything about the client api (maybe there is
something it doesn't like in my wsdl, i'll check stop-by-step when
starting from my original wsdl).
But on the generated server, I now have a third method signature in
the generated interface :
public InviteResponse invite(Invite parameters)
public Future<?> inviteAsync(Invite parameters, final
AsyncHandler<InviteResponse> asyncHandler)
public Response<InviteResponse> inviteAsync(Invite parameters);
What is that third method with Response<InviteResponse> as the return type ?
Is it an "old" (pre servlet 3) asynchronous API that will rely on
underlying synchronous IO (thus not thread-efficient ?) Looks like
this method is jax-ws compliant since the response type is "import
javax.xml.ws.Response;".
2012/11/13 Gege <[email protected]>:
> 2012/11/12 Daniel Kulp <[email protected]>:
>> 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.
>
> You're totally right, that's why only some persons have this issue: I
> voluntary changed the behavior of the classloader using
> ocntainer-specific parameters in jonas and jboss.
>
> Why ?
>
> Because many java EE containers come with tons of "services". However
> those services (like jax-ws auto deployment based on CXF ^_^) come
> with a fixed version of ... CXF in this case. But I want to use CXF
> 2.7.0, and my container contains CXF 2.5.2. I don't want to ask the
> installation team to mess with the container, so I put the parameter
> to change the classpath order. Now, for my war only, the embedded jars
> will be looked at first when looking for a class. That way I'm not
> dependent (well... less than before) of the container. Of course my
> war is bigger because I don't re-use the container's included libs.
>
> But in this case, a usually invisible problem (the alien classes in
> xmlbeans) becomes visible ^_^
>
> Anyway, thanks a lot for your support ! I realize that i mightbe in a
> specific situation, wanting asynchronous api and NIO everywhere, and
> even with this classloader tweak ! !
