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 ?
Sergey
> -- Santiago
>
> On Apr 25, 2013, at 11:01 AM, Sergey Beryozkin<sberyozkin_at_talend.com> 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
>