[ 
https://issues.apache.org/jira/browse/NIFI-5566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16605074#comment-16605074
 ] 

ASF GitHub Bot commented on NIFI-5566:
--------------------------------------

Github user alopresto commented on the issue:

    https://github.com/apache/nifi/pull/2983
  
    @ottobackwards I've run this branch with the full build and all tests 
enabled multiple times and I have not encountered that error (just did it again 
from scratch with no `.m2` to be sure; 41:24 minute process). Can you manually 
verify if that directory and file exist on your machine?
    
    The logic in the test should populate the file when the test is run and 
delete the file when the test suite is complete (so we don't just have an 
unnecessary 10 MB file checked in to the source). 
    
    ```
         File inputFile = new File(LARGE_FILE_PATH)
    
            // Generates a file with "apachenifi" 10 times per line for 10_000 
lines (11 bytes * 10 * 10_000 ~= 1 MiB)
            if (!inputFile.exists() || inputFile.length() == 0) {
                10_000.times { int i ->
                    inputFile << "${i.toString().padLeft(5)}: ${"apachenifi " * 
10}\n"
                }
            }
    ```
    
    ```
        @AfterClass
        static void tearDownOnce() throws Exception {
            File largeFile = new File(LARGE_FILE_PATH)
            if (largeFile.exists()) {
                largeFile.deleteOnExit()
            }
        }
    ```


> Bring HashContent inline with HashService and rename legacy components
> ----------------------------------------------------------------------
>
>                 Key: NIFI-5566
>                 URL: https://issues.apache.org/jira/browse/NIFI-5566
>             Project: Apache NiFi
>          Issue Type: Improvement
>          Components: Extensions
>    Affects Versions: 1.7.1
>            Reporter: Andy LoPresto
>            Assignee: Andy LoPresto
>            Priority: Major
>              Labels: backwards-compatibility, hash, security
>
> As documented in [NIFI-5147|https://issues.apache.org/jira/browse/NIFI-5147] 
> and [PR 2980|https://github.com/apache/nifi/pull/2980], the {{HashAttribute}} 
> processor and {{HashContent}} processor are lacking some features, do not 
> offer consistent algorithms across platforms, etc. 
> I propose the following:
> * Rename {{HashAttribute}} (which does not provide the service of calculating 
> a hash over one or more attributes) to {{HashAttributeLegacy}}
> * Renamed {{CalculateAttributeHash}} to {{HashAttribute}} to make semantic 
> sense
> * Rename {{HashContent}} to {{HashContentLegacy}} for users who need obscure 
> digest algorithms which may or may not have been offered on their platform
> * Implement a processor {{HashContent}} with similar semantics to the 
> existing processor but with consistent algorithm offerings and using the 
> common {{HashService}} offering
> With the new component versioning features provided as part of the flow 
> versioning behavior, silently disrupting existing flows which use these 
> processors is no longer a concern. Rather, Any flow currently using the 
> existing processors will either:
> 1. continue normal operation
> 1. require flow manager interaction and provide documentation about the change
>   1. migration notes and upgrade instructions will be provided



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to