cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin (JIRA)" <>
Subject [jira] [Commented] (CXF-5835) Two issues in org.apache.cxf.jaxrs.provider.DataSourceProvider
Date Tue, 01 Jul 2014 12:45:26 GMT


Sergey Beryozkin commented on CXF-5835:

I've added an explicit support for FileDataSource. It does not really make sense to have in
the method signature because it implies a temporary file will need to be created, and you
will see a warning in the logs coming from BinaryDataProvider. I'm only adding this code because
as it happens TCK enforces MBR support for File and indeed because having class cast exception
is not cool.

I agree about an InputStream related issue being not an issue. It is strange other implementations
copy it in memory, it can be a massive stream after all.

Cheers, Sergey

> Two issues in org.apache.cxf.jaxrs.provider.DataSourceProvider
> --------------------------------------------------------------
>                 Key: CXF-5835
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-RS
>    Affects Versions: 3.0.0
>            Reporter: iris ding
>             Fix For: 2.7.12, 3.0.1
> Issue 1: ClassCastException if you post a FileDataSource in your resource class: 
> @Path("providers/standard/datasource")
> public class DataSourceResource {
>     @POST
>     public DataSource postDataSource(FileDataSource  ds) {
>         return ds;
>     }
>    }
> The error stack is like below:
> Caused by: java.lang.ClassCastException: Cannot cast class org.apache.cxf.jaxrs.ext.multipart.InputStreamDataSource
to class javax.activation.FileDataSource
> 	at java.lang.Class.cast(
> 	at org.apache.cxf.jaxrs.provider.DataSourceProvider.readFrom(
> 	at org.apache.cxf.jaxrs.utils.JAXRSUtils.readFromMessageBodyReader(
> 	at org.apache.cxf.jaxrs.utils.JAXRSUtils.readFromMessageBody(
> 	at org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameter(
> 	at org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameters(
> 	at org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(
> 	at org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(
> 	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
> Since there are several implementation class for DataSource, we can not use the logic
>     public T readFrom(Class<T> cls, Type genericType, Annotation[] annotations,

>                                MediaType type, 
>                                MultivaluedMap<String, String> headers, InputStream
>         throws IOException {
>         DataSource ds = new InputStreamDataSource(is, type.toString());
>         return cls.cast(DataSource.class.isAssignableFrom(cls) ? ds : new DataHandler(ds));
>     }
> Issue 2: Return the original InputStream directly in InputStreamDataSource.getInputStream().
> I have checked Jersy and Wink's implementation for this part, both of them will replace
the incomming InputStream with ByteArrayInputStream. Using this way, the inputStream.available()
will be correctly be called.
> My resource  can run successfully both in Jersey and Wink. But failed with CXF. The resource
class snippet is like below:
>     public Response post(DataSource dataSource) {
>         Response resp = null;
>         try {
>             InputStream inputStream = dataSource.getInputStream();
>             byte[] inputBytes = new byte[inputStream.available()];
>             ..........
>     }
> From my understanding, we need to this conversion for InputStream to convert it to a
standard Because only in such way, we can return to users a
standard InputStream. For example, the incomming InputStream might be a specific type to J2ee

This message was sent by Atlassian JIRA

View raw message