Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Date: Wed, 14 Aug 2013 09:43:47 +0000 (UTC)
From: "abdelgadiri (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: <JIRA.12663593.1376468747917.63224.1376473427655@arcas>
In-Reply-To: <JIRA.12663593.1376468747917@arcas>
References: <JIRA.12663593.1376468747917@arcas>
Subject: [jira] [Comment Edited] (CXF-5201) jaxrs2: unable to intercept
 response to add new response headers
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CXF-5201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13739449#comment-13739449 ] 

abdelgadiri edited comment on CXF-5201 at 8/14/13 9:42 AM:
-----------------------------------------------------------

The bit related to the http method in my above comments may not be relevant - it was just an observation. Below are more details about my test case

My JAX-RS resource has two methods (first one 'readSingleAccount()' always ends up successfully appending additional response headers to the returned HTTPResponse while second one always doesn't append):

 @GET
 @Path("/{id}")
 public Response readSingleAccount(@PathParam("id") String accountID, @Context UriInfo uriInfo);

 @GET
 public Response readManyAccounts(@Context HttpServletRequest request, @Context UriInfo uriInfo);


The WriterInterceptor is as follows:

OutboundWriterInterceptor implements WriterInterceptor{
  @Context
    private HttpServletResponse response;

 public void aroundWriteTo(WriterInterceptorContext context)  IOException, WebApplicationException {
   response.setHeader("headerName", "headerValue");
 }

}

I am pretty sure the above interceptor gets invoked for both the JAX-RS calls but on client the response from first method readSingleAccount() will include the new 'headerName' while the reamManyAccounts() won't 
                
      was (Author: abdelgadiri):
    The bit related to the http method in my above comments may not be relevant - it was just an observation. Below are more details about my test case

My JAX-RS resource has two methods (first one 'readSingleAccount()' always ends up successfully appending additional response headers to the returned HTTPResponse while second one always doesn't append):

 @GET
 @Path("/{guid}")
 public Response readSingleAccount(@PathParam("id") String accountID, @Context UriInfo uriInfo);

 @GET
 public Response readManyAccounts(@Context HttpServletRequest request, @Context UriInfo uriInfo);


The WriterInterceptor is as follows:

OutboundWriterInterceptor implements WriterInterceptor{
  @Context
    private HttpServletResponse response;

 public void aroundWriteTo(WriterInterceptorContext context)  IOException, WebApplicationException {
   response.setHeader("headerName", "headerValue");
 }

}

I am pretty sure the above interceptor gets invoked for both the JAX-RS calls but on client the response from first method readSingleAccount() will include the new 'headerName' while the reamManyAccounts() won't 
                  
> jaxrs2: unable to intercept response to add new response headers
> ----------------------------------------------------------------
>
>                 Key: CXF-5201
>                 URL: https://issues.apache.org/jira/browse/CXF-5201
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-RS
>    Affects Versions: 2.7.5, 2.7.6
>         Environment: windows
>            Reporter: abdelgadiri
>
> In a WriterInterceptor, one expects to be able to modify response headers via:
> //here using putSingle() but could also use on of the addXXX variants
> context.getHeaders().putSingle("headerName", headerValue);
> However, above is not working in 2.7.5/2.7.6 (@see JIRA-4986)
> As a workaround, one should be able to inject the HttpServletResponse object via: @Context HttpServletResponse response;
> then be able to add headers directly to the response object e.g.,
> response.setHeader("headerName", headerValue);
> however, above is also not working in (2.7.5/2.7.6). This is not always reproducable as sometimes my client does see the new headers in the received response. On closer look it seems the added headers get lost when it is a @GET request as opposed to e.g., a @POST. Basically, my test case (a @GET) always fails with a missing header in the received response even though I am pretty sure the server had added the header. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira