Github user jvwing commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2859#discussion_r204246421
--- Diff:
nifi-nar-bundles/nifi-aws-bundle/nifi-aws-processors/src/main/java/org/apache/nifi/processors/aws/sqs/PutSQS.java
---
@@ -115,7 +125,19 @@ public void onTrigger(final ProcessContext context,
final ProcessSession session
entry.setId(flowFile.getAttribute("uuid"));
final ByteArrayOutputStream baos = new ByteArrayOutputStream();
session.exportTo(flowFile, baos);
- final String flowFileContent = baos.toString();
+
+ final Charset charset =
Charset.forName(context.getProperty(CHARSET).getValue());
+
+ String flowFileContent;
+
+ // Get the content of the FlowFile with the given Charset. Fall
back to the default charset
+ // if the given charset is not supported.
+ try {
+ flowFileContent = baos.toString(charset.name());
+ } catch (UnsupportedEncodingException e) {
--- End diff --
I don't think we should silently fall back to a default encoding without
notifying users. Alternatives might include:
* Routing the flowfile to the FAILURE relationship and logging an error
* Falling back to the default encoding, but log a warning describing the
issue (via `getLogger().warn(...)`)
Also, have you considered validating the charset with a customValidate()
override?
---
