[ 
https://issues.apache.org/jira/browse/CXF-7638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16356857#comment-16356857
 ] 

ASF GitHub Bot commented on CXF-7638:
-------------------------------------

sberyozkin commented on issue #379: [CXF-7638] Only register provider if it 
implements specified contracts
URL: https://github.com/apache/cxf/pull/379#issuecomment-364092698
 
 
   OK, I've debugged the test and recall a bit better now what I was trying to 
do with these supported types. FYI, I found implementing all of these 
Configuration/Configurable very challenging, I recall typing and thinking I was 
not really sure if I was on the wrong or right path :-) as the original docs 
were quite compact, and the interpretation of some signatures can vary even 
today.
   
   My own initial understanding was that it was primarily about supporting new 
filters/interceptors, given that in 2.0 (and in 2.1 for the most 
non-filter/non-interceptor interfaces) no priorities existed for MBR/MBW (and 
today for ex for ExceptionMapper or ParamConverterProvider) while many register 
methods accept the priorities or have the default priorities which have no any 
processing reqs for the last 2 interfaces and in 2.0 - for MBR/MBW as well.  
Hence those supported types lists (for client/server) only included the new 2.0 
filter/interceptors and only later I started adding the support for the wider 
set of standard types. 
   
   But  anyway, the patch looks fine, except that the supported contracts still 
need to be passed in, this is to protect Server-side Configuration from 
accepting ClientRequest/ResponseFilter and the client side Configuration - from 
ContainerRequest/ResponseFilter.   These supported types lists may need to be 
expanded for the client and server (to include all other standard types which 
make sense on the client and the server) such that a provider can not be 
registered under SomeNonJaxrsContract - which should be rejected
   
   Thanks    

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> JAXRS CTS/TCK issue:  register(...) should ignore components when invalid 
> contracts are passed in
> -------------------------------------------------------------------------------------------------
>
>                 Key: CXF-7638
>                 URL: https://issues.apache.org/jira/browse/CXF-7638
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-RS
>    Affects Versions: 3.2.2
>            Reporter: Andy McCright
>            Assignee: Andy McCright
>            Priority: Major
>             Fix For: 3.2.3
>
>
> We're seeing some failures when running the JAX-RS 2.1 TCK - particularly 
> around the register method. The javadoc states that the implementation MUST 
> ignore the component if the call to register specifies a contract (interface) 
> that the component does not implement.
> So, for example, suppose somebody calls code like this:
>  
> public class MyProvider implements MessageBodyWriter<MyObject> ...
>  
> Client c = ClientBuilder.newClient();
> c.register(MyProvider.class, ContainerRequestFilter.class); // should ignore
> c.register(new MyProvider, ExceptionMapper.class, MessageBodyReader.class); 
> // should ignore
> Map<Class, int> contractPriorityMap = new HashMap<>();
> contractPriorityMap.put(ClientResponseFilter.class, 20);
> c.register(MyProvider.class, contractPriorityMap); // should ignore
> c.register(new MyProvider.class, contractPriorityMap); // should ignore
>  
> The TCK tests basically check that nothing gets registered when a passed-in 
> contract is not assignable to the provider class.  And scenarios like the 
> four mentioned above are failing.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to