[
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)
