Hi,
On 29/02/12 16:13, Bill Burke wrote:
>
>
> On 2/29/12 6:39 AM, Sergey Beryozkin wrote:
>> Hi Bill
>> On 28/02/12 17:20, Bill Burke wrote:
>>> I just wanted to list all the inconsistencies and awkwardness with the
>>> current Request/Response/Filter API and to suggest a different proposal
>>> here (read the readme):
>>>
>>> https://github.com/patriot1burke/jaxrs2-proposal-2-24-12
>>>
>>> * Clients don't use the Request interface at all. Only within a client
>>> filter.
>>>
>>> * THere are methods that don't make sense on Request and Response
>>> depending on the semantics:
>>>
>>> - Request.selectVariant(), evaluatePreconditions(), etc. don't make
>>> sense on the client side.
>>> - Request.readEntity() methods don't make sense on the client side.
>>> - Response.readEntity(), close(), and bufferEntity methods don't make
>>> sense on the server side
>>>
>>
>> So indeed it possibly make sense introducing a client side Request
>> representation.
>> As for Response, I do think that the close() method was redundant, one
>> can get the InputStream and close if needed but you also was keen on
>> having that method :-); indeed the semantics of close() on the server
>> side are not clear to me at all and as I indicated earlier on it might
>> interfere with other framework-specific features to do with calling
>> post-destroy methods on server resource classes.
>>
>
> If there is an entity, then the container cannot automatically close the
> InputStream until the entity is read. There are times when the client
> does not care about the entity (i.e. an error response). Are you
> suggesting that the client has to read the entity even if it doesn't
> care about it?
>
No. I'm saying that if it does care about closing the response stream
asap without expecting GC to close it then it can request an underlying
InputStream from Response and close it.
Now, I'm looking at Response...Well, indeed some of these methods do not
make sense on the server side, unless Marek is seeing it differently ?
>>> * Header values aren't always objects or strings. On the server side,
>>> Request headers are strings, on the client side, they are Objects. Vice
>>> versa with Response headers.
>>>
>> I think Objects (on the client or server sides) should only be settable
>> when headers are set initially. On the get side - should always be
>> strings.
>>
>
> Seriously you think that? For one, you don't think a filter will want to
> add a header to an outgoing request or resopnse? You want to require
> them to marshal these headers into String before adding them? You are
> also saying filters will have to unmarshal the header value before
> interacting with it? Both of these are akin to marshalling the request
> or response before it is finished being built.
>
> Not to mention that MessageBodyWriters already require header values as
> java.lang.Objects. Be consistent with MessageBodyWriters.
Yes, MessageBodyWriter accepts a modifiable Map with Object values.
This should've been presented differently somehow, the writer can add
arbitrary Java objects to the map but of course it has to 'unmarshall'
the individual header value if it want to make the decision based on the
already available header instances...
So I wanted to say was that the reader of the headers should see the
Strings, the writer - Objects.
am I missing something ?
>
>>> http://java.net/jira/browse/JAX_RS_SPEC-176
>>>
>>> * Server-side deployment scanning is unusable if you have client-only
>>> Request or ResponseFilters in your classpath:
>>>
>>> http://java.net/jira/browse/JAX_RS_SPEC-170
>>>
>>> This will require extra metadata (annotation or otherwise).
>>>
>> Not worried about this one :-)
>>
>
> Well, you should worry about it as it is an issue. The examples/ folder
> in the spec already has examples of client-only filters. Currently there
> is no way to designate these filters as client-only, and these filters
> will end up in the server filter chain if scanning is turned on.
>
>
>>> * On the server-side, we're changing how developers interact with
>>> JAX-RS. Instead of HttpHeaders we want them to inject RequestHeaders or
>>> a Request object.
>>
>> I do want HttpHeaders be preserved as the main representation of the
>> request headers on the server side as having both HttpHeaders &
>> RequestHeaders does seem controversial to me, but I do not see why
>> replacing them with RequestHeaders changes the interaction pattern; as
>> for Request offering the reference to headers - this seems simply
>> another option as opposed to the pattern change
>>
>
> Well, for one, I strongly oppose header values always represented as
> Strings. HttpHeaders return header value as Strings which isn't
> compatible with a client request header value which can be
> java.lang.Object.
>
I think all the mutable maps, as in
http://java.net/projects/jax-rs-spec/sources/git/content/src/jax-rs-api/src/main/java/javax/ws/rs/ext/ReaderInterceptorContext.java?rev=62bb71340b7c156684858dac5c9af09aec50430c
(which seems to be the only problematic place to me...)
should return Object as value - so in that regard I think we agree.
Immutable maps should only have Strings...
Ex.
http://java.net/projects/jax-rs-spec/sources/git/content/src/jax-rs-api/src/main/java/javax/ws/rs/ext/WriterInterceptorContext.java?rev=62bb71340b7c156684858dac5c9af09aec50430c
looks good to me. RequestBuilder & ResponseBuilder are also fine.
Sorry, where else do you see the problems ?
Sergey
>
>