Mime type parameter matching - or lack

["Longton, Nigel" <Ni...@pimco.com>]

Hi,
We've noticed that CXF doesn't use mime type parameters for matching except for q and d. Is there a reason for this?
Our goal is to use a parameter to influence the shape of json or xml that is returned. We had to create a @Feature to override the default sort model for method selection, but now we are running into a problem with the Content-Type that CXF is using to select the message writer - it effectively uses the first mime type in the @Produces section whose type/subtype match the incoming Accept rather than the parameters that are on the incoming accept. An example
Consider a method of
@GET @Produces({"a/b", "a/b;x=y"}) Object getData() {}
When sent
                Accept = a/b;x=y, a/b
Will call a message body with content type of
                a/b
but the caller prefers a/b;x=y as it is listed first.

Have I misunderstood Mime types or is there a way to influence CXF?
The problem is in JAXRSUtils.intersectMimeType. When it sorts, the comparator ignores the mime type parameters and doesn't do a best match against the users types.

Nigel

This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute, alter or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmissions cannot be guaranteed to be secure or without error as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender, therefore, does not accept liability for any errors or omissions in the contents of this message which arise during or as a result of e-mail transmission. If verification is required, please request a hard-copy version. This message is provided for information purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments in any jurisdiction.  Securities are offered in the U.S. through PIMCO Investments LLC, distributor and a company of PIMCO LLC.

Re: Mime type parameter matching - or lack

[Sergey Beryozkin <sb...@gmail.com>]

Hi

As far as I know the custom parameters do not affect the selection 
algorithm - and the order in which they are listed is not taken into 
account.
Indeed, the client can try to affect the selection by including a 'q' 
property but if it is not possible then you can add a 'qs' parameter to 
Produces:

@Produces({"a/b;qs=0.9", "a/b;x=y"})

That should fix it, even though the JAX-RS text says nothing about the 
custom parameters affecting the process.

Thanks, Sergey



On 17/09/16 20:38, Longton, Nigel wrote:
> Hi,
> We've noticed that CXF doesn't use mime type parameters for matching except for q and d. Is there a reason for this?
> Our goal is to use a parameter to influence the shape of json or xml that is returned. We had to create a @Feature to override the default sort model for method selection, but now we are running into a problem with the Content-Type that CXF is using to select the message writer - it effectively uses the first mime type in the @Produces section whose type/subtype match the incoming Accept rather than the parameters that are on the incoming accept. An example
> Consider a method of
> @GET @Produces({"a/b", "a/b;x=y"}) Object getData() {}
> When sent
>                 Accept = a/b;x=y, a/b
> Will call a message body with content type of
>                 a/b
> but the caller prefers a/b;x=y as it is listed first.
>
> Have I misunderstood Mime types or is there a way to influence CXF?
> The problem is in JAXRSUtils.intersectMimeType. When it sorts, the comparator ignores the mime type parameters and doesn't do a best match against the users types.
>
> Nigel
>
> This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute, alter or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmissions cannot be guaranteed to be secure or without error as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender, therefore, does not accept liability for any errors or omissions in the contents of this message which arise during or as a result of e-mail transmission. If verification is required, please request a hard-copy version. This message is provided for information purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments in any jurisdiction.  Securities are offered in the U.S. through PIMCO Investments LLC, distributor and a company of PIMCO LLC.
>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/