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?
>> * 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.
>> 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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com