cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin (JIRA)" <>
Subject [jira] [Commented] (CXF-6307) Wrong select the message body reader
Date Fri, 03 Apr 2015 15:38:53 GMT


Sergey Beryozkin commented on CXF-6307:

Just a short summary based on the anslysis/conversations I've done so far.

- MBR can depend on the declarative Consumes support or do the checks dynamically in its isReadable.
Both options are valid/compliant. Either option can be used independently or both options
can be combined.
- MBR can provide a valid implementation of "Boolean/etc for text/plain only" by using either
declarative Consumes or dynamic checks. Spec can not/does not enforce which approach is used
to implement a given requirement 
- This test is technically valid
- This test should not be at the CTS level but at a concrete JAX-RS implementation level (example,
at RI level) because it was written with the assumption that a default MBR uses a declarative
approach as opposed to a dynamic check approach.

Base on the above, but also on the fact that having all of CXF default providers (many of
them with wildcard Consumes as per the spec) will slowdown a selection process but also be
a very sensitive operation in the short term, my recommendation is to challenge this test.

I'm not opposed in principle to refactoring ProviderFactory and hence I will keep this issue
open and will review how this can be addressed. But given that we have major releases coming
in now, and also because it is very important that a validity of MBRs doing the dynamic checks
is enforced, IMHO the faster solution to getting behind this test is to challenge it

Cheers, Sergey  

> Wrong select the message body reader
> ------------------------------------
>                 Key: CXF-6307
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-RS
>    Affects Versions: 3.0.3
>         Environment: Windows
>            Reporter: Neal Hu
>             Fix For: 3.0.5
> This is a CTS testcase, the resource class is like this:   
>    @POST
>     @Path("boolean")
>     public Boolean postBoolean(Boolean bool) {
>     	if(bool){    		 
>     		throw new WebApplicationException(Status.NOT_ACCEPTABLE);
>     	}
>         return false;
>     }
> The application provided provider is like this:
> public class MyReader implements MessageBodyReader<Boolean> {
>     @Override
>     public boolean isReadable(Class<?> type, Type type1, Annotation[] antns, MediaType
mt) {
>     	return type== Boolean.class;
>     }
>     @Override
>     public Object readFrom(Class<Object > type,
>                              Type type1,
>                              Annotation[] antns,
>                              MediaType mt, MultivaluedMap<String, String> mm,
>                              InputStream in) throws IOException, WebApplicationException
> 		return Boolean.valueOf("true");        
>     }
> }
> The request
> Content-Type:text/plain
> Accept:text/plain 
> Method:POST
> Body:false
> According to jsr339 section 4.2.4 Standard Entity Providers java.lang.Boolean, java.lang.Character,
java.lang.Number Only for text/plain. Corresponding primitive types supported via boxing/unboxing
> An implementation MUST support application-provided entity providers and MUST use those
in preference to its own pre-packaged providers when either could handle the same request.
More precisely, step 4 in Section 4.2.1 and step 5 in Section 4.2.2 MUST prefer application-provided
over pre-packaged entity providers.
> 4.2.1 Message Body Reader
> 3. Select the set of MessageBodyReader classes that support the media type of the request,
see Section
> 4.2.3.
> 4. Iterate through the selected MessageBodyReader classes and, utilizing the isReadable
method of
> each, choose a MessageBodyReader provider that supports the desired Java type.
> It says the entity providers should be sorted by media type firstly then(the media type
is the same) on Section 4.2.1 and step 5 in Section 4.2.2 MUST prefer application-provided
over pre-packaged entity providers. So org.apache.cxf.jaxrs.provider.PrimitiveTextProvider
should be selected as its media type MUST be text/plain and the application provider's media
type is */*.(x/y>x/*>*/*)
> So at this point the CTS expected response code is 200 instead of 406, the application
provided provider should not be chosen.

This message was sent by Atlassian JIRA

View raw message