You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Mukarram Baig <mu...@gmail.com> on 2014/07/01 04:12:18 UTC

ParamConverterProviders getting jumbled up between jaxrs:server and jaxrs:client on 2.7.1.1

Hi All,

I am facing a weird issue with CXF 2.7.11 (also in 2.7.3)

Say I have an app1 that exposes a certain method in Service1 like:

void doSomething(@QueryParam("input") SpecialObject1 obj)

and the XML configuration for this is as:
    <jaxrs:server id="app1ServiceRS"
        address="/app1ServiceRS">
        <jaxrs:serviceBeans>
            <ref bean="service1" />
        </jaxrs:serviceBeans>
        <jaxrs:providers>
            <ref bean="jacksonJsonProvider"/>
            <ref bean="app1ParamConverterProvider" />
        </jaxrs:providers>
    </jaxrs:server>

the app1ParamConverterProvider is the bean of a ParamConverterProvider
class in app1 that supplies the ParamConverter for handling SpecialObject1.
So far things work great. Now if this app1 needs to interact with another
app - app2 which exposes a method in Service2 like:

void doSomething(@QueryParam("inputThing") SpecialObject2 obj);

and the XML in app1 to access this as:
    <jaxrs:client id="service2" serviceClass="com.kilo.Service2"
        address="http://somehost:someport/app2ServiceRS">
        <jaxrs:providers>
            <ref bean="jacksonJsonProvider" />
            <ref bean="app2ParamConverterProvider" />
        </jaxrs:providers>
    </jaxrs:client>

the app2ParamConverterProvider is a different bean of a
ParamConverterProvider class in app2 that supplies the ParamConverter for
handling SpecialObject2.

No other bus configuration is done - so everything else is default. When
any thread in app1 tries to access service2, somehow the control is passed
to app1ParamConverterProvider instead of app2ParamConverterProvider and the
call fails. Is this expected? From the docs at
http://cxf.apache.org/docs/jaxrs-services-configuration.html#JAXRSServicesConfiguration-Sharingprovidersbetweenmultipleendpoints
it seems that if the two providers are mentioned with different ids, then
they should not be shared and shouldn't cause one to be invoked with the
other.

This is somewhat random, but I think I have a test project (using jetty
container) where I am able to reproduce this consistently. Please let me
know if I am missing out on something elementary.

FWIW, I don't see this problem in CXF 3.0.0. Maybe because
ServerProviderFactory and ClientProviderFactory have been split up?

Thanks in advance!

Re: ParamConverterProviders getting jumbled up between jaxrs:server and jaxrs:client on 2.7.1.1

Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 01/07/14 03:12, Mukarram Baig wrote:
> Hi All,
>
> I am facing a weird issue with CXF 2.7.11 (also in 2.7.3)
>
> Say I have an app1 that exposes a certain method in Service1 like:
>
> void doSomething(@QueryParam("input") SpecialObject1 obj)
>
> and the XML configuration for this is as:
>      <jaxrs:server id="app1ServiceRS"
>          address="/app1ServiceRS">
>          <jaxrs:serviceBeans>
>              <ref bean="service1" />
>          </jaxrs:serviceBeans>
>          <jaxrs:providers>
>              <ref bean="jacksonJsonProvider"/>
>              <ref bean="app1ParamConverterProvider" />
>          </jaxrs:providers>
>      </jaxrs:server>
>
> the app1ParamConverterProvider is the bean of a ParamConverterProvider
> class in app1 that supplies the ParamConverter for handling SpecialObject1.
> So far things work great. Now if this app1 needs to interact with another
> app - app2 which exposes a method in Service2 like:
>
> void doSomething(@QueryParam("inputThing") SpecialObject2 obj);
>
> and the XML in app1 to access this as:
>      <jaxrs:client id="service2" serviceClass="com.kilo.Service2"
>          address="http://somehost:someport/app2ServiceRS">
>          <jaxrs:providers>
>              <ref bean="jacksonJsonProvider" />
>              <ref bean="app2ParamConverterProvider" />
>          </jaxrs:providers>
>      </jaxrs:client>
>
> the app2ParamConverterProvider is a different bean of a
> ParamConverterProvider class in app2 that supplies the ParamConverter for
> handling SpecialObject2.
>
> No other bus configuration is done - so everything else is default. When
> any thread in app1 tries to access service2, somehow the control is passed
> to app1ParamConverterProvider instead of app2ParamConverterProvider and the
> call fails. Is this expected? From the docs at
> http://cxf.apache.org/docs/jaxrs-services-configuration.html#JAXRSServicesConfiguration-Sharingprovidersbetweenmultipleendpoints
> it seems that if the two providers are mentioned with different ids, then
> they should not be shared and shouldn't cause one to be invoked with the
> other.
>
> This is somewhat random, but I think I have a test project (using jetty
> container) where I am able to reproduce this consistently. Please let me
> know if I am missing out on something elementary.
>
> FWIW, I don't see this problem in CXF 3.0.0. Maybe because
> ServerProviderFactory and ClientProviderFactory have been split up?

It is works in 3.0.0 because there multiple ParamConverterProvider 
instances are supported so I believe when you have a shared bus between 
the client and the server the providers get accumulated.

In 2.7.x only a single ParamConverterProvider was supported, probably 
because originally I thought that having a single ParamConverterProvider 
was sufficient (it can support in turn multiple specific 
ParamConvertes), and later was forced to fix it on the trunk only to get 
past TCK issues. So I guess it can be overridden in 2.7.x when a shared 
bus is used.

I updated 2.7.x to support multiple ParamConverterProvider instances 
too. In meantime either have unique buses assigned to jaxrs:server and 
jaxrs:client or have a single ParamConverterProvider supporting multiple 
ParamConverters

Cheers, Sergey





>
> Thanks in advance!
>


Re: ParamConverterProviders getting jumbled up between jaxrs:server and jaxrs:client on 2.7.1.1

Posted by Mukarram Baig <mu...@gmail.com>.
Thanks Sergey, that explains the behavior.