We've had a user reporting an issue to do with CXF javax.activation.DataSource provider throwing an exception after a user typed 'javax.activation.FileDataSource' in the signature.
Given that the spec requires support for java.io.File it was easy to provide a support for javax.activation.FileDataSource OOB.
Now the user asks is it against the spec for a default provider to support a type not specifically mentioned in the spec.
IMHO the spec should clarify what MessageBodyReader supporting the interfaces required to be supported by the spec should do when it sees a concrete, well-known interface implementation.
Here are 3 proposed solutions:
1. Recommend that "Default MessageBodyReaders may support some concrete implementations" - the problem here is that we may have a portability issue between the implementations
2. Specify some of concrete implementations such as javax.activation.FileDataSource, and a couple of known JAXP Source classes.
3. Request that if concrete implementation class is typed in the method signature and it is different from the class MessageBodyReader uses to support a given interface then throw 500.
I think 3 may be reasonable - but may be we can relax it a bit with 2.