[
https://issues.apache.org/jira/browse/CXF-6423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14566103#comment-14566103
]
ASF GitHub Bot commented on CXF-6423:
-------------------------------------
Github user skjolber commented on the pull request:
https://github.com/apache/cxf/pull/75#issuecomment-107067157
So for logging, why would it be logical to try to repair trunkated (or
invalid xml)?
The primary goal must be to log something which correctly represents the
payload content. And does that whether the content is good or bad xml,
trunkated or not.
Consider this valid xml string:
```xml
<a><b><c></c></b></a>
```
if it is trunkated to
```xml
<a><b>
```
then the current approach would give you
```xml
<a><b></b></a>
```
as the closing tags are added. This is not only a string which is longer
than the limit, it might give the impression that there is no c element. This
is clearly a good way to create misunderstandings.
Another use-case: This one shows that inserting an 'content trunkated'
message and then adding end tags is not a good idea either
Consider this invalid xml string:
```xml
<a><b><c></c></a>
```
if it is trunkated to
```xml
<a><b><c></c>
```
then the current approach would give you
```xml
<a><b><c></c></b></a>
```
which is valid xml. And so tracking the problem by looking at the logged
xml would be quit difficult. So if we did
```xml
<a><b><c></c>[content trunkated]</b></a>
```
we would still have the same problem.
Certainly I can add some more test cases and test documentation, if you
prefer.
> PrettyLoggingFilter tests and improvements
> ------------------------------------------
>
> Key: CXF-6423
> URL: https://issues.apache.org/jira/browse/CXF-6423
> Project: CXF
> Issue Type: Improvement
> Reporter: Thomas Skjølberg
> Assignee: Christian Schneider
> Priority: Minor
>
> Improvements for PrettyLoggingFilter in the cxf-rt-features-logging module:
> 1. use a StringReader instead of getting bytes from a String and using an
> InputStream (capture encoding issues at an eariler stage)
> 2. add parser exception handling based on whether the payload is truncated or
> not; return original XML if deemed invalid
> 3. do not call XMLStreamWriter.close() before getting contents for truncated
> or invalid XML because some writers misbehave (are extra helpful) in a way
> unfit for logging.
> 4.construct output StringWriter with a size based on the raw XML string size
> 5.additional test cases
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
