[
https://issues.apache.org/jira/browse/MINIFICPP-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16889223#comment-16889223
]
Daniel Bakai edited comment on MINIFICPP-984 at 7/19/19 10:46 PM:
------------------------------------------------------------------
[~aboda] The question here is when to print the payload hexencoded. One option,
as discussed, would be to try to autodetect when the payload is textual. My
argument was that this is not too well defined and could have unexpected
consequences and would not add much value, so I do not suggest doing it at all.
I think the best solution, that we arrived at, is to add a new, EL-supporting
property to the processor which determines whether the payload is printed
hexencoded or not.
The NiFi implementation's Character Set property is a completely unrelated
thing, it deals with how textual data is transcoded to Java's UTF-16 string.
This is useful if the payload is a textual data encoded with some character
encoding that has to be converted to UTF-16 (or just simply interpreted as it)
to be logged by NiFi.
This could be added as a feature, but it would definitely be a new one, and as
our output character encoding is not as well defined as in Java (we just write
the byte stream into a file that could either be interpreted by a text editor
or printed to the terminal), it is not straightforward not we would have to use
a library to convert between encodings.
And it would not solve the problem when the data is truly not textual: that is
when hexencoding is needed.
I like the line length Property with a default 80 value though, I will be
adding that too.
was (Author: bakaid):
[~aboda] The question here is when to print the payload hexencoded. One option,
as discussed, would be to try to autodetect when the payload is textual. My
argument was that this is not too well defined and could have unexpected
consequences and would not add much value, so I do not suggest doing it at all.
I think the best solution, that we arrived at, is to add a new, EL-supporting
property to the processor which determines whether the payload is hexencoded or
not.
The NiFi implementation's Character Set property is a completely unrelated
thing, it deals with how textual data is transcoded to Java's UTF-16 string.
This is useful if the payload is a textual data encoded with some character
encoding that has to be converted to UTF-16 (or just simply interpreted as it)
to be logged by NiFi.
This could be added as a feature, but it would definitely be a new one, and as
our output character encoding is not as well defined as in Java (we just write
the byte stream into a file that could either be interpreted by a text editor
or printed to the terminal), it is not straightforward not we would have to use
a library to convert between encodings.
And it would not solve the problem when the data is truly not textual: that is
when hexencoding is needed.
I like the line length Property with a default 80 value though, I will be
adding that too.
> LogAttribute should return to prior behavior or detect text and print it out
> ----------------------------------------------------------------------------
>
> Key: MINIFICPP-984
> URL: https://issues.apache.org/jira/browse/MINIFICPP-984
> Project: Apache NiFi MiNiFi C++
> Issue Type: Bug
> Reporter: Mr TheSegfault
> Assignee: Daniel Bakai
> Priority: Blocker
>
> Noticed by user: change in behavior on log attribute payload log.
> Prior behavior on text files printed text. In some cases this may have
> issues. I think we took a step forward; however, we should provide hex
> printing along with ascii ( leaving what was default previously as the
> default ) to be backwards compatible and provide the benefits of hex encoding
> ( maybe make it EL based, so it can be per ff )
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
