jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: Updated Client API and Interceptors/Filters proposal is available - please review

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Thu, 09 Jun 2011 19:15:06 +0200

Yes, sounds reasonable when looking at the example. Will update the API.

Marek

On 06/09/2011 06:08 PM, Guilherme Silveira wrote:
> Hi Marek!
>
> There is also the method name "typification". Again, it's a personal
> taste regarding conciseness:
>
>> postPersonalData.disableFeature(Features.REQUEST_LOGGING);
> postPersonalData.disable(Features.REQUEST_LOGING);
>
> If you have a feature in your hand:
> postPersonalData.disable(feature);
>
> instead of the previous one:
> postPersonalData.disableFeature(feature);
>
> Regards
>
>
> Guilherme Silveira
> Caelum | Ensino e Inovação
> http://www.caelum.com.br/
>
>
>
> On Thu, Jun 9, 2011 at 9:53 AM, Marek Potociar
> <marek.potociar_at_oracle.com> wrote:
>>
>>
>> On 06/06/2011 02:06 PM, Bill Burke wrote:
>>>
>>>
>>> On 6/6/11 7:45 AM, Dionysios G. Synodinos wrote:
>>>> - I don't like all the getFeature() methods. Just have a
>>>> getProperties() method and be done with it. I don't think I've ever
>>>> seen such an API in Java EE before or what you're trying to
>>>> accomplish with it.
>>>>
>>>>
>>>> I appreciate simplicity, but semantically "properties" continue to be
>>>> quite different to me than "features".
>>>>
>>>
>>> I just don't see a use case for being able to see if a feature is enabled or enabling or disabling a feature at the
>>> Invocation level. Can somebody provide one?
>>>
>>
>> How about:
>>
>> postPersonalData.disableFeature(Features.REQUEST_LOGGING);
>>
>> ?
>>
>> Marek
>>