[
https://issues.apache.org/jira/browse/CXF-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118181#comment-14118181
]
Sergey Beryozkin commented on CXF-5970:
---------------------------------------
Hi Romain
Sorry for a delay. This is what the spec says:
{noformat}
4.2.3
Declaring Media Type Capabilities
Message body readers and writers MAY restrict the media types they support
using the @Consumes and
@Produces annotations respectively. The absence of these annotations is
equivalent to their inclusion with
media type (“*/*”), i.e. absence implies that any media type is supported. An
implementation MUST NOT
use an entity provider for a media type that is not supported by that provider.
When choosing an entity provider an implementation sorts the available
providers according to the media
types they declare support for. Sorting of media types follows the general
rule: x/y < x/* < */*, i.e. a
provider that explicitly lists a media types is sorted before a provider that
lists */*.
{noformat}
As you see, checking custom "*/*" providers before custom providers with more
specific types is non compliant.
The moment say TomEE will let it happen you'd get some users asking the next
day why my more specific provider is not checked first any longer :-).
However, I can imagine a case where a user registers a 3rd party
"application/json" provider which takes on processing type A (due to misleading
the runtime by asserting it can handle it by returning 'true' from
isWriteable() and/or isReadable()) but fails because it actually does not know
how to handle A when asked to. And thus a wildcard provider which does know how
to handle A will have no chance. Reversing the order might help in such cases,
assuming a wildcard provider is 'well-behaved' i.e, it won't do the same with
respect to type B which is known to the "application/json" provider but not to
this wildcard provider.
So yes, there's a possibility that disabling a sorting would help in such edge
cases but I don't think we can ever convince the expert group that the order of
the registration should be taken into the consideration, example, as you said,
that won't hold anyway in the auto-discovery cases.
IMHO, if a user ever faces such a conflict of MBW/MBR providers, the spec
compliant way would be to avoid registering one of these providers and for
example register a custom JAX-RS 2.0 WriterInterceptor or ReaderInterceptor,
check the types there (media types, the entity parameter types) and read or
write using a the right provider to avoid the ambiguities. Another option is to
register a composite MBR or MBW that will do the same.
I.e, IMHO the way to sort such cases is to introduce custom higher-level
providers that can delegate appropriately as opposed to relying on the order of
the registration - the latter might work but will unlikely offer a portable or
reliable solution (if we deal with the auto-discovery).
Having said all of the abovem, I can add the option to disable the sorting (not
at the jaxrs:server but at JAXRSServerFactoryBean) to quickly validate that
keeping the order of the registration actually helps, this can be handy as a
quick test that a more specific provider can be 'guilty' of consuming the type
it can not actually handle
Thanks
> review org.apache.cxf.jaxrs.provider.ProviderFactory.Message*ReaderComparator
> -----------------------------------------------------------------------------
>
> Key: CXF-5970
> URL: https://issues.apache.org/jira/browse/CXF-5970
> Project: CXF
> Issue Type: Bug
> Reporter: Romain Manni-Bucau
> Assignee: Sergey Beryozkin
> Fix For: NeedMoreInfo
>
>
> Actually the task can be rephrase saying rework
> org.apache.cxf.jaxrs.provider.ProviderFactory#*Comparators
> Current implementations don't seem to have an absolute order which means
> sorting is not as deterministic as it should be under java >= 7.
> Other point is as a user you set a List of providers (you probably already
> sorted if important) so you want to ensure *your* order is respected at
> runtime (ie
> org.apache.cxf.jaxrs.provider.ProviderFactory#message[Readers|Writers]
> respect it).
> If you think this sorting is important maybe introducing in
> org.apache.cxf.jaxrs.AbstractJAXRSFactoryBean and
> org.apache.cxf.jaxrs.provider.ProviderFactory a boolean sortProviders can be
> enough to prevent calling sortXXX().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
