cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eirik Bjørsnøs <>
Subject Re: Using Interceptors on JAX-RS 2.0 Client
Date Wed, 23 Mar 2016 21:40:14 GMT

We got our feature working by letting it keep track of which
InterceptorProviders it had already initialised. This way interceptors only
got added once.

Not sure what you mean by "adding interceptors directy". I found no way of
doing that on the Client..? Perhaps you just mean client.register(new
LoggingInInterceptor()) ? I didn't find any read of Interceptors in the
implementation classes, but perhaps I got lost. And yes, the implementation
wouldn't know which chain to put those on, so I guess a Feature would be
required anyway.

Our code currently works for us using a Feature.  It correctly captures
request and response logs (we're using a custom subclass of

Having some sort of cleaner lifecycle tracking done by the framework would
be nice. Doesn't feel right to register a feature and have it initialised
once per request.

If you end up changing something, please ping this thread so we can test
and update the code on our side.


On Wed, Mar 23, 2016 at 6:58 PM, Sergey Beryozkin <>

> Hi Eirik
> I totally forgot, I looked at the code and realized I did something there
> to support CXF Features - the fact the interceptors are added per request
> is the unfortunate side-effect that in 2.0 API WebTargets are spawned per
> request, so obviously it was not done by design. To be honest I did not
> spend much time on it.
> Right so it nearly works, and worth investigating further how to avoid
> adding duplicate interceptors.
> I don't think adding interceptors directly will work because the client
> will no idea if it is the in or out interceptor. Feature will work
> Sergey
> On 23/03/16 19:40, Eirik Bjørsnøs wrote:
>> Sergey,
>> Our observation (with 3.0.3 I think) was that the feature was not ignored,
>> but instead initialized once per request. Which added new interceptors to
>> the WebClient on every request. Not sure I understand the intention behind
>> this design.
>> I think I just assumed that I could use Interceptors for JAX-RS clients
>> just like JAX-WS.
>> We could and probably will rewrite these to JAX-RS filters, but it would
>> of
>> course be even sweeter if we could simply reuse the logging interceptors
>> we
>> currently use for our SOAP services.
>> Cheers,
>> Eirik.
>> On Mar 22, 2016 10:08 AM, "Sergey Beryozkin" <>
>> wrote:
>> Hi
>>> It is not possible to register CXF specific Feature or Interceptor
>>> with JAX-RS 2.0 Client API.
>>> When you do "client.register(new MyLoggingFeature())", assuming it is CXF
>>> Feature, then it will be currently ignored.
>>> I wonder if it might make sense to create some JAX-RS 2.0 FeatureWrapper
>>> which can wrap an arbitrary CXF Feature...I'll try to experiment with
>>> it...
>>> Sergey
>>> On 22/03/16 01:56, Eirik Bjørsnøs wrote:
>>> Hello,
>>>> Is the CXF implementation of the JAX-RS 2.0 client API designed to allow
>>>> Interceptors to be configured on Clients? If so, how should this be
>>>> done?
>>>> Say we have a Client built like this:
>>>>      Client client = ClientBuilder.newClient();
>>>> and we want to configure Logging[In/Out]Interceptors of this client.
>>>> (Just
>>>> as an example).
>>>> First I tried in various ways to get an Endpoint out of the client, but
>>>> failed at that.
>>>> Then, after looking through the implementation classes of
>>>> Client/WebTarget,
>>>> I discovered that you can register CXF Features on a Client using
>>>> something
>>>> like
>>>>       client.register(new MyLoggingFeature());
>>>> However, with this setup MyLoggingFeature.initialize(InterceptorProvider
>>>> ip, Bus bus) is called _once per request_.
>>>> Not exactly what I wanted since it lead to the interceptor chains being
>>>> filled up with duplicate LoggingInterceptors.
>>>> I might perhaps have misunderstood the lifecycle of Clients and/or
>>>> WebTargets. Should be ok to reuse a JAX-RS 2.0 Client, right?
>>>> Can someone please enlighten me? Did I perhaps miss some relevant
>>>> documentation?
>>>> Cheers,
>>>> Eirik.
> --
> Sergey Beryozkin
> Talend Community Coders

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message