[
https://issues.apache.org/jira/browse/WINK-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729045#action_12729045
]
Nick Gallardo edited comment on WINK-47 at 7/8/09 9:17 PM:
-----------------------------------------------------------
To the broader issue of wildcard support, maybe it's a combination of the
equals() and isCompatible() that need to be accounted for. I'll go back to
Michael's example.
{code}
@Produces("text/*")
class ProviderA
@Produces("text/plain")
class ProviderB{code}
Given these two providers, let's consider two scenarios.
1. Client sends "text/plain"
In this scenario, although both providers are technically a match, the spec
states that we should map to the most specific one. The behavior remains
unchanged with what we have today. When you're building the list of possible
providers though, you could first check for equals(). If that works, breakout
immediately because you have the most specific match (provided that there are
no wildcards in the inbound mediatype). If the equals() fails, check the
isCompatible() to see if it at least matches based on the wildcard.
Either way, once we found the exact match for "text/plain", we just return that
and be done with it.
2. Client sends "text/*"
This is what I think Mike was getting at originally. Since we may not have a
specific provider for "text/*", everything that starts with "text/" is a
candidate. That means both ProviderA and ProviderB show up in the list. To
Michael's question about which one is then selected, I think it's ProviderB aka
"text/plain".
Not go chapter-and-verse, but take a look at section 3.8 of JAX-RS. I'm
interpreting step 5 to be where both are added to the list, because they're
compatible. Step 7 is where "text/plain" is put ahead of "text/*", and the
rest just plays out.
At least, that's my interpretation. Dustin brought up the fact that some of
this is also discussed in the Accept headers section of the HTTP spec, here:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1
was (Author: nickgallardo):
To the broader issue of wildcard support, maybe it's a combination of the
equals() and isCompatible() that need to be accounted for. I'll go back to
Michael's example.
{code}
@Produces("text/*")
class ProviderA
@Produces("text/plain")
class ProviderB{code}
Given these two providers, let's consider two scenarios.
# Client sends "text/plain"
In this scenario, although both providers are technically a match, the spec
states that we should map to the most specific one. The behavior remains
unchanged with what we have today. When you're building the list of possible
providers though, you could first check for equals(). If that works, breakout
immediately because you have the most specific match (provided that there are
no wildcards in the inbound mediatype). If the equals() fails, check the
isCompatible() to see if it at least matches based on the wildcard.
Either way, once we found the exact match for "text/plain", we just return that
and be done with it.
# Client sends "text/*"
This is what I think Mike was getting at originally. Since we may not have a
specific provider for "text/*", everything that starts with "text/" is a
candidate. That means both ProviderA and ProviderB show up in the list. To
Michael's question about which one is then selected, I think it's ProviderB aka
"text/plain".
Not go chapter-and-verse, but take a look at section 3.8 of JAX-RS. I'm
interpreting step 5 to be where both are added to the list, because they're
compatible. Step 7 is where "text/plain" is put ahead of "text/*", and the
rest just plays out.
At least, that's my interpretation. Dustin brought up the fact that some of
this is also discussed in the Accept headers section of the HTTP spec, here:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1
> 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.
