Thank you very much for this clarification.
Implicitly behind this, there is still the need to determine which is the
MediaType to return ?
I understand that it is done automatically most of time by Jersey:
For example, if you are in the Resource method that produces "xml" or
"json".
The developper has nothing to deal with. The correct @Provider will be
called automatically by Jersey,
in order to decide the correct representation of the entity to return.
But the issue more for HTML reprsentations, that are made via a Viewable
wrapper.
Rarely for Resource method but truly for ExceptionMappers:
And the music sounds like this:
Resonse toResponse() {
MediaType firstType =
httpContext.getRequest().getAcceptableMediaTypes().get(0);
if(firstType.equals(MediaType.TEXT_HTML)) {
response = new Viewable("/jsp",entity);
}
}
This is what happens (often) in a ExceptionMapper that need to deal with
many represenations.It does not know the @Procuces constraint of the
Resource method where the issue has occurred.
Or may be I missed something...
Regards,
exxos.
On Tue, Sep 7, 2010 at 1:45 PM, Paul Sandoz <Paul.Sandoz_at_oracle.com> wrote:
> Hi,
>
> It is because the response content-type header is only set after the
> response of the resource method has been processed.
>
> For the case of exceptions thrown from the resource method then the
> content-type will be set after the response of the exception mapper has been
> returned.
>
> I am gonna have to think of a way to improve the situation as a number of
> developers are running into this issue. The problem is when one sets a
> Response instance on the HttpResponseContext (returned or generated from the
> resource method or an exception mapper) existing response headers, if any,
> are removed i.e. it replaces the complete response state.
>
> If one explicitly sets response headers in a resource method one may not
> necessarily want them to apply if an exception is thrown from that resource
> method.
>
> Another example is if an exception occurs in a response filter, which is
> then mapped to a response, then it does not make sense to apply the
> content-type (nor most likely any other response headers set by other
> filters) associated with the resource method.
>
> I need to think some more on this...
>
> Paul.
>
>
> On Sep 7, 2010, at 1:03 PM, exxos wrote:
>
> Hello,
>>
>> Here is the code I'm testing:
>>
>> @Path("hello")
>> public class App {
>>
>> @Context HttpContext httpContext;
>>
>> @GET
>> @Produces(MediaType.TEXT_HTML)
>> public Response getHtml() {
>>
>> System.out.println("RESOURCE hello >>> HttpContext Response:" +
>> httpContext.getResponse());
>> System.out.println("RESOURCE hello >>> MediaType :" +
>> httpContext.getResponse().getMediaType());
>>
>> return Response.ok("Hello I'm fine !").build();
>> }
>> }
>>
>> The issue is that MediaType is "null". Could you please advise why I
>> cannot get the MediaType from the HttpContext?
>> (This is the same behavior with ExecptionMapper where I base content
>> negotiation on that)
>>
>> Best regards,
>> exxos.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>
>