[jax-rs-spec users] [jsr339-experts] Re: The origin of MessageBodyWriter - when to check

From: Sergey Beryozkin <>
Date: Wed, 1 May 2013 10:47:12 +0100

Hi Santiago
On 26/04/13 13:55, Santiago Pericas-Geertsen wrote:
> Hi Sergey,
> It's a bit difficult to comment on this without looking at the test. Is this a TCK test that you're referring to? If so, which one?
Sorry for a delay. It's indeed a TCK test but I did not want to use the
list to discuss the specific TCK tests (I'd follow a proper procedure
for challenging the individual tests) but rather keep the question more
in 'scope' for this list, and besides I guess I can not even do that as
I've signed NDA :-)

However we've talked about this issue before, so here is my question in
some other words:

- custom Application registers a custom provider, typed like this:

public class MyProvider implements MessageBodyReader<Object>,
MessageBodyWriter<Object> {
     public boolean isReadable(Class c, ...) {
         return InputStream.class.isAssignableFrom(c);
     public boolean isWriteable(Class c, ...) {
         return InputStream.class.isAssignableFrom(c);

I honestly do not see how the 2.0 spec text can make a
standard/pre-packaged InputStream provider preferred to MyProvider above
when a resource method expects InputStream.

The spec needs to specific about the order of the 'origin' key (custom
vs pre-packaged) and furthermore, IMHO, it has to do an explicit text
about the pre-packaged provider taking a precedence in some cases,
because the

"primary key of generic type where providers
whose generic type is the nearest superclass of the object class are
sorted first and a secondary key of
media type" condition does not work because there's no spec requirement
that pre-packaged providers have to be typed on InputStream, etc, as
opposed to just 'Object'

What do you think ?

> -- Santiago
> On Apr 25, 2013, at 11:01 AM, Sergey Beryozkin<> wrote:
>> Hi Santiago, All,
>> The specification says:
>> "An implementation MUST support application-provided entity providers and MUST use those in prefer-
>> ence to its own pre-packaged providers when either could handle the same request.
>> "
>> We have a failing test. An application provider, typed on Object, is written to support some specific types like Boolean, InputStream, etc, and its isWritebale& isReadable checks that a given Object is of the supported type and returns true if yes, false if not.
>> The test still expects that the shipped/pre-packaged provider (presumably typed for example on Boolean or InputStream) is chosen.
>> The question boils down to what is the order of the 'origin' key. Does the specification mean that it is a tertiary key ? If yes then I'm accepting the test is valid, if not - concluding it is not.
>> Thanks, Sergey