Its really a per-media type, per media type parameter question. I
don't think there's any general rule we can apply to parameter
matching. Either we choose to ignore parameters as we do now or we
choose to treat them as being significant (even if they aren't).
Marc.
On Apr 9, 2008, at 10:10 AM, Bill Burke wrote:
>
>
> Marc Hadley wrote:
>> On Apr 9, 2008, at 8:30 AM, Bill Burke wrote:
>>> Consider this resource:
>>>
>>> @Consumes("application/xml;schema=bar")
>>> @GET
>>> public String get();
>>>
>>>
>>> Is it compatible with the content-type of "application/
>>> xml;schema=foo"?
>>>
>>> My thinking is that it is not compatible. Why?
>>>
>>> Consider this example:
>>>
>>> Accept: application/xml;schema=foo;q=1.0, application/
>>> xml;schema=bar;q=0.5
>>>
>>> Content-type: application/xml;schema=stuff
>>>
>>>
>>>
>>> The resource:
>>>
>>> @Path("/")
>>> public class MyESB {
>>>
>>> @Produces("application/xml;schema=foo")
>>> @Consumes("application/xml;schema=junk")
>>> public String method1() {}
>>>
>>>
>>> @Produces("application/xml;schema=bar")
>>> @Consumes("application/xml;schema=stuff")
>>> @GET
>>> public String method2() {}
>>> }
>>>
>>>
>>> From the current spec implementation(if i understand the rules
>>> correctly) with this request, method1 will be matched because the
>>> Accept precedence and my application will fail as the XML document
>>> sent will be incompatible with method 1.
>>>
>> Media type matching ignores parameters so either method would be
>> considered compatible. Method 1 would be matched since its it has
>> the highest q in the accept.
>
> Is this a JSR311 thing or W3C thing? If jSR311, then it should be
> changed.
>
> Bill
>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.