The second? Same reason I wouldn't change the JVM if I used Guava. you are confusing impl with Interface.
/je On Jun 30, 2014, at 9:02 PM, Daniel Kulp <[email protected]> wrote: > > I’m not sure the first one is something I’d consider bug either. Per spec, > we need to just support “DataSource” as a parameter type. Not any of the > subclasses or concrete implementations. > > Wink actually has a test that asserts that using: > public DataSource postDataSource(FileDataSource ds) > > would result in a HTTP failure. That said, a classCastException is probably > not the BEST error here, but it’s certainly not wrong. > > Anyway, not a critical bug. Potentially a feature request. Likely > something you could implement your own provider for if you really need it. > > Dan > > > > On Jun 30, 2014, at 9:38 PM, Daniel Kulp <[email protected]> wrote: > >> >> On Jun 30, 2014, at 9:07 PM, iris ding <[email protected]> wrote: >> >>> Hi Guys, >>> >>> I think There are two issues in >>> org.apache.cxf.jaxrs.provider.DataSourceProvider: >>> Issue 1: ClassCastException if you post a FileDataSource in your resource >>> class: >>> Issue 2: Return the original InputStream directly in >>> InputStreamDataSource.getInputStream(). >>> >>> >>> I have created a JIRA in >>> https://issues.apache.org/jira/browse/CXF-5835 and put more details there. >>> >>> Would you take a look at the problem and see whether we can make any >>> modification for it? >>> >> >> The second one is NOT a bug and should not be fixed. That’s a bug in your >> code. The javadoc for “available()” specifically says: >> >> "Note that while some implementations of InputStream will return the total >> number of bytes in the stream, many will not. It is never correct to use the >> return value of this method to allocate a buffer intended to hold all data >> in this stream." >> >> CXF tries hard to stream everything (including attachments). Thus, the >> “available()” method likely will only return the number of bytes that have >> been received so far by the server which could be MUCH less than the full >> length of the attachment. >> >> -- >> Daniel Kulp >> [email protected] - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com > > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com >
