[
https://issues.apache.org/jira/browse/WINK-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nadav Fischer reopened WINK-53:
-------------------------------
You're completely right that the previous implementation was incorrect, but
after re-thinking this, I think that we are missing some functionality by using
the == (thanks go to Eli Baram for pointing this out)
Consider this scenario:
Given the following class hierarchy, where B inherits from A, and C and D
inherit from B:
{noformat}
A
|-B
|-C
|-D
{noformat}
and a Provider for class B (let's call it BProvider :-)), if we simply use ==
for the isReadable, then BProvider will not be picked up for an entity of type
A (assuming the media type is not the issue), even though it shouldn't be a
problem.
I think that what we want to do is reverse the order of classes in the
isAssignableFrom invocation in isReadable so that C and D entities won't be
picked up, but A will be, like so:
instead of this
{code}
return type != null && InputStream.class.isAssignableFrom(type);
{code}
do this
{code}
return type != null && type.isAssignableFrom(InputStream.class);
{code}
What do you think?
> MessageBodyReader.isReadable methods should do straight ==
> ----------------------------------------------------------
>
> Key: WINK-53
> URL: https://issues.apache.org/jira/browse/WINK-53
> Project: Wink
> Issue Type: Bug
> Components: Common
> Affects Versions: 0.1
> Reporter: Bryant Luk
> Assignee: Bryant Luk
> Priority: Minor
> Fix For: 0.1
>
> Attachments: WINK-53.patch
>
>
> In some cases the built in MessageBodyReaders providers's isReadable method
> does an isAssignableFrom. This should just be a straight == instead.
> For instance in InputStreamProvider:
> public boolean isReadable(Class<?> type, Type genericType, Annotation[]
> ann
> MediaType mediaType) {
> - return type != null && InputStream.class.isAssignableFrom(type);
> + return type != null && InputStream.class == type;
> }
> If the method parameter were:
> @GET
> public void getMethod(FileInputStream fis) {
> }
> we get a 500 back (because I think the injection throws) instead of a 415. I
> can fix this up.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
