On Aug 9, 2010, at 11:10 AM, Christian Helmbold wrote:
>
>
>> Do you intend to have separate MBWs for different charsets or be
>> more dynamic
>> about the charset to utilize?
>
> My intention is to be more flexible. A resource method could be
> annotated with
> @Produces("text/html") and the actual encoding could be set
> separately with the
> MBW. My intention is not to provide several encodings with different
> MBWs, since
> everything should be UTF-8 in my opinion ;-)
>
Then i think the best way to guarantee this is to modify the content-
type in your MBW to declare the charset to be UTF-8 :-)
>>>> It should work if declaring on the resource method/class.
>>>
>>> Yes, it does. What is the reason, that it doesn't work with the
>>> MessageBodyWriter?
>>>
>>
>> An oversight, but it also introduces some interesting problems to
>> solve. The
>> @Produces on the MBW may not be concrete. Which @Produces takes
>> priority? Does
>> one merge the parameters, if so which ones takes priority if two of
>> the same
>> name are declared, and how does one compare the parameter names,
>> are they are
>> case insensitive or not (IIRC that is specific to the definition of
>> the
>> parameter)
>
> Interesting question! I think that is a fundamental problem with the
> method
> level content negotiation. If resource methods would produce a
> "neutral" without
> a media type result,
It can, just do not declare the @Produces on a resource method. Then
the content-type will be derived from the @Produces on MBWs and the
acceptable media types. And if the MBW does not like the derived
content-type it can override it.
> that would be rendered depending on the clients needs,
> there would be a single place to handle content negotiation, so that
> there
> wouldn't be a conflict. But that is pure theory ...
>
One can view the JAX-RS conneg in this respect as a sort of filtering.
Some resource methods may filter but yet produce no concrete media
type and then defer more specifics to MBWs or their own algorithm.
>> I suspect if you intend to say support the charset as a prefix of
>> the template
>> (or if it is defined in the template, can freemarker do that?)
>
> Yes, the encoding can be set within a template or per template
> through Java
> code. But as I've already said, I don't plan to support different
> encodings of
> the same entity.
>
OK.
Paul.