You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2018/06/05 21:48:00 UTC

[jira] [Commented] (NIFI-4272) ReplaceText processor does not properly iterate multiple replacement values when EL is used

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

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

Github user mosermw commented on a diff in the pull request:

    https://github.com/apache/nifi/pull/2748#discussion_r193232920
  
    --- Diff: nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/test/java/org/apache/nifi/processors/standard/TestReplaceText.java ---
    @@ -1074,12 +1090,11 @@ public void testRegexWithBadCaptureGroup() throws IOException {
             runner.setProperty(ReplaceText.REPLACEMENT_STRATEGY, ReplaceText.REGEX_REPLACE);
             runner.setProperty(ReplaceText.EVALUATION_MODE, ReplaceText.ENTIRE_TEXT);
     
    +        exception.expect(AssertionError.class);
    +        exception.expectMessage("java.lang.IndexOutOfBoundsException: No group 1");
    --- End diff --
    
    At first I was really concerned about this change to IndexOutOfBoundsException, because it means the flowfile will rollback and admin yield the ReplaceText.  But if this is simply verifying behavior when the SEARCH_VALUE is incorrectly configured, then I think this is OK.  Can you confirm?  Normally we would prefer a customValidate() method catch this scenario (REPLACEMENT_VALUE references a capture group that does exist in the SEARCH_VALUE) but perhaps that isn't viable at validation time.


> ReplaceText processor does not properly iterate multiple replacement values when EL is used
> -------------------------------------------------------------------------------------------
>
>                 Key: NIFI-4272
>                 URL: https://issues.apache.org/jira/browse/NIFI-4272
>             Project: Apache NiFi
>          Issue Type: Bug
>          Components: Core Framework
>    Affects Versions: 1.1.0, 1.2.0, 1.3.0
>            Reporter: Matthew Clarke
>            Assignee: Otto Fowler
>            Priority: Major
>
> I am using the ReplaceText processor to take a string input (example:   {"name":"Smith","middle":"nifi","firstname":"John"} ) and change all the filed names to all uppercase.
> Using above input as an example, I expect output like {"NAME":"Smith","MIDDLE":"nifi","FIRSTNAME":"John"}
> I expect I should be able to do this with ReplaceText processor; however, I see some unexpected behavior:
> -------
> Test 1:  (uses EL in the replacement value property)
> Search value:  \"([a-z]+?)\":\"(.+?)\"
> Replacement Value: \"*${'$1':toUpper()}*":\"$2\"
> Result: {"NAME":"Smith","NAME":"nifi","NAME":"John"}
> -------
> Test 2:  (Does not use EL in the replacement Value property)
> Search value:  \"([a-z]+?)\":\"(.+?)\"
> Replacement Value: \"new$1":\"$2\"
> Result: {"newname":"Smith","newmiddle":"nifi","newfirstname":"John"}
> --------
> As you can see if I use a NiFi expression Language statement in the Replacement Value property it no longer iterates as expect through the various $1 captured values. It repeatedly uses the EL result from the first EL evaluation in every iteration while $2 correctly iterates through the search values.



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