Just an update as the JAX-RS section of our EE 9.1 TCK results is currently the 
largest non-passing section.

A lot of the issues appear to be around sorting of the JAX-RS Providers.  I've 
been poking at the code, getting tests to pass making small tweaks.  This 
usually results in one test passing but several tests failing.  This is often 
how it goes at the finish line when you're down to just a few tests.

We had our own non-compliant sorting code that I have successfully removed, 
gaining us some passes at the expense of an extra failure or two (still net 
positive change).  This code was not complete or compliant.  I suspect we 
needed it because CXF was seeing our JSON-B and JSON-P providers as supplied by 
the application and this negatively affects sorting, making our impls compete 
with anything user-supplied.  User supplied Providers must win against any 100% 
equivalent system Provider.

 - 
https://github.com/apache/tomee/commit/bdfb7ce50e9ba5f2c875867469c60cb5739ae0eb

This approach unfortunately does not help us pass the related JAX-RS Client 
test that have the same need for JSON-B and JSON-P providers and compliant 
sorting.  It was also filled with excessive undocumented and untested system 
properties.  It's all gone now.


I don't yet of a complete view of what is lacking in the @Provider sorting in 
CXF yet, but I do see one large gap I am working on.  At the moment CXF will 
sort these in the reverse order

        class ShapeReader implements MessageBodyReader<Shape> {}
        class SquareReader implements MessageBodyReader<Square> {}
        class ObjectReader implements MessageBodyReader<Object> {}

With Square being a subclass of Shape, which is a subclass of Object, the 
correct sorted order of precedence should be: SquareReader, ShapeReader, 
ObjectReader.  We're getting the opposite, so the most generic @Provider is 
winning and tests are failing.

The trick is code to accurately find and resolve the 'Foo' value in a 
declaration like `MessageBodyReader<Foo>`.  Working on that now.  Happy path is 
all good, edge cases in progress.


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to