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

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

Github user joewitt commented on the pull request:

    https://github.com/apache/nifi/pull/354#issuecomment-211708711
  
    @YolandaMDavis @olegz some feedback.
    
    1. The com.bazaar.jolt... dependency does not appear to be accounted for in 
the LICENSE/NOTICE updates.  Their LICENSE does indicate they would like 
reference made to 'Copyright 2013-2014 Bazaarvoice, Inc.'  This is found in 
https://github.com/bazaarvoice/jolt/blob/1271e1919693e63ce1efdf534dfee0e0579d0b2f/LICENSE
  So we should propogate that into the NOTICE file as well.  Also we need to 
reference JOLT in our top level nifi-assembly/NOTICE as well if it is new and 
I'd assume at least for Bazaar it would be.
    
    2. I don't believe I follow the recommendation to change the member 
variable 'transform' to volatile or to set it to null on stopped.  The variable 
appears to be set at the proper lifecycle point in NiFi and thus would not be 
reassigned in some non-thread safe way.  The only question then is could its 
use itself be non Thread safe and that does appear questionable to me.  In that 
case marking the variable as volatile won't help at all anyway.  If indeed it 
is not thread safe you will want to consider marking the class as executing 
serially or you could have a pool of transforms or you could transform batches 
at a time.  Lots of ways to tackle it.  Of course if that is thread safe 
already then you are fine and in any event the volatile should be unnecessary.  
Finally, I am not aware of any cause for setting it to null during onStopped or 
on unScheduled as if the processor was being removed from the flow then it 
would get cleaned up anyway.  If there was a need to call a close method or 
something then yes that is good.
    
    



> Create Processors to mutate JSON data
> -------------------------------------
>
>                 Key: NIFI-361
>                 URL: https://issues.apache.org/jira/browse/NIFI-361
>             Project: Apache NiFi
>          Issue Type: New Feature
>            Reporter: Aldrin Piri
>            Assignee: Oleg Zhurakousky
>            Priority: Minor
>             Fix For: 1.0.0, 0.7.0
>
>
> Creating a separate issue to track these as a pull request has been submitted 
> for related issue NIFI-356.
> Also backed by JsonPath, processors should facilitate through specification 
> of user-defined properties:
> * Add - identify path and add key/value pair
> ** Handle if the path is an array, this would ignore the name specified and 
> just add the value to the collection
> * Remove - delete the element at the specified path
> * Update - change the value for the given path to a provided value
> Need to determine if objects/arrays make sense for values or if they are 
> needed.
> While it would be nice to be able to execute several operations per processor 
> instance, it may be hard to capture all the relevant information needed for 
> multiple operations in one processor configuration in a user friendly context.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to