You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by cchepelov <gi...@git.apache.org> on 2017/08/31 20:29:52 UTC
[GitHub] cxf pull request #309: [CXF-7491] Fork Stax & XSLT interceptors to make them...
GitHub user cchepelov opened a pull request:
https://github.com/apache/cxf/pull/309
[CXF-7491] Fork Stax & XSLT interceptors to make them Charset-aware
per https://issues.apache.org/jira/browse/CXF-7491
this implements "solution 3" described there; forking the Stax & XSLT transform interceptors to make them charset-aware, not blind "always UTF-8" as previously
+ updates the tests to cover for this
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/cchepelov/cxf cxf-7491_nonutf8-interceptor
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cxf/pull/309.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #309
----
commit 56dd9e31ff7b403191294592a3fa0bb73ce0c780
Author: Cyrille Chépélov <cc...@transparencyrights.com>
Date: 2017-08-31T20:28:03Z
[CXF-7491] Fork Stax & XSLT interceptors to make them Charset-aware
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] cxf issue #309: [CXF-7491] Fork Stax & XSLT interceptors to make them Charse...
Posted by cchepelov <gi...@git.apache.org>.
Github user cchepelov commented on the issue:
https://github.com/apache/cxf/pull/309
Thanks for the feedback @sberyozkin
As noted in the JIRA ticket, I hesitated between simply updating the existing interceptors and forking/deprecating. The reason why I went with the latter is in order to avoid making a breaking interface change for users of _subclasses_ of these interceptors, which seemed to be an excessive surprise in a possible 3.1.(x+1) release. In the patch as it is now, the **features** are updated to use the new interceptors.
Do you feel I overestimated the inconvenience to such subclassers, at the expense of leaving (effectively) dead/worse code around ? I'll gladly switch to the break-but-improve-in-place strategy if this is preferred.
---
[GitHub] cxf issue #309: [CXF-7491] Fork Stax & XSLT interceptors to make them Charse...
Posted by sberyozkin <gi...@git.apache.org>.
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/309
Thanks for this effort. Can you consider modifying the existing interceptors to make them charset-aware instead of creating a new set of interceptors ? In reality some users will continue using the old ones, and we will face the problems with syncing the fixes across the 2 sets of interceptors
---
[GitHub] cxf issue #309: [CXF-7491] Fork Stax & XSLT interceptors to make them Charse...
Posted by sberyozkin <gi...@git.apache.org>.
Github user sberyozkin commented on the issue:
https://github.com/apache/cxf/pull/309
I'm not sure if users actually have ever tried to extend these classes, we can ask at the CXF users for example if someone has tried it...Can you please try to do another PR but based on updating the protected methods, or may be you can find a way to pass that extra parameter as a new message property, example, Message.PAYLOAD_ENCODING, or similar ? thanks
---