[
https://issues.apache.org/jira/browse/WINK-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12728552#action_12728552
]
Michael Elman commented on WINK-47:
-----------------------------------
Ok, I thought about it and to tell you the truth I'm kinda confused about the
scenario.
For the context resolvers the spec states the following:
{quote}Get a context resolver for a particular type of context and media type.
The set of resolvers is first filtered by *comparing the supplied value of
mediaType with the value of each resolver's Produces*, ensuring the generic
type of the context resolver is assignable to the supplied value of
contextType, and eliminating those that do not match. If only one resolver
matches the criteria then it is returned. If more than one resolver matches
then the list of matching resolvers is ordered with those with the best
matching values of Produces (x/y > x/* > */*) sorted first. A proxy is returned
that delegates calls to ContextResolver.getContext(java.lang.Class) to each
matching context resolver in order and returns the first non-null value it
obtains or null if all matching context resolvers return null. {quote}
The spec states "comparing" for Media Types, it doesn't states that stars means
pattern comparison like Mike did in his first patch, and it doesn't states
"compatible", so I would believe that using isCompatible is incorrect.
So actually I believe that the current behavior is the correct one, but to
emphasize this I'll try to give the problematic use cases. Let's consider we
want to support patterns:
{co...@produces("text/*")
class ProviderA
@Produces("text/plain")
class ProviderB{code}
which provider will be returned for "text/*"?
ProviderA gives an exact match, but ProviderB will be returned...
Another question: should we support patterns like "text/plain*"?
In addition, I have check how the JAX-RS RI (Jersey) behaves on the Mike's unit
test, and it also fails.
So in general, I think we should decide if the whole scenario is valid before
trying to solve it :)
> honor media type wildcards
> --------------------------
>
> Key: WINK-47
> URL: https://issues.apache.org/jira/browse/WINK-47
> Project: Wink
> Issue Type: Bug
> Components: Common
> Affects Versions: 0.1
> Reporter: Mike Rheinheimer
> Fix For: 0.1
>
> Attachments: patch.txt, patch_02.txt
>
>
> This issue probably needs discussion, as it may be a spec interpretation
> issue. Please reference JAX-RS javadoc for
> javax.ws.rs.ext.Providers.getContextResolver here:
> http://jackson.codehaus.org/javadoc/jax-rs/1.0/javax/ws/rs/ext/Providers.html#getContextResolver(java.lang.Class,%20javax.ws.rs.core.MediaType)
> Currently, the implementation does not use the '*' character in a passed-in
> media type as a wildcard. Rather, it matches exactly by just allowing the
> LinkedHashMap.get to it's object compare. Attached is a patch with tests
> that demonstrate the proposed function, and a fix that supports it. All
> existing and new tests in wink-common and wink-server passed for me with this
> change.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
