users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Re: Re: Does FilterContext.getRequestBuilder() copy request?

From: Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com>
Date: Thu, 15 Dec 2011 07:43:24 -0800

On Dec 14, 2011, at 9:18 AM, Bill Burke wrote:

>
>
> On 12/14/11 11:43 AM, Santiago Pericas-Geertsen wrote:
>>
>> On Dec 13, 2011, at 6:35 AM, Bill Burke wrote:
>>
>>>
>>>
>>> On 12/13/11 7:25 AM, Marek Potociar wrote:
>>>
>>>>> All these builder interfaces buy you very very little (except for confusion and complexity). Its really hurting the
>>>>> spec, IMO.
>>>>
>>>> I disagree.
>>>>
>>>
>>> I know you disagree and its unfortunate. The spec is hurting because of it. You have different read interface (Request) and write interface (RequestBuilder) for something that is *always* available to both read and write.
>>
>> This is a matter of personal preference, it does not hurt the spec as you say. In fact, it seems consistent with JAX-RS 1.X where we had a Response and a Response.ResponseBuilder.
>>
>> As for the filters, if the builders have getter methods, we could create a single builder for the filter chain and have the framework call build() when the chain is completed.
>>
>
> You don't separate things in terms of a read and write interface unless there's going to be a case where the thing is immutable.

 There are many cases of immutable filters. These do not need to access the builders, and you can tell this by looking at the implementation with this separation.

> Plus a ResponseBuilder made sense in JAXRS 1 because you were building something. For RequestBuilder you not building anything, but instead modifying something that already exists. I just view this as a pedantic exercise to follow some suggested best-practice/design-pattern religiously.
>
> The same reason why I think its ridiculous we have two duplicate hierarchies for RequestBuilder and Invoction.Builder and all the SyncInvoker, etc. complex hierarchy. All this exists because you guys insist that it is more important to follow a specific design pattern/methodology than having a consistent simple interface for the user.

 Simplicity and consistency are separate aspects. I don't see how your proposal is consistent with the existing class hierarchy. If we could forget some parts of JAX-RS 1.X, I'd probably support your proposal, but I don't see how we can.

-- Santiago