Thanks Sergey. Let's keep an eye on what is going on for the JAXRS SPEC
clarification.
Iris Ding
--
View this message in context:
http://cxf.547215.n5.nabble.com/two-issues-in-org-apache-cxf-jaxrs-provider-DataSourceProvider-tp5745783p5745974.html
Sent from the cxf-dev mailing list archive at
On 02/07/14 10:58, Sergey Beryozkin wrote:
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://i
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 wel
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.
The other question is:
In ProviderFa
Hi
On 01/07/14 07:19, iris ding wrote:
Thanks Daniel for digging out the issue.
So how about below change to convert the ClassCastException to a 415
response?
public T readFrom(Class cls, Type genericType, Annotation[]
annotations,
MediaType type,
Thanks Daniel for digging out the issue.
So how about below change to convert the ClassCastException to a 415
response?
public T readFrom(Class cls, Type genericType, Annotation[]
annotations,
MediaType type,
MultivaluedMap heade
wrote:
>
>>
>> On Jun 30, 2014, at 9:07 PM, iris ding wrote:
>>
>>> Hi Guys,
>>>
>>> I think There are two issues in
>>> org.apache.cxf.jaxrs.provider.DataSourceProvider:
>>> Issue 1: ClassCastException if you post a FileDataSourc
30, 2014, at 9:38 PM, Daniel Kulp wrote:
>
> On Jun 30, 2014, at 9:07 PM, iris ding wrote:
>
>> Hi Guys,
>>
>> I think There are two issues in
>> org.apache.cxf.jaxrs.provider.DataSourceProvider:
>> Issue 1: ClassCastException if you post a FileDataSource
I’m still failing to see any issue. As far as the user is concerned it’s an
InputStream. Whether that is a ServeltInputStream, FileInputStream,
ByteArrayInputStream, etc… should be irrelevant. As long as it behaves
according to the InputStream contract, it shouldn’t matter.
That said, that
Johan,
Can I know the reason for your point?
Actually, the key reason for the issue 2 is not for available() usage. Let
me give an example for this issue:
If you deploy your application to Tomcat, the incomming InputStream might be
a tomcat class which implements ServletInputStream.
If you depl
Issue 2 is not an issue.
On Jun 30, 2014, at 7:47 PM, iris ding wrote:
> Thanks Daniel for your quick response.
>
> Although the javadoc for avaliable() is not promised to return the length.
> There also reasons we need to convert the incomming InputStream to a
> java.io.** .: The incomming in
Thanks Daniel for your quick response.
Although the javadoc for avaliable() is not promised to return the length.
There also reasons we need to convert the incomming InputStream to a
java.io.** .: The incomming inputStream might be a special type which only
applicable to the jee container you use
On Jun 30, 2014, at 9:07 PM, iris ding 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 In
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
14 matches
Mail list logo
