On 25/05/12 00:57, Bill Burke wrote:
>
>
> On 5/24/12 5:15 PM, Sergey Beryozkin wrote:
>> Hi Bill
>> On 24/05/12 18:44, Bill Burke wrote:
>>>
>>>
>>> On 5/24/12 12:37 PM, Sergey Beryozkin wrote:
>>>> That effectively makes isReadable, isWritable useless. Some
>>>> 'well-behaved' providers may have written in its isReadable:
>>>>
>>>> if (InputStream.class == class || isPrimitive(class)) {
>>>> return false;
>>>> }
>>>>
>>>
>>> Ooops! Your isReadable() forgot the possibility of ByteBuffer, byte[],
>>> char[] (arrays aren't primitive types), java.io.Reader, java.io.File,
>>> and DataSource. Not to mention any other possible custom low-level types
>>> somebody might want to add: i.e. Netty's or Mina's ChannelBuffer,
>>> Resteasy's MarshalledEntity, etc. etc. etc.
>>>
>> The chance of the resource method returning
>> ConcurrentHashMap representing the json array and thus falling into the
>> 'hands' of catch-all JSON provider is very very negligible and when it
>> arises it would be a good idea for the developers to actually write a
>> custom MBR or MBW.
>>
>
> You're missing the whole point. Users often use InputStream, File,
> DataSource, StreamingOutput, and byte[]. They also often have the
> Jackson provider installed too. So, I know from experience that this
> issue exists. We actually *already* have this matching algorithm by
> default because of this issue.
This issue exists because some providers assume that all the types are
theirs, not because the algorithm for choosing the providers is faulty.
This issue also exists when the implementations are not capable of
getting multiple endpoints within the same war up and using the specific
per-endpoint providers.
Sometimes such custom providers affect the flow as in case of the
InputStream. But I think their right to assert that they want to deal
with a given type must be preserved.
If I were to write a controlling or optimized XML provider which is
'conscious' of making sure that all the XML payloads go via it, example,
those to be read into POJOs and those consumed as InputStreams, then I'd
be out of luck.
As I said the proposed solution is to make sure that those all-consuming
providers which blindly assert they can deal with any type do not
interfere. Unfortunately, it may lead to the providers who do consume
all/some types and know what to do with all of those types being
side-tracked in favor of the default built-in providers which do not
even care what is being copied via them or what formats are consumed or
produced.
>
>> The chance of the users registering the custom provider supporting
>> multiple types is much higher IMHO
>>
>
> Yes, but its unlikely to have a custom provider that conflicts with a
> built in one that is specific to one of the "low-level" Java types
> mentioned above.
>
What it shows that the earlier argument about Mina's ChannelBuffer and
friends was not quite to the point because we are really talking about
the default providers for the types (InputStream, primitives) that are
to be supported by the implementation and happen to by bypassed by the
all-consuming custom providers.
Anyway. I recognize the issue exists. I'm not happy with the proposed
solution. I see it works in the examples that you gave but concerned it
will upset more sophisticated providers. But I do not have much to offer
instead but only suggesting to get custom providers registered when is
really needed or introducing multiple endpoints to avoid the conflicts.
Sergey