Hi Paul,
About the HTTP codes above 399 (errors), this is more a question of
assisstance offered to clients. For example, even if for the error 406 it is
not useful, for others it could be interesting:
<error>
<reference>FG123</reference>
<message>Internal issue recorded, please keep the reference for further
assistance with our help desk</message>
</error>
and for the HTML version: Viewable("/error.jsp", error);
<html>
<header><title>Error 500</title></header>
<body>
Error reference FG123.
Internal issue recorded, please keep the reference for further
assistance with our help desk.
</body>
</html>
Regarding MessageBodyWriter, it could be hard to go with it for "composition
of resources" and where the same wrapper is reused for each of them:
<wrapper><EntityA/><EntityB/><wrapper>
Viewable("/template1.jsp", wrapper);
<wrapper><entityC/><entityD/></wrapper>
Viewable("/template2.jsp", wrapper);
In order to resume and to have the ideas clear, the following can be
consider as "the" correct approaches:
1- httpContext.getRequest().getAcceptableMediaTypes().get(0)
2- Variant v = request.selectVariant(vs);
Could you please confirm?
Once again, thank you for your support and your time.
Regards,
exxos.
On Tue, Sep 7, 2010 at 4:10 PM, Paul Sandoz <Paul.Sandoz_at_oracle.com> wrote:
>
> On Sep 7, 2010, at 2:32 PM, exxos wrote:
>
> Thank you very much for this clarification.
>>
>> Implicitly behind this, there is still the need to determine which is the
>> MediaType to return ?
>>
>>
> Yes.
>
>
>
> 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.
>>
>>
> Yes.
>
>
>
> 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.
>>
>>
> Nor if the exception was thrown from a resource method. For example it
> could be thrown from a constructor, a sub-resource locator or a filter.
>
> There is currently no support for @Produces on an ExceptionMapper, which
> could potentially help. But i am not sure about that since message body
> writers can do that, although accept that does not work too well for
> Viewable. Generally responses to 4xx or greater don't have to obey the same
> constraints as 2xx responses for acceptable content. For example, what
> content should one return for a 406 (Not Acceptable) response?
>
> A different work around is to use variants for the set of media types that
> support error responses:
>
> List<Variant> vs = Variant.mediaTypes("text/html", "application/xml",
> "application/json");
> Variant v = request.selectVariant(vs);
>
> Jersey does add the content-type it will set, if concrete, to the request
> property:
>
> "com.sun.jersey.server.impl.uri.rules.HttpMethodRule.Content-Type",
>
> i could make that public property and then you can look that up. But i
> think it may be better to solve this by enabling access to the content-type
> and relaxing the reseting constraints.
>
> Paul.
>
>
>
> 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
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>
>