Skip to main content

[jax-rs-spec issues] [JIRA] Issue Comment Edited: (JAX_RS_SPEC-155) Request interface should offer a reference to HttpHeaders

  • From: "Marek Potociar (JIRA)" <jira-no-reply@...>
  • To: issues@...
  • Subject: [jax-rs-spec issues] [JIRA] Issue Comment Edited: (JAX_RS_SPEC-155) Request interface should offer a reference to HttpHeaders
  • Date: Fri, 24 Feb 2012 18:59:38 +0000 (GMT+00:00)
  • Auto-submitted: auto-generated


    [ 
http://java.net/jira/browse/JAX_RS_SPEC-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=332813#action_332813
 ] 

Marek Potociar edited comment on JAX_RS_SPEC-155 at 2/24/12 6:58 PM:
---------------------------------------------------------------------

I tried to think about it more and unfortunately I don't see a way how we 
could unify the headers interfaces into a single {{HttpHeaders}}, since that 
interface was originally designed as request-only (see e.g. 
{{getRequestHeader(String name)}} and {{getRequestHeaders()}} methods on the 
interface).

The only solution that I could think of was to do something along these lines:

# Perform a "roll-back" in the req/resp API:
#* remove {{Request.RequestBuilder}}
#* remove new methods added to {{Request}}, {{Response}}, 
{{Response.ResponseBuilder}}
#* remove {{RequestHeaders}}, {{ResponseHeaders}}
# Define client-side response interface
# Define {{BaseUriInfo}} that would contain only the URI-related and 
client-side usable subset of {{UriInfo}} interface
# Extend {{FilterContext}} and/or add specific sub-classes.
#* Expose {{BaseUriInfo}} in {{FilterContext}}
#* Expose mutable request headers (in {{RequestFilterContext}} sub-class) and 
immutable request headers (in {{ResponseFilterContext}} sub-class) 
multivalued map
#* Expose mutable request entity (in {{RequestFilterContext}} sub-class) and 
immutable request entity (in {{ResponseFilterContext}} sub-class) multivalued 
map
#* Expose mutable response headers (in {{ResponseFilterContext}} sub-class) 
multivalued map
#* Expose mutable response entity (in {{ResponseFilterContext}} sub-class) 
multivalued map
#* Define common {{MessageEntity}} interface to cover entity manipulation in 
filters as described above.
#* (Alternatively, we could expose some of the information in filters via 
injection)

So the above is an outline of a potential solution(?), but I am not sure we 
should go that way at the moment. Feel free to comment or add your own 
CONCRETE proposal. It is clear that, given our schedule, unless we can 
resolve the issue very soon, we'll have to close it and leave things as is.


      was (Author: m_potociar):
    I tried to think about it more and unfortunately I don't see a way how we 
could unify the headers interfaces into a single {{HttpHeaders}}, since that 
interface was originally designed as request-only (see e.g. 
{{getRequestHeader(String name)}} and {{getRequestHeaders()}} methods on the 
interface).

The only solution that I could think of was to do something along these lines:

# Perform a "roll-back" in the req/resp API:
#* remove {{Request.RequestBuilder}}
#* remove new methods added to {{Request}}, {{Response}}, 
{{Response.ResponseBuilder}}
#* remove {{RequestHeaders}}, {{ResponseHeaders}}
# Define client-side response interface
# Define {{BaseUriInfo}} that would contain only the URI-related and 
client-side usable subset of {{UriInfo}} interface
# Extend {{FilterContext}} and/or add specific sub-classes.
#* to expose {{BaseUriInfo}} in {{FilterContext}}
#* to expose mutable request headers (in {{RequestFilterContext}} sub-class) 
and immutable request headers (in {{ResponseFilterContext}} sub-class) somehow
#* to expose mutable request entity (in {{RequestFilterContext}} sub-class) 
and immutable request entity (in {{ResponseFilterContext}} sub-class) somehow
#* to expose mutable response headers (in {{ResponseFilterContext}} 
sub-class) somehow
#* to expose mutable response entity (in {{ResponseFilterContext}} sub-class) 
somehow
#* Define common {{MessageEntity}} interface to cover entity manipulation in 
filters as described above.
#* (Alternatively, we could expose some of the information in filters via 
injection)

So the above is an outline of a potential solution(?), but I am not sure we 
should go that way at the moment. Feel free to comment or add your own 
CONCRETE proposal. It is clear that, given our schedule, unless we can 
resolve the issue very soon, we'll have to close it and leave things as is.

  
> Request interface should offer a reference to HttpHeaders
> ---------------------------------------------------------
>
>                 Key: JAX_RS_SPEC-155
>                 URL: http://java.net/jira/browse/JAX_RS_SPEC-155
>             Project: jax-rs-spec
>          Issue Type: Improvement
>          Components: server
>            Reporter: beryozkin_sergey
>            Assignee: Marek Potociar
>             Fix For: 2.0-pr
>
>
> Request interface should offer a reference to HttpHeaders;

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://java.net/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


[jax-rs-spec issues] [JIRA] Issue Comment Edited: (JAX_RS_SPEC-155) Request interface should offer a reference to HttpHeaders

Marek Potociar (JIRA) 02/24/2012

<Possible follow-up(s)>

[jax-rs-spec issues] [JIRA] Issue Comment Edited: (JAX_RS_SPEC-155) Request interface should offer a reference to HttpHeaders

Marek Potociar (JIRA) 02/24/2012

[jax-rs-spec issues] [JIRA] Issue Comment Edited: (JAX_RS_SPEC-155) Request interface should offer a reference to HttpHeaders

Marek Potociar (JIRA) 02/24/2012

[jax-rs-spec issues] [JIRA] Issue Comment Edited: (JAX_RS_SPEC-155) Request interface should offer a reference to HttpHeaders

Marek Potociar (JIRA) 02/24/2012
 
 
Close
loading
Please Confirm
Close