[
https://issues.apache.org/jira/browse/CXF-7430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16093934#comment-16093934
]
Alex Korobko commented on CXF-7430:
-----------------------------------
Not sure if github integrated with JIRA, I don't see my pull request in the
ticket, so I add link here https://github.com/apache/cxf/pull/294
> The logInputStream method of the LoggingInInterceptor fails if input stream
> size bigger than limit and PrettyPrint option is true.
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: CXF-7430
> URL: https://issues.apache.org/jira/browse/CXF-7430
> Project: CXF
> Issue Type: Bug
> Affects Versions: 3.0.10, 3.1.7, 3.1.8, 3.0.11, 3.1.9, 3.0.12, 3.0.13
> Reporter: Alex Korobko
>
> The logInputStream method of the LoggingInInterceptor class fails when the
> input stream size is bigger than the limit variable value and PrettyPrint
> option is set to true.
> The problem is:
> # In the logInputStream method of the LoggingInInterceptor class if the input
> stream is bigger than limit (the default value of the limit variable defined
> in the AbstractLoggingInterceptor as 48 * 1024) the input stream is
> truncated to the length of the limit value;
> # The logInputStream method of the LoggingInInterceptor class uses the
> writePayload method of the AbstractLoggingInterceptor to log the payload of
> the response;
> # As the PrettyPrint option is true, the writePayload method attempts to use
> the PrettyPrintXMLWriter class to log already truncated XML data and throws
> exception.
> It seems like the issue could be resolved if the LoggingInInterceptor class
> resets the PrettyPrint option to false every time if the input stream was
> truncated. Or the same result would be achieved if contentType parameter of
> the writePayload method is NOT set to 'xml' for truncated stream.
> Additionally, the same solution should be propagated to all usages of the
> writePayload method of the AbstractLoggingInterceptor class.
> I faced this issue in my project that uses older version of the library, but
> as I just found the exception could be handled by changes in code made by
> commit
> https://github.com/apache/cxf/commit/d5373a3e3d2219ce07526cfb92ff954b3382727e
> so it is not relevant to latest sources anymore. But I think it is not a very
> good way to handle it through handling exception.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
