Skip to content

NIFI-7172: Trim whitespace from NiFi properties#4854

Closed
eaolson wants to merge 4 commits intoapache:mainfrom
eaolson:NIFI-7172
Closed

NIFI-7172: Trim whitespace from NiFi properties#4854
eaolson wants to merge 4 commits intoapache:mainfrom
eaolson:NIFI-7172

Conversation

@eaolson
Copy link
Contributor

@eaolson eaolson commented Feb 28, 2021

Description of PR

Fixes NIFI-7172. Trims whitespace from NiFi properties. Multi-line properties are truncated at the first line break. The underlying java.util.Properties actually takes care of leading whitespace, but it's included in the test case as well.

For all changes:

  • Is there a JIRA ticket associated with this PR? Is it referenced
    in the commit message?

  • Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

  • Has your PR been rebased against the latest commit within the target branch (typically main)?

  • Is your initial contribution a single, squashed commit? Additional commits in response to PR reviewer feedback should be made on this branch and pushed to allow change tracking. Do not squash or use --force when pushing to allow for clean monitoring of changes.

For code changes:

  • Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder?
  • Have you written or updated unit tests to verify your changes?
  • Have you verified that the full build is successful on JDK 8?
  • Have you verified that the full build is successful on JDK 11?
  • If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
  • If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?
  • If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?
  • If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?

… are truncated at the first line terminator.
rawProperties.load(inStream);
logger.info("Loaded {} properties from {}", rawProperties.size(), file.getAbsolutePath());

// Trim whitespace from each property. If property is multi-line, remove anything after the first line break.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we allow for whitespace at the start/end of properties if the user wants it (e.g. a password)? So either a flag (in the properties) to enable/disable the whitespace trimming or an escape/quote megabits, e.g. "foo " would retain the trailing whitespace but not the quotes?

Suspect this is somewhat of an edge case but always running whitespace can lead to frustrations

Copy link
Contributor Author

@eaolson eaolson Mar 4, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Allow me to counterpoint:

  1. Leading whitespace on the value is taken care of by the underlying java.util.Properties . That's already being stripped out and this pull request doesn't change that. So to support leading whitespace would mean writing a whole new reader.
  2. Similarly, trailing whitespace on the key is already taken care of by the Properties instance. So supporting leading whitespace would mean the possibility of "foo=bar" and "foo = bar" (which are currently equivalent) being different. And "foo =bar" would be equivalent to the former and not the latter. If nothing else, "supportLeadingWhitespace=false" should be the default, because you just know someone out there has configured their properties with spaces around the "=" and it's working now.
  3. Supporting surrounding quote characters just changes the situation from "no trailing whitespace" to "no leading or trailing quote marks", though I supposed you could have a quote inside the value if you escape it somehow.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I realised the quotes issue after mashing the comment (i.e. just chasing it to handle surrounding quotes instead of whitespace)

Allowing for multi-line properties is good and as I say, this would be something of an edge case that isn't likely to happen regularly. If the standard property reader already removes such things anyway then as you say, maybe better to leave as-is

assert niFiProperties.getProperty("nifi.whitespace.propWithLeadingSpace") == "foo";
assert niFiProperties.getProperty("nifi.whitespace.propWithTrailingSpace") == "foo";
assert niFiProperties.getProperty("nifi.whitespace.propWithLeadingAndTrailingSpace") == "foo";
assert niFiProperties.getProperty("nifi.whitespace.propWithTrailingTab") == "foo";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this test is failing in all the checks, looking at your regex, not sure you're currently removing tab characters

Copy link
Contributor Author

@eaolson eaolson Mar 7, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I misunderstood how multiline properties worked and this change fixes that. That simplified the regex a lot. Users can still embed a newline character with "\n". I figure if they go to that much trouble, they should be allowed to. The tab issue has been fixed. I also moved the test into a test class that executes under Windows, where I'm working. The failing check seems to have nothing to do with my change.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

JDK 11 build failed still, though can't see from the errors whether that's caused by your changes or an intermittent issue with the build (and therefore whether a simple re-execution of that check may let it pass)?

…ngTab to use \t instead of a binary tab; fails contrib-check. Move test to a class that runs under Windows.
String key = itr.next();
String prop = rawProperties.getProperty(key);
if(!prop.isEmpty()){
prop = Pattern.compile("\\s+$").matcher(prop).replaceFirst("");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably better to define the Pattern once as a class-level static final field or use the String class' replace such as prop.replace("\\s+$", ""), although I'd guess using the pre-compiled Pattern would be slightly more efficient... but this code is probably only run once at startup anyway so it's unlikely a big deal (but I'd still prefer Pattern not to be compiled every time within the while loop)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've moved the pattern compilation out of the loop.

Copy link
Contributor

@exceptionfactory exceptionfactory left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your contribution @eaolson. There appear to be some opportunities to optimize the approach. It would also be helpful to assign the associated NiFi Jira issue to yourself and set the status to Patch Available based on your work.

Incorporate suggestions from exceptionfactory.
@exceptionfactory
Copy link
Contributor

Thanks for making the adjustments @eaolson. Do you have any additional comments @ChrisSamo632?

@ChrisSamo632
Copy link
Contributor

Thanks for making the adjustments @eaolson. Do you have any additional comments @ChrisSamo632?

@exceptionfactory nothing more from me (I can't see how to resolve conversations, maybe I don't have access, nevermind)

@exceptionfactory
Copy link
Contributor

Thanks for making the adjustments @eaolson. Do you have any additional comments @ChrisSamo632?

@exceptionfactory nothing more from me (I can't see how to resolve conversations, maybe I don't have access, nevermind)

Thanks for the confirmation @ChrisSamo632!

Copy link
Contributor

@exceptionfactory exceptionfactory left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your work on this @eaolson! +1 Merging.

@asfgit asfgit closed this in bff3e94 Mar 25, 2021
krisztina-zsihovszki pushed a commit to krisztina-zsihovszki/nifi that referenced this pull request Jun 28, 2022
This closes apache#4854

Signed-off-by: David Handermann <exceptionfactory@apache.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants