On Apr 8, 2009, at 8:13 AM, Tatu Saloranta wrote:
> On Tue, Apr 7, 2009 at 6:05 AM, Marc Hadley <Marc.Hadley_at_sun.com>
> wrote:
>> On Apr 7, 2009, at 4:22 AM, Paul Sandoz wrote:
>>>
>>> This is a known issue in JAX-RS.
>>>
>>> I think there is a way to fix this in Jersey by sorting the
>>> message body
>>> readers/writers such that readers/writers with the most specific
>>> generic
>>> type occur first and thus the isWriteable/isReadable if the more
>>> specifc
>>> generic types are called first. (Such general sorting is non-
>>> trivial for
>>> complex types, and there may be more than one solution, but for
>>> Class types
>>> it is easy).
>>>
>> Note that sorting of providers based on closeness of generic type is
>> required by JAX-RS 1.1, see step 4 of section 4.2.2 in the 1.1
>> draft spec
>> (https://jsr311.dev.java.net/drafts/spec20090313.pdf). This
>> corresponds to
>> change C004 in the chnagelog
>> (https://jsr311.dev.java.net/drafts/changelog.1.1.html).
>
> Thanks! I hope something along the lines of what Paul was suggesting
> could be made to work.
Yes, it should work for most cases (see below for more details).
Some points:
- application registered providers always take precedence over system-
registered providers
(those that are registered in META-INF/services).
- system registered providers take precedence based on order in the
class path.
I think there is a edge case for JAXB objects.
Say that the jersey-son module is in the class path. This means that
for the media type "application/json" or "application/xxx+json" and
classes annotated with @XmlType or @XmlElement that JSON/JAXB reading/
writing will be enabled.
If there is another general object-based JSON reader/writer registered
then it will not work under the following conditions
- the class is a JAXB annotated class.
- the reader/writer is registered as a system provider; and
- jersey-json is in the classpath and is before that of the object-
based JSON reader/writer, Note that jersey-json will
be shipped with GF so IIUC web apps jersey-json will take precedence.
> I understand that automated ranking is a
> non-trivial problem, even with Class - parametrized body
> readers/writers.
>
> But even if it was something as simple as de-prioritizing anything
> that declares itself to handle Object.class would help in this
> particular case.
>
Perhaps the developer (of a provider) could also provide a sorting
function to act as a tertiary key?
Paul.