Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NIFI-12017 add ability to choose to output to single line for base32 base64 contents #8417

Conversation

knguyen1
Copy link
Contributor

@knguyen1 knguyen1 commented Feb 15, 2024

Summary

NIFI-12017

Tracking

Please complete the following tracking steps prior to pull request creation.

Issue Tracking

Pull Request Tracking

  • Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
  • Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

  • Pull Request based on current revision of the main branch
  • Pull Request refers to a feature branch with one commit containing changes

Verification

Please indicate the verification steps performed prior to pull request creation.

Build

  • Build completed using mvn clean install -P contrib-check
    • JDK 21

Licensing

  • New dependencies are compatible with the Apache License 2.0 according to the License Policy
  • New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

  • Documentation formatting appears as expected in rendered files

@knguyen1
Copy link
Contributor Author

FYI: @exceptionfactory @dan-s1

Update nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/encoding/EncodingMode.java

Co-authored-by: dan-s1 <dstieg1@gmail.com>

Simplify if logic, simplify enum expression
@knguyen1 knguyen1 force-pushed the feat/NIFI-12017/add-ability-to-choose-to-output-to-single-line-for-base32-base64-contents branch from 7f97614 to f07f292 Compare February 15, 2024 21:12
@dan-s1
Copy link
Contributor

dan-s1 commented Feb 15, 2024

@knguyen1 It looks like there are Checkstyle violations that must be corrected.

@knguyen1
Copy link
Contributor Author

@knguyen1 It looks like there are Checkstyle violations that must be corrected.

Fixed. 95f6c0a

@knguyen1
Copy link
Contributor Author

@dan-s1 I just realised our change to enum introduces a breaking change.

case "BASE64_ENCODING":
case "BASE32_ENCODING":

It's because we're using name() from the enum. Thoughts on overriding getValue() and return the old string values instead?

Copy link
Contributor

@dan-s1 dan-s1 left a comment

Choose a reason for hiding this comment

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

The suggested changes addresses your latest question

Fixes backward-compatibility issue, earlier proc uses `base32`, `base64`, `hex`, etc. as string.

Co-authored-by: dan-s1 <dstieg1@gmail.com>
…/src/main/java/org/apache/nifi/processors/standard/EncodeContent.java

Co-authored-by: dan-s1 <dstieg1@gmail.com>
Copy link
Contributor

@dan-s1 dan-s1 left a comment

Choose a reason for hiding this comment

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

Hopefully we are getting closer. I still need to look over the unit tests but here are some formatting suggestions. Now with Junit5 none of the test methods need to be public so the public modifier should be removed from the tests similar to the ones you added. In addition the standard in the code base is to have the @Test annotation above the test method signature so most of the current suggestions are to align with that . Thanks!

Copy link
Contributor

@dan-s1 dan-s1 left a comment

Choose a reason for hiding this comment

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

Further suggestions to refactor the multiple unit test into single parameterized tests.

Copy link
Contributor

@dan-s1 dan-s1 left a comment

Choose a reason for hiding this comment

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

A few more things which should be changed.

Co-authored-by: dan-s1 <dstieg1@gmail.com>
@dan-s1
Copy link
Contributor

dan-s1 commented Feb 27, 2024

@exceptionfactory When you get a chance can you please check things over to see if all necessary changes were made? Thanks!

Co-authored-by: dan-s1 <dstieg1@gmail.com>
Co-authored-by: dan-s1 <dstieg1@gmail.com>
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 the work on these new properties @knguyen1, and thanks for the feedback thus far @dan-s1.

The general capability is useful, but there are still several refinements needed to maintain backward compatibility. I also recommended a few documentation changes. One particular note is the Line Separator property, which seems unnecessary in general. Unless there is a strong reason to support either LF or CRLF, just using LF across the board seems simpler. Sometimes less is more when it comes to configuration, but feel free to provide more details.

@knguyen1 knguyen1 force-pushed the feat/NIFI-12017/add-ability-to-choose-to-output-to-single-line-for-base32-base64-contents branch from ecc3263 to 229dc0c Compare March 3, 2024 13:15
knguyen1 and others added 3 commits March 3, 2024 08:26
Co-authored-by: David Handermann <exceptionfactory@apache.org>
…le-line-for-base32-base64-contents' of github.com:knguyen1/nifi into feat/NIFI-12017/add-ability-to-choose-to-output-to-single-line-for-base32-base64-contents
@knguyen1
Copy link
Contributor Author

knguyen1 commented Mar 3, 2024

I fixed failing tests and build failures from the latest code review. Everything's passing now. @exceptionfactory

I had to add this method: EncodingType getEncodingTypeFromString(final String encodingTypeValue) because previous implementation used hex instead of hexadecimal as in @exceptionfactory's suggestion. So we can't easily use EncodingType.valueOf anymore.

Latest is pending the resolution of comments regarding.

Is this property necessary? It seems best to hard-code the line-feed character \n, rather than making this platform-dependent or configurable.

This description needs some rewording and clarification. It is not clear why it is rounded to a multiple of 4, and again, the conditional nature of the property does not need to be stated.

I have left those threads unresolved.

knguyen1 and others added 2 commits March 4, 2024 09:54
Co-authored-by: dan-s1 <dstieg1@gmail.com>
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 updating the property values @knguyen1.

The last remaining item to change is the Encoded Content Line Separator property. I recommend removing the property and using a hard-coded \n value so that the behavior is the same regardless of the operating system on which NiFi is running.

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 working through the feedback @knguyen1. After one more runtime review, I adjusted the new properties to be required, since the default values align with current behavior. I also set the Encoded Line Length property to use the Positive Integer Validator, ensuring that the value will never be zero or lower.

With these changes, I plan to merge soon, pending one more successful build.

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 again for taking the time to work through all the feedback @knguyen1! +1 merging

@exceptionfactory
Copy link
Contributor

Thanks for the reviews as well @dan-s1!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants