Re: Mime type parameter matching - or lack

2016-09-19 Thread Sergey Beryozkin

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/


Mime type parameter matching - or lack

2016-09-17 Thread Longton, Nigel
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.