cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gunnar Morling <>
Subject Re: Coloc feature and dispatch clients
Date Fri, 27 May 2011 20:14:48 GMT

thanks for your answers. I'm feeling though, that having to specify an
operation and/or WSDL is somewhat contrary to what I had in mind when
thinking about using a dispatch client in the first place.

The idea was to write integration tests for a CXF based web service in
a manner similar to what Spring WS offers [1]. So basically I'd like
to be able to "send" simple String (or Source etc.) based requests to
my endpoint and retrieve a String back for comparison. I want to use
the coloc transport as that way the endpoint is invoked synchronously
(meaning in the same thread as the test and the client runs). This in
turn allows to execute the complete test within one transaction.

As alternative I'm now invoking the endpoint directly (without using
CXF at all) but this comes at the cost of having to deal with
(un-)marshalling manually which makes the test a bit less elegant.

Maybe you see any other way to accomplish this?

Thanks again,



2011/5/27 Daniel Kulp <>:
> On Friday, May 27, 2011 1:58:17 PM Aki Yoshida wrote:
>> Hi Dan,
>> I don't think replacing the generic operation name with the user
>> defined operation name so early in the phase helps because the
>> operation name must match within ClientImpl to find one of the
>> "dispatching operations".
> Actually, it doesn't.  If the Dispatch is created via a Service object that
> was created with the WSDL URL, it should be able to find a valid operation for
> it.    This is also needed to be able to do things like WS-SecurityPolicy and
> such with the Dispatch clients.   To get the correct policies for the
> operation, we need to know the operation, match it based on the WSDL, and get
> the policies from there.    The SecurityPolicyTest.testDispatchClient() test
> case (in the ws-security systests) shows this, although this actually goes a
> different route.   If the operation is not specified on the RequestContext, it
> will use the qname on the root of the Source passed into the dispatch.invoke
> to try and match the operation.
> Again, this ONLY works if the Service is constructed with a WSDL.   If you try
> with a generic Service object, it won't.
> Dan
>> I also gave up on trying to use the annotations to make the matching
>> work because there seems to be no way to construct a matching pair
>> when you want to have the service name of your provider to be
>> something different from the dispatch invoker’s generic service name.
>> If we can set the namespace of the provider’s operation to the
>> dispatch invoker's generic namespace while setting the namespace of
>> the provider's service to the user defined one, that would work. In
>> this case, the endpoint references will match with the user defined
>> name and the binding operations will match with the invoker's generic
>> operation name. But I couldn't find a way to do this.
>> So I just went the other way and modifed a couple of lines in several
>> Coloc classes to make it work. I don't know whether there is an easier
>> approach.
>> regards, aki
>> 2011/5/27 Daniel Kulp <>:
>> > One thing you can try:
>> >
>> > If you do a
>> > dispatch.getRequestContext().put(MessageContext.WSDL_OPERATION, new
>> > QName("http://my.namespace", "myOperation"));
>> >
>> > before calling the invoke, it MAY be able to properly match the operation
>> > name and thus not use the generic "invoke" operation.   That said, you
>> > MAY need to create the Dispatch client from a Service that was created
>> > with a WSDL URL.
>> >
>> > Dan
>> >
>> > On Thursday, May 26, 2011 1:02:56 PM Gunnar Morling wrote:
>> >> Hi,
>> >>
>> >> I'm trying to use CXF's coloc feature
>> >> ( Things work fine when
>> >> using a "real" client for accessing the service (meaning the generated
>> >> service/port classes for my service).
>> >>
>> >> But I'm running into trouble when using a dynamic client, namely a
>> >> JAX-WS dispatch client. The cause seems to be that in
>> >> org.apache.cxf.binding.coloc.ColocOutInterceptor#isColocated() the
>> >> name of the invoked operation is compared against the names hosted by
>> >> the co-located server port. As the invoked method name is a generic
>> >> one in the dispatch scenario ("invoke" actually) this comparison fails
>> >> and instead of the coloc transport the standard transport using HTTP
>> >> is performed.
>> >>
>> >> Is there anything I could do about this? If JAX-WS dispatch based
>> >> clients are generally not supported, is there any other way to use the
>> >> coloc transport in a generic manner? Or is this just an issue, for
>> >> which I should open up a feature request in JIRA?
>> >>
>> >> Thanks in advance,
>> >>
>> >> Gunnar
>> >
>> > --
>> > Daniel Kulp
>> >
>> >
>> > Talend -
> --
> Daniel Kulp
> Talend -

View raw message