Hi Freeman
Can you move ReaderInputStream to the CXF core where CachedInputStream
and other IO utility code is located ?
Please also update the code which gets Reader.class and check it for
null first, and also drop a comment re the JMS transport, checking the
reader can make sense in all th
The other thing is, should JMS transport itself set ReaderInputStream as
InputStream on the message, as opposed to patching the JAX-RS code in
various places ?
Sergey
On 19/10/17 09:44, Sergey Beryozkin wrote:
Hi Freeman
Can you move ReaderInputStream to the CXF core where CachedInputStream
Yeah, set ReaderInputStream instead of Reader for the JMS transport is a better
solution. If no objection I will go this way.
－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
> On Oct 19, 2017, at 4:50 PM, Sergey Beryozkin wrote:
>
> The other thing is, should
Hi Freeman
Reader may likely need to be set too for SOAP, and I recall checking
Reader somewhere else too (will double check now), but I thought may be
the transport can set both Reader and InputStream, hmm, that is an extra
instance though, may be lets start with moving ReaderInputStream to t
Sure, will do!
－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
> On Oct 19, 2017, at 5:05 PM, Sergey Beryozkin wrote:
>
> Hi Freeman
>
> Reader may likely need to be set too for SOAP, and I recall checking Reader
> somewhere else too (will double check now),
If we assume that checking Reader can be useful in the general sense,
then may be lets keep things as is, with the minor cleanup only...
Sergey
On 19/10/17 10:05, Sergey Beryozkin wrote:
Hi Freeman
Reader may likely need to be set too for SOAP, and I recall checking
Reader somewhere else too
I modified the JMS transport part and set ReaderInputStream instead of Reader,
running all tests now, will see what I can get.
If I run into any test failure, I will keep things as is, just clean up.
－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
> On Oct 19,
Siggen opened a new pull request #322: [CXF-7533] Fix non-fonctional 'setBus'
method.
URL: https://github.com/apache/cxf/pull/322
Fix for https://issues.apache.org/jira/browse/CXF-7533
Thanks you !
This is an automated
asfgit closed pull request #322: [CXF-7533] Fix non-fonctional 'setBus' method.
URL: https://github.com/apache/cxf/pull/322
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull
andymc12 closed pull request #321: Check @Priority annotations on providers
when sorting
URL: https://github.com/apache/cxf/pull/321
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a fo
If using the TEXT stuff for JMS, it should remain as a Reader on the message if
at all possible. Converting from Reader to InputStream is not a trivial
operation and does enact a performance penalty. All of the SOAP pathways for
JMS should be OK for use of a Reader so that we can avoid the en
Some JAX-RS providers check Reader or XMLStreamReader if InputStream is
null.
But at the moment, Freeman, please do a bit of cleanup as agreed, and
then we can check if the use ReaderInputStream can be avoided at all.
Sergey
On 19/10/17 19:47, Daniel Kulp wrote:
If using the TEXT stuff for JM
andymc12 opened a new pull request #323: Handle @Priority on ExceptionMappers
URL: https://github.com/apache/cxf/pull/323
Like PR #321, we need to handle the `@Priority` annotation on exception
mappers.
This is an automated m
Hi Sergey,
Cleaned up accordingly.
Cheers
－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
> On Oct 20, 2017, at 5:59 AM, Sergey Beryozkin wrote:
>
> Some JAX-RS providers check Reader or XMLStreamReader if InputStream is null.
> But at the moment, Freeman, p
14 matches
Mail list logo
