Hi Aldrin, I agree that an enhancement to the existing processor could fulfill the same goal. My thinking was that adding to the EL would essential add the functionality to all processors that support the EL. Of course the adding to the EL does not mean that the existing processor could not be enhanced. In fact I was also planning on doing that as a follow up.
I still planning on doing the EL extension; its nearly done. But if the pull request isn’t ultimately accepted, that’s fine as its a good exercise for me. Cheers, Chris On 3/22/16, 12:51 PM, "Aldrin Piri" <[email protected]> wrote: >Chris, > >Awesome that you are ready to dive in and get this fixed up. The >functionality is certainly one that would be helpful. >I do find myself a bit torn on whether the inclusion of this as EL is >preferred instead of the extension of EvaluateJsonPath as suggested >in NIFI-1567 [1]. Are there use cases that would not be fulfilled via >enhancements to the existing processor that I might be overlooking? > >Thanks! > >[1] https://issues.apache.org/jira/browse/NIFI-1567 > >On Tue, Mar 22, 2016 at 12:45 PM, Matt Burgess <[email protected]> wrote: > >> Chris, >> >> Great to hear! For the following steps, I'm assuming it will be a >> one-argument function called "jsonPath" that takes a String containing a >> JSON Path expression to be evaluated on the "subject" of the function. So I >> am picturing it used like: >> >> ${ my.json.attribute:jsonPath("$.path.to.my.data") } >> >> To add such a function to EL, you'll likely want to do something like the >> following: >> >> 1) Add a token for the function name to the Lexer: >> >> https://github.com/apache/nifi/blob/master/nifi-commons/nifi-expression-language/src/main/antlr3/org/apache/nifi/attribute/expression/language/antlr/AttributeExpressionLexer.g#L120 >> >> 2) Add the token to the oneArgString rule: >> >> https://github.com/apache/nifi/blob/master/nifi-commons/nifi-expression-language/src/main/antlr3/org/apache/nifi/attribute/expression/language/antlr/AttributeExpressionParser.g#L77 >> >> 3) Add a JsonPathEvaluator class (or whatever its called) to the functions >> package: >> >> https://github.com/apache/nifi/tree/master/nifi-commons/nifi-expression-language/src/main/java/org/apache/nifi/attribute/expression/language/evaluation/functions >> >> 4) Add a case to Query.buildFunctionEvaluator() to create and use a new >> JsonPathEvaluator: >> >> https://github.com/apache/nifi/blob/master/nifi-commons/nifi-expression-language/src/main/java/org/apache/nifi/attribute/expression/language/Query.java#L1061 >> >> 5) Add unit test(s) to TestQuery to test your function: >> >> https://github.com/apache/nifi/blob/master/nifi-commons/nifi-expression-language/src/test/java/org/apache/nifi/attribute/expression/language/TestQuery.java >> >> Also whatever dependencies you bring in (Jayway, e.g.) will need to be >> added to the EL module's POM: >> >> https://github.com/apache/nifi/blob/master/nifi-commons/nifi-expression-language/pom.xml >> . >> If a parent POM has declared a version already (such as the NiFi parent POM >> declaring jayway 2.0.0 at present), you may want to keep that unless you >> need to override for some reason. >> >> Looking forward to your contribution, please let me/us know if you run into >> any trouble or have any questions. >> >> Cheers, >> Matt >> >> >> On Tue, Mar 22, 2016 at 10:59 AM, McDermott, Chris Kevin (MSDU - >> STaTS/StorefrontRemote) <[email protected]> wrote: >> >> > Hi folks, >> > >> > I’m a newbie NiFi user but long time Java developer. I’ve entered a Jira >> > issue to extend the expression language to add a function to evaluate a >> > Json path against the subject. Looking at the code I feel this is very >> > doable, and I am up for task so I’m planning on tackling it. I’ve read >> the >> > developers guide, etc. Please, any advice and direction is most welcome. >> > >> > Thanks, >> > >> > Chris McDermott. >> > >>
