cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gege <>
Subject Re: Asynchronous
Date Tue, 13 Nov 2012 13:44:05 GMT
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

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;".

2012/11/13 Gege <>:
> 2012/11/12 Daniel Kulp <>:
>> 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 ! !

View raw message