Hi
On 02/07/14 02:45, iris ding wrote:
Thanks Sergey for your fix for this issue.
But actually I have a question for the fix as it is against spec for support
of subclasses or concrete implementations for DataSource. I have put my
question in https://issues.apache.org/jira/browse/CXF-5835 as well.
I doubt it is against the spec for a default provider to give a best
effort and support some of DataSource implementing classes from
javax.activation OOB. It would probably be reasonable to throw an
exception too but it is probably too harsh given that FileDataSource is
the only well-known DataSource implementation that we can support for
'free' given that the spec requires support for File.
Of course, we can say that if a user typed ByteArrayInputStream, then
should we copy InputStream into ByteArrayInputStream too based on the
fact ByteArrayInputStream is a well known type. But it won't work right
now. However we'd support DOMSource even though the spec requires
supporting Source only, etc.
The only reason FileDataSource is supported now is that File has to be
supported per the spec.
That said I will request a clarification in the spec. My preference
would be to have a text added along the lines of "Default Message Body
Readers MAY optionally support well-known implementations of interfaces
required to be supported by default..."
Note it is the issue only for Message Body Readers, obviously Message
Body Writer must support concrete implementations.
The other question is:
In ProviderFactory.initBaseFactory(), CXF will add DataSourceProvider by
default. Is there a way to remove the built-in CXF DataSourceProvider but
using my own one?
The custom providers are always preferred, so just register your custom
implementation.
Cheers, Sergey
--
View this message in context:
http://cxf.547215.n5.nabble.com/two-issues-in-org-apache-cxf-jaxrs-provider-DataSourceProvider-tp5745783p5745869.html
Sent from the cxf-dev mailing list archive at Nabble.com.
