[jira] [Updated] (NIFI-5815) PutORC processor "Restricted" still requires access to restricted components regardless of restriction
[ https://issues.apache.org/jira/browse/NIFI-5815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Kawamura updated NIFI-5815: Resolution: Fixed Fix Version/s: 1.9.0 Status: Resolved (was: Patch Available) > PutORC processor "Restricted" still requires access to restricted components > regardless of restriction > -- > > Key: NIFI-5815 > URL: https://issues.apache.org/jira/browse/NIFI-5815 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.6.0, 1.7.0, 1.8.0, 1.7.1 >Reporter: Matthew Clarke >Assignee: Pierre Villard >Priority: Major > Fix For: 1.9.0 > > > When the new more granular policies were introduced for the "Access > Restricted Components" access policy, the PutORC processor was missed. It > still requires that users have full access to all restricted components in > order to use this processor. This has side affect of any user who needs to > use this components having access to all components in every sub policy of > restricted-components. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5815) PutORC processor "Restricted" still requires access to restricted components regardless of restriction
[ https://issues.apache.org/jira/browse/NIFI-5815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686084#comment-16686084 ] ASF GitHub Bot commented on NIFI-5815: -- Github user ijokarumawak commented on the issue: https://github.com/apache/nifi/pull/3169 LGTM +1, merging. Thanks @pvillard31! > PutORC processor "Restricted" still requires access to restricted components > regardless of restriction > -- > > Key: NIFI-5815 > URL: https://issues.apache.org/jira/browse/NIFI-5815 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.6.0, 1.7.0, 1.8.0, 1.7.1 >Reporter: Matthew Clarke >Assignee: Pierre Villard >Priority: Major > > When the new more granular policies were introduced for the "Access > Restricted Components" access policy, the PutORC processor was missed. It > still requires that users have full access to all restricted components in > order to use this processor. This has side affect of any user who needs to > use this components having access to all components in every sub policy of > restricted-components. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5815) PutORC processor "Restricted" still requires access to restricted components regardless of restriction
[ https://issues.apache.org/jira/browse/NIFI-5815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686085#comment-16686085 ] ASF subversion and git services commented on NIFI-5815: --- Commit 9e7610ac70c389ecfb3a4d389e4e28a41249af2b in nifi's branch refs/heads/master from [~pvillard] [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=9e7610a ] NIFI-5815 - PutORC processor 'Restricted' still requires access to restricted components regardless of restriction This closes #3169. Signed-off-by: Koji Kawamura > PutORC processor "Restricted" still requires access to restricted components > regardless of restriction > -- > > Key: NIFI-5815 > URL: https://issues.apache.org/jira/browse/NIFI-5815 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.6.0, 1.7.0, 1.8.0, 1.7.1 >Reporter: Matthew Clarke >Assignee: Pierre Villard >Priority: Major > > When the new more granular policies were introduced for the "Access > Restricted Components" access policy, the PutORC processor was missed. It > still requires that users have full access to all restricted components in > order to use this processor. This has side affect of any user who needs to > use this components having access to all components in every sub policy of > restricted-components. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5815) PutORC processor "Restricted" still requires access to restricted components regardless of restriction
[ https://issues.apache.org/jira/browse/NIFI-5815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16686086#comment-16686086 ] ASF GitHub Bot commented on NIFI-5815: -- Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/3169 > PutORC processor "Restricted" still requires access to restricted components > regardless of restriction > -- > > Key: NIFI-5815 > URL: https://issues.apache.org/jira/browse/NIFI-5815 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.6.0, 1.7.0, 1.8.0, 1.7.1 >Reporter: Matthew Clarke >Assignee: Pierre Villard >Priority: Major > > When the new more granular policies were introduced for the "Access > Restricted Components" access policy, the PutORC processor was missed. It > still requires that users have full access to all restricted components in > order to use this processor. This has side affect of any user who needs to > use this components having access to all components in every sub policy of > restricted-components. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi pull request #3169: NIFI-5815 - PutORC processor 'Restricted' still req...
Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/3169 ---
[GitHub] nifi issue #3169: NIFI-5815 - PutORC processor 'Restricted' still requires a...
Github user ijokarumawak commented on the issue: https://github.com/apache/nifi/pull/3169 LGTM +1, merging. Thanks @pvillard31! ---
[jira] [Resolved] (MINIFICPP-654) C API: failure callback improvements
[ https://issues.apache.org/jira/browse/MINIFICPP-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mr TheSegfault resolved MINIFICPP-654. -- Resolution: Fixed > C API: failure callback improvements > > > Key: MINIFICPP-654 > URL: https://issues.apache.org/jira/browse/MINIFICPP-654 > Project: NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Arpad Boda >Assignee: Arpad Boda >Priority: Minor > Fix For: 0.6.0 > > > Improvements and further discussion of failure callbacks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MINIFICPP-670) Move away from Processor linkages in favor of UT hash linked list
[ https://issues.apache.org/jira/browse/MINIFICPP-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mr TheSegfault updated MINIFICPP-670: - Labels: nanofi (was: ) > Move away from Processor linkages in favor of UT hash linked list > - > > Key: MINIFICPP-670 > URL: https://issues.apache.org/jira/browse/MINIFICPP-670 > Project: NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Mr TheSegfault >Priority: Major > Labels: nanofi > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MINIFICPP-629) Investigate removing exceptions in CAPI and improving response code handling
[ https://issues.apache.org/jira/browse/MINIFICPP-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mr TheSegfault updated MINIFICPP-629: - Labels: nanofi (was: ) > Investigate removing exceptions in CAPI and improving response code handling > > > Key: MINIFICPP-629 > URL: https://issues.apache.org/jira/browse/MINIFICPP-629 > Project: NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Mr TheSegfault >Priority: Major > Labels: nanofi > > Investigate removing exceptions in CAPI and improving response code handling > – maybe start by calling set_terminate to set a termination handler function > and move to the eventual goal of returning meaningful response codes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MINIFICPP-667) Create Structural definitions for moving away from C++ classes
[ https://issues.apache.org/jira/browse/MINIFICPP-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mr TheSegfault updated MINIFICPP-667: - Affects Version/s: nanofi > Create Structural definitions for moving away from C++ classes > -- > > Key: MINIFICPP-667 > URL: https://issues.apache.org/jira/browse/MINIFICPP-667 > Project: NiFi MiNiFi C++ > Issue Type: Improvement >Affects Versions: nanofi >Reporter: Mr TheSegfault >Assignee: Mr TheSegfault >Priority: Major > Fix For: 0.6.0 > > > Create Structural definitions for moving away from C++ classes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MINIFICPP-666) NanoFi should be c file not Cpp file
[ https://issues.apache.org/jira/browse/MINIFICPP-666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mr TheSegfault reassigned MINIFICPP-666: Assignee: (was: Mr TheSegfault) > NanoFi should be c file not Cpp file > > > Key: MINIFICPP-666 > URL: https://issues.apache.org/jira/browse/MINIFICPP-666 > Project: NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Mr TheSegfault >Priority: Major > > This should be the eventual goal of moving the cpp file to C as we move from > C to C++ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MINIFICPP-658) Port Site to Site to C
[ https://issues.apache.org/jira/browse/MINIFICPP-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mr TheSegfault updated MINIFICPP-658: - Labels: nanofi (was: ) > Port Site to Site to C > -- > > Key: MINIFICPP-658 > URL: https://issues.apache.org/jira/browse/MINIFICPP-658 > Project: NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Mr TheSegfault >Assignee: Mr TheSegfault >Priority: Major > Labels: nanofi > > Most code is already written in C, so there's no reason this should be a > tough task. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MINIFICPP-671) Create determinate call chain to current set of C++ processors as we transition away from Instance
[ https://issues.apache.org/jira/browse/MINIFICPP-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mr TheSegfault updated MINIFICPP-671: - Labels: nanofi (was: ) > Create determinate call chain to current set of C++ processors as we > transition away from Instance > -- > > Key: MINIFICPP-671 > URL: https://issues.apache.org/jira/browse/MINIFICPP-671 > Project: NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Mr TheSegfault >Priority: Major > Labels: nanofi > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MINIFICPP-671) Create determinate call chain to current set of C++ processors as we transition away from Instance
Mr TheSegfault created MINIFICPP-671: Summary: Create determinate call chain to current set of C++ processors as we transition away from Instance Key: MINIFICPP-671 URL: https://issues.apache.org/jira/browse/MINIFICPP-671 Project: NiFi MiNiFi C++ Issue Type: Improvement Reporter: Mr TheSegfault -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MINIFICPP-670) Move away from Processor linkages in favor of UT hash linked list
Mr TheSegfault created MINIFICPP-670: Summary: Move away from Processor linkages in favor of UT hash linked list Key: MINIFICPP-670 URL: https://issues.apache.org/jira/browse/MINIFICPP-670 Project: NiFi MiNiFi C++ Issue Type: Improvement Reporter: Mr TheSegfault -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MINIFICPP-657) Begin removing Instance class in favor of a C based design.
[ https://issues.apache.org/jira/browse/MINIFICPP-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mr TheSegfault updated MINIFICPP-657: - Epic Name: nanofi (was: NanoFi) > Begin removing Instance class in favor of a C based design. > > > Key: MINIFICPP-657 > URL: https://issues.apache.org/jira/browse/MINIFICPP-657 > Project: NiFi MiNiFi C++ > Issue Type: Epic >Reporter: Mr TheSegfault >Priority: Critical > > We currently use an execution plan as instance variables in the C code. We > should begin porting these constructs to C or eliminate the need for them > altogether. This will mean that sub components should be slowly ported. Could > also use this as a way to begin integrating C functionality into integration > tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MINIFICPP-645) Move from new to malloc in CAPI to facilitate eventual change from C++ to C
[ https://issues.apache.org/jira/browse/MINIFICPP-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mr TheSegfault updated MINIFICPP-645: - Description: As gradually move to C we should move out of libminifi and remove the linter. Nothing that is returned via the API that is not an opaque pointer should use new was:As gradually move to C we should move out of libminifi and remove the linter. > Move from new to malloc in CAPI to facilitate eventual change from C++ to C > --- > > Key: MINIFICPP-645 > URL: https://issues.apache.org/jira/browse/MINIFICPP-645 > Project: NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Mr TheSegfault >Priority: Blocker > Labels: CAPI, nanofi > Fix For: 0.6.0 > > > As gradually move to C we should move out of libminifi and remove the linter. > Nothing that is returned via the API that is not an opaque pointer should use > new -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MINIFICPP-645) Move from new to malloc in CAPI to facilitate eventual change from C++ to C
[ https://issues.apache.org/jira/browse/MINIFICPP-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mr TheSegfault updated MINIFICPP-645: - Labels: CAPI nanofi (was: CAPI) > Move from new to malloc in CAPI to facilitate eventual change from C++ to C > --- > > Key: MINIFICPP-645 > URL: https://issues.apache.org/jira/browse/MINIFICPP-645 > Project: NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Mr TheSegfault >Priority: Blocker > Labels: CAPI, nanofi > Fix For: 0.6.0 > > > As gradually move to C we should move out of libminifi and remove the linter. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (MINIFICPP-648) add processor and add processor with linkage nomenclature is confusing
[ https://issues.apache.org/jira/browse/MINIFICPP-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mr TheSegfault resolved MINIFICPP-648. -- Resolution: Fixed > add processor and add processor with linkage nomenclature is confusing > -- > > Key: MINIFICPP-648 > URL: https://issues.apache.org/jira/browse/MINIFICPP-648 > Project: NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Mr TheSegfault >Assignee: Arpad Boda >Priority: Blocker > Labels: CAPI > Fix For: 0.6.0 > > > add_processor should be changed to always add a processor with linkage > without compelling documentation as why this exists.. As a result we will > need to add a create_processor function to create one without adding it to > the flow ( certain use cases where a flow isn't needed such as invokehttp or > listenhttp ) this can be moved to 0.7.0 if we tag before recent commits. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MINIFICPP-633) Create docker tests for site to site in capi
[ https://issues.apache.org/jira/browse/MINIFICPP-633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mr TheSegfault updated MINIFICPP-633: - Labels: nanofi test (was: test) > Create docker tests for site to site in capi > > > Key: MINIFICPP-633 > URL: https://issues.apache.org/jira/browse/MINIFICPP-633 > Project: NiFi MiNiFi C++ > Issue Type: Sub-task >Reporter: Mr TheSegfault >Priority: Major > Labels: nanofi, test > > +Create python integration tests.+ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MINIFICPP-633) Create docker tests for site to site in capi
[ https://issues.apache.org/jira/browse/MINIFICPP-633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mr TheSegfault reassigned MINIFICPP-633: Assignee: (was: Mr TheSegfault) > Create docker tests for site to site in capi > > > Key: MINIFICPP-633 > URL: https://issues.apache.org/jira/browse/MINIFICPP-633 > Project: NiFi MiNiFi C++ > Issue Type: Sub-task >Reporter: Mr TheSegfault >Priority: Major > Labels: nanofi, test > > +Create python integration tests.+ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MINIFICPP-639) Improve error handling of CAPI return failures
[ https://issues.apache.org/jira/browse/MINIFICPP-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mr TheSegfault updated MINIFICPP-639: - Labels: nanofi (was: ) > Improve error handling of CAPI return failures > -- > > Key: MINIFICPP-639 > URL: https://issues.apache.org/jira/browse/MINIFICPP-639 > Project: NiFi MiNiFi C++ > Issue Type: Bug >Reporter: Mr TheSegfault >Priority: Critical > Labels: nanofi > > Errors like not returning a class name as expected should return a meaningful > error throughout the API -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MINIFICPP-622) Transmit binary information for CAPI implementations in heartbeat
[ https://issues.apache.org/jira/browse/MINIFICPP-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mr TheSegfault updated MINIFICPP-622: - Labels: CAPI nanofi (was: CAPI) > Transmit binary information for CAPI implementations in heartbeat > - > > Key: MINIFICPP-622 > URL: https://issues.apache.org/jira/browse/MINIFICPP-622 > Project: NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Mr TheSegfault >Priority: Major > Labels: CAPI, nanofi > > Heartbeats transmit a great deal of information as per our defined spec: > [https://cwiki.apache.org/confluence/display/MINIFI/C2+Design+Proposal] > This ticket will be responsible for figuring out what can and cannot be sent > via these binaries created using the CAPI > > For CAPI : probably need the AgentBuild information, but also potentially > information from a consumer's program – is there a way to capture information > about THEIR binary information > > May include information like python version, GCC version, etc that's NOT > about our library ( and not captured in AgentBuild) – but rather about > theirs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MINIFICPP-621) Crate log aggregator example for CAPI
[ https://issues.apache.org/jira/browse/MINIFICPP-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mr TheSegfault updated MINIFICPP-621: - Labels: CAPI nanofi (was: CAPI) > Crate log aggregator example for CAPI > -- > > Key: MINIFICPP-621 > URL: https://issues.apache.org/jira/browse/MINIFICPP-621 > Project: NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Mr TheSegfault >Priority: Major > Labels: CAPI, nanofi > > Create examples that can tail log files ( perhaps using TailFile ) that works > in windows and *nix -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MINIFICPP-669) Begin moving flow file record struct record away from using an opaque pointer
Mr TheSegfault created MINIFICPP-669: Summary: Begin moving flow file record struct record away from using an opaque pointer Key: MINIFICPP-669 URL: https://issues.apache.org/jira/browse/MINIFICPP-669 Project: NiFi MiNiFi C++ Issue Type: Improvement Reporter: Mr TheSegfault -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (NIFI-5817) QueryRecord processor exception when using JsonPath expression language
[
https://issues.apache.org/jira/browse/NIFI-5817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685585#comment-16685585
]
Mandeep Gill edited comment on NIFI-5817 at 11/13/18 6:36 PM:
--
Following email discussion with Mark Payne, appears to be an issue with
QueryRecord and can be worked around in the meantime by adding a
`replaceNull('{}')` within the expression function chain to handle the case
where the variable may be a flowfile attribute.
was (Author: mandeepg):
Following email discussion, appears to be an issue with QueryRecord and can be
worked around in the meantime by adding a `replaceNull('{}')` within the
expression function chain to handle the case where the variable may be a
flowfile attribute.
> QueryRecord processor exception when using JsonPath expression language
>
>
> Key: NIFI-5817
> URL: https://issues.apache.org/jira/browse/NIFI-5817
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.8.0
> Environment: Linux x64 (Fedora 29) with OpenJDK 8 (openjdk version
> "1.8.0_191")
>Reporter: Mandeep Gill
>Priority: Major
> Attachments: QueryRecord_JsonPath_Issue.xml
>
>
> (From email to the users list)
>
> I'm hitting an issue using the "jsonPath" expression language function to
> extract a query to use with the QueryRecord processor. The processor works
> fine if the expression language subject is contained within the process group
> variable registry, but fails upon starting with an
> `AttributeExpressionLanguageException` if the subject was expected to to
> exist within a flowfile attribute [1]
>
> I've attached a template generated on NiFi 1.8.0 demonstrating the problem -
> it only appears to be an issue with dynamic outputs from the QueryRecord
> processor, as the same expression language statement works fine when used as
> part of UpdateAttribute processor with the subject in a flowfile attribute as
> per the template. I've dug into the codebase and can trace the error to the
> `evaluate` function within the `JsonPathEvaluator` class, which throws the
> exception if the variable can not be referenced. I have a local fix at
> [https://github.com/apache/nifi/compare/master...nstack:fix/jsonpath] that
> returns `StringQueryResult("")` if the subject is empty instead of throwing
> the exception and this appears to work.
>
> However I'm not sure if this is the correct fix as UpdateAttribute works,
> perhaps the problem is instead in QueryRecord eagerly evaluating the queries
> thus triggering the `evaluate` function.
>
> [1] 2018-11-13 14:46:24,899 ERROR [Timer-Driven Process Thread-1]
> o.a.nifi.processors.standard.QueryRecord
> QueryRecord[id=0d5684e2-0167-1000-74c1-eb29a1401981] Failed to properly
> initialize Processor. If still scheduled to run, NiFi will attempt to
> initialize and run the Processor again after the 'Administrative Yield
> Duration' has elapsed. Failure is due to
> java.lang.reflect.InvocationTargetException:
> java.lang.reflect.InvocationTargetException
> java.lang.reflect.InvocationTargetException: null
> at sun.reflect.GeneratedMethodAccessor916.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:142)
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:130)
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:75)
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotation(ReflectionUtils.java:52)
> at
> org.apache.nifi.controller.StandardProcessorNode.lambda$initiateStart$4(StandardProcessorNode.java:1499)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
> org.apache.nifi.attribute.expression.language.exception.AttributeExpressionLanguageException:
> Subject is empty
> at
> org.apache.nifi.attribute.expression.language.evaluation.functions.JsonPathEvaluator.evaluate(JsonPathEvaluator.java:66)
> at
> org.apache.nifi.attribute.expression.language.Query.evaluate(Query.java:315)
> at
>
[jira] [Commented] (NIFI-5817) QueryRecord processor exception when using JsonPath expression language
[
https://issues.apache.org/jira/browse/NIFI-5817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685585#comment-16685585
]
Mandeep Gill commented on NIFI-5817:
Following email discussion, appears to be an issue with QueryRecord and can be
worked around in the meantime by adding a `replaceNull('{}')` within the
expression function chain to handle the case where the variable may be a
flowfile attribute.
> QueryRecord processor exception when using JsonPath expression language
>
>
> Key: NIFI-5817
> URL: https://issues.apache.org/jira/browse/NIFI-5817
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.8.0
> Environment: Linux x64 (Fedora 29) with OpenJDK 8 (openjdk version
> "1.8.0_191")
>Reporter: Mandeep Gill
>Priority: Major
> Attachments: QueryRecord_JsonPath_Issue.xml
>
>
> (From email to the users list)
>
> I'm hitting an issue using the "jsonPath" expression language function to
> extract a query to use with the QueryRecord processor. The processor works
> fine if the expression language subject is contained within the process group
> variable registry, but fails upon starting with an
> `AttributeExpressionLanguageException` if the subject was expected to to
> exist within a flowfile attribute [1]
>
> I've attached a template generated on NiFi 1.8.0 demonstrating the problem -
> it only appears to be an issue with dynamic outputs from the QueryRecord
> processor, as the same expression language statement works fine when used as
> part of UpdateAttribute processor with the subject in a flowfile attribute as
> per the template. I've dug into the codebase and can trace the error to the
> `evaluate` function within the `JsonPathEvaluator` class, which throws the
> exception if the variable can not be referenced. I have a local fix at
> [https://github.com/apache/nifi/compare/master...nstack:fix/jsonpath] that
> returns `StringQueryResult("")` if the subject is empty instead of throwing
> the exception and this appears to work.
>
> However I'm not sure if this is the correct fix as UpdateAttribute works,
> perhaps the problem is instead in QueryRecord eagerly evaluating the queries
> thus triggering the `evaluate` function.
>
> [1] 2018-11-13 14:46:24,899 ERROR [Timer-Driven Process Thread-1]
> o.a.nifi.processors.standard.QueryRecord
> QueryRecord[id=0d5684e2-0167-1000-74c1-eb29a1401981] Failed to properly
> initialize Processor. If still scheduled to run, NiFi will attempt to
> initialize and run the Processor again after the 'Administrative Yield
> Duration' has elapsed. Failure is due to
> java.lang.reflect.InvocationTargetException:
> java.lang.reflect.InvocationTargetException
> java.lang.reflect.InvocationTargetException: null
> at sun.reflect.GeneratedMethodAccessor916.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:142)
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:130)
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:75)
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotation(ReflectionUtils.java:52)
> at
> org.apache.nifi.controller.StandardProcessorNode.lambda$initiateStart$4(StandardProcessorNode.java:1499)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
> org.apache.nifi.attribute.expression.language.exception.AttributeExpressionLanguageException:
> Subject is empty
> at
> org.apache.nifi.attribute.expression.language.evaluation.functions.JsonPathEvaluator.evaluate(JsonPathEvaluator.java:66)
> at
> org.apache.nifi.attribute.expression.language.Query.evaluate(Query.java:315)
> at
> org.apache.nifi.attribute.expression.language.Query.evaluateExpression(Query.java:203)
> at
> org.apache.nifi.attribute.expression.language.CompiledExpression.evaluate(CompiledExpression.java:58)
> at
> org.apache.nifi.attribute.expression.language.StandardPreparedQuery.evaluateExpressions(StandardPreparedQuery.java:51)
> at
>
[jira] [Updated] (NIFI-5817) QueryRecord processor exception when using JsonPath expression language
[
https://issues.apache.org/jira/browse/NIFI-5817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mandeep Gill updated NIFI-5817:
---
Environment: Linux x64 (Fedora 29) with OpenJSDK 8 (openjdk version
"1.8.0_191") (was: Linux (Fedora 29) with OpenJSDK 8 (openjdk version
"1.8.0_191"))
> QueryRecord processor exception when using JsonPath expression language
>
>
> Key: NIFI-5817
> URL: https://issues.apache.org/jira/browse/NIFI-5817
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.8.0
> Environment: Linux x64 (Fedora 29) with OpenJSDK 8 (openjdk version
> "1.8.0_191")
>Reporter: Mandeep Gill
>Priority: Major
> Attachments: QueryRecord_JsonPath_Issue.xml
>
>
> (From email to the users list)
>
> I'm hitting an issue using the "jsonPath" expression language function to
> extract a query to use with the QueryRecord processor. The processor works
> fine if the expression language subject is contained within the process group
> variable registry, but fails upon starting with an
> `AttributeExpressionLanguageException` if the subject was expected to to
> exist within a flowfile attribute [1]
>
> I've attached a template generated on NiFi 1.8.0 demonstrating the problem -
> it only appears to be an issue with dynamic outputs from the QueryRecord
> processor, as the same expression language statement works fine when used as
> part of UpdateAttribute processor with the subject in a flowfile attribute as
> per the template. I've dug into the codebase and can trace the error to the
> `evaluate` function within the `JsonPathEvaluator` class, which throws the
> exception if the variable can not be referenced. I have a local fix at
> [https://github.com/apache/nifi/compare/master...nstack:fix/jsonpath] that
> returns `StringQueryResult("")` if the subject is empty instead of throwing
> the exception and this appears to work.
>
> However I'm not sure if this is the correct fix as UpdateAttribute works,
> perhaps the problem is instead in QueryRecord eagerly evaluating the queries
> thus triggering the `evaluate` function.
>
> [1] 2018-11-13 14:46:24,899 ERROR [Timer-Driven Process Thread-1]
> o.a.nifi.processors.standard.QueryRecord
> QueryRecord[id=0d5684e2-0167-1000-74c1-eb29a1401981] Failed to properly
> initialize Processor. If still scheduled to run, NiFi will attempt to
> initialize and run the Processor again after the 'Administrative Yield
> Duration' has elapsed. Failure is due to
> java.lang.reflect.InvocationTargetException:
> java.lang.reflect.InvocationTargetException
> java.lang.reflect.InvocationTargetException: null
> at sun.reflect.GeneratedMethodAccessor916.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:142)
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:130)
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:75)
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotation(ReflectionUtils.java:52)
> at
> org.apache.nifi.controller.StandardProcessorNode.lambda$initiateStart$4(StandardProcessorNode.java:1499)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
> org.apache.nifi.attribute.expression.language.exception.AttributeExpressionLanguageException:
> Subject is empty
> at
> org.apache.nifi.attribute.expression.language.evaluation.functions.JsonPathEvaluator.evaluate(JsonPathEvaluator.java:66)
> at
> org.apache.nifi.attribute.expression.language.Query.evaluate(Query.java:315)
> at
> org.apache.nifi.attribute.expression.language.Query.evaluateExpression(Query.java:203)
> at
> org.apache.nifi.attribute.expression.language.CompiledExpression.evaluate(CompiledExpression.java:58)
> at
> org.apache.nifi.attribute.expression.language.StandardPreparedQuery.evaluateExpressions(StandardPreparedQuery.java:51)
> at
> org.apache.nifi.attribute.expression.language.StandardPropertyValue.evaluateAttributeExpressions(StandardPropertyValue.java:160)
> at
>
[jira] [Updated] (NIFI-5817) QueryRecord processor exception when using JsonPath expression language
[
https://issues.apache.org/jira/browse/NIFI-5817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mandeep Gill updated NIFI-5817:
---
Summary: QueryRecord processor exception when using JsonPath expression
language (was: JsonPath expression language exception with QueryRecord
processor)
> QueryRecord processor exception when using JsonPath expression language
>
>
> Key: NIFI-5817
> URL: https://issues.apache.org/jira/browse/NIFI-5817
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.8.0
> Environment: Linux (Fedora 29) with OpenJSDK 8 (openjdk version
> "1.8.0_191")
>Reporter: Mandeep Gill
>Priority: Major
> Attachments: QueryRecord_JsonPath_Issue.xml
>
>
> (From email to the users list)
>
> I'm hitting an issue using the "jsonPath" expression language function to
> extract a query to use with the QueryRecord processor. The processor works
> fine if the expression language subject is contained within the process group
> variable registry, but fails upon starting with an
> `AttributeExpressionLanguageException` if the subject was expected to to
> exist within a flowfile attribute [1]
>
> I've attached a template generated on NiFi 1.8.0 demonstrating the problem -
> it only appears to be an issue with dynamic outputs from the QueryRecord
> processor, as the same expression language statement works fine when used as
> part of UpdateAttribute processor with the subject in a flowfile attribute as
> per the template. I've dug into the codebase and can trace the error to the
> `evaluate` function within the `JsonPathEvaluator` class, which throws the
> exception if the variable can not be referenced. I have a local fix at
> [https://github.com/apache/nifi/compare/master...nstack:fix/jsonpath] that
> returns `StringQueryResult("")` if the subject is empty instead of throwing
> the exception and this appears to work.
>
> However I'm not sure if this is the correct fix as UpdateAttribute works,
> perhaps the problem is instead in QueryRecord eagerly evaluating the queries
> thus triggering the `evaluate` function.
>
> [1] 2018-11-13 14:46:24,899 ERROR [Timer-Driven Process Thread-1]
> o.a.nifi.processors.standard.QueryRecord
> QueryRecord[id=0d5684e2-0167-1000-74c1-eb29a1401981] Failed to properly
> initialize Processor. If still scheduled to run, NiFi will attempt to
> initialize and run the Processor again after the 'Administrative Yield
> Duration' has elapsed. Failure is due to
> java.lang.reflect.InvocationTargetException:
> java.lang.reflect.InvocationTargetException
> java.lang.reflect.InvocationTargetException: null
> at sun.reflect.GeneratedMethodAccessor916.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:142)
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:130)
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:75)
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotation(ReflectionUtils.java:52)
> at
> org.apache.nifi.controller.StandardProcessorNode.lambda$initiateStart$4(StandardProcessorNode.java:1499)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
> org.apache.nifi.attribute.expression.language.exception.AttributeExpressionLanguageException:
> Subject is empty
> at
> org.apache.nifi.attribute.expression.language.evaluation.functions.JsonPathEvaluator.evaluate(JsonPathEvaluator.java:66)
> at
> org.apache.nifi.attribute.expression.language.Query.evaluate(Query.java:315)
> at
> org.apache.nifi.attribute.expression.language.Query.evaluateExpression(Query.java:203)
> at
> org.apache.nifi.attribute.expression.language.CompiledExpression.evaluate(CompiledExpression.java:58)
> at
> org.apache.nifi.attribute.expression.language.StandardPreparedQuery.evaluateExpressions(StandardPreparedQuery.java:51)
> at
> org.apache.nifi.attribute.expression.language.StandardPropertyValue.evaluateAttributeExpressions(StandardPropertyValue.java:160)
> at
>
[jira] [Updated] (NIFI-5817) JsonPath expression language exception with QueryRecord processor
[
https://issues.apache.org/jira/browse/NIFI-5817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mandeep Gill updated NIFI-5817:
---
Description:
(From email to the users list)
I'm hitting an issue using the "jsonPath" expression language function to
extract a query to use with the QueryRecord processor. The processor works fine
if the expression language subject is contained within the process group
variable registry, but fails upon starting with an
`AttributeExpressionLanguageException` if the subject was expected to to exist
within a flowfile attribute [1]
I've attached a template generated on NiFi 1.8.0 demonstrating the problem -
it only appears to be an issue with dynamic outputs from the QueryRecord
processors, as the same expression language statement works fine when used as
part of UpdateAttribute processor with the subject in a flowfile attribute as
per the template. I've dug into the codebase and can trace the error to the
`evaluate` function within the `JsonPathEvaluator` class, which throws the
exception if the variable can not be referenced. I have a local fix at
[https://github.com/apache/nifi/compare/master...nstack:fix/jsonpath] that
returns `StringQueryResult("")` if the subject is empty instead of throwing the
exception and this appears to work.
However I'm not sure if this is the correct fix as UpdateAttribute works,
perhaps the problem is instead in QueryRecord eagerly evaluating the queries
thus triggering the `evaluate` function.
```
[1] 2018-11-13 14:46:24,899 ERROR [Timer-Driven Process Thread-1]
o.a.nifi.processors.standard.QueryRecord
QueryRecord[id=0d5684e2-0167-1000-74c1-eb29a1401981] Failed to properly
initialize Processor. If still scheduled to run, NiFi will attempt to
initialize and run the Processor again after the 'Administrative Yield
Duration' has elapsed. Failure is due to
java.lang.reflect.InvocationTargetException:
java.lang.reflect.InvocationTargetException
java.lang.reflect.InvocationTargetException: null
at sun.reflect.GeneratedMethodAccessor916.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:142)
at
org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:130)
at
org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:75)
at
org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotation(ReflectionUtils.java:52)
at
org.apache.nifi.controller.StandardProcessorNode.lambda$initiateStart$4(StandardProcessorNode.java:1499)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by:
org.apache.nifi.attribute.expression.language.exception.AttributeExpressionLanguageException:
Subject is empty
at
org.apache.nifi.attribute.expression.language.evaluation.functions.JsonPathEvaluator.evaluate(JsonPathEvaluator.java:66)
at
org.apache.nifi.attribute.expression.language.Query.evaluate(Query.java:315)
at
org.apache.nifi.attribute.expression.language.Query.evaluateExpression(Query.java:203)
at
org.apache.nifi.attribute.expression.language.CompiledExpression.evaluate(CompiledExpression.java:58)
at
org.apache.nifi.attribute.expression.language.StandardPreparedQuery.evaluateExpressions(StandardPreparedQuery.java:51)
at
org.apache.nifi.attribute.expression.language.StandardPropertyValue.evaluateAttributeExpressions(StandardPropertyValue.java:160)
at
org.apache.nifi.attribute.expression.language.StandardPropertyValue.evaluateAttributeExpressions(StandardPropertyValue.java:148)
at
org.apache.nifi.attribute.expression.language.StandardPropertyValue.evaluateAttributeExpressions(StandardPropertyValue.java:113)
at
org.apache.nifi.processors.standard.QueryRecord.setupQueues(QueryRecord.java:443)
... 14 common frames omitted
```
was:
(From email to the users list)
I'm hitting an issue using the "jsonPath" expression language function to
extract a query to use with the QueryRecord processor. The processor works fine
if the expression language subject is contained within the process group
variable registry, but fails upon starting with an
[jira] [Updated] (NIFI-5817) QueryRecord processor exception when using JsonPath expression language
[
https://issues.apache.org/jira/browse/NIFI-5817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mandeep Gill updated NIFI-5817:
---
Environment: Linux x64 (Fedora 29) with OpenJDK 8 (openjdk version
"1.8.0_191") (was: Linux x64 (Fedora 29) with OpenJSDK 8 (openjdk version
"1.8.0_191"))
> QueryRecord processor exception when using JsonPath expression language
>
>
> Key: NIFI-5817
> URL: https://issues.apache.org/jira/browse/NIFI-5817
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.8.0
> Environment: Linux x64 (Fedora 29) with OpenJDK 8 (openjdk version
> "1.8.0_191")
>Reporter: Mandeep Gill
>Priority: Major
> Attachments: QueryRecord_JsonPath_Issue.xml
>
>
> (From email to the users list)
>
> I'm hitting an issue using the "jsonPath" expression language function to
> extract a query to use with the QueryRecord processor. The processor works
> fine if the expression language subject is contained within the process group
> variable registry, but fails upon starting with an
> `AttributeExpressionLanguageException` if the subject was expected to to
> exist within a flowfile attribute [1]
>
> I've attached a template generated on NiFi 1.8.0 demonstrating the problem -
> it only appears to be an issue with dynamic outputs from the QueryRecord
> processor, as the same expression language statement works fine when used as
> part of UpdateAttribute processor with the subject in a flowfile attribute as
> per the template. I've dug into the codebase and can trace the error to the
> `evaluate` function within the `JsonPathEvaluator` class, which throws the
> exception if the variable can not be referenced. I have a local fix at
> [https://github.com/apache/nifi/compare/master...nstack:fix/jsonpath] that
> returns `StringQueryResult("")` if the subject is empty instead of throwing
> the exception and this appears to work.
>
> However I'm not sure if this is the correct fix as UpdateAttribute works,
> perhaps the problem is instead in QueryRecord eagerly evaluating the queries
> thus triggering the `evaluate` function.
>
> [1] 2018-11-13 14:46:24,899 ERROR [Timer-Driven Process Thread-1]
> o.a.nifi.processors.standard.QueryRecord
> QueryRecord[id=0d5684e2-0167-1000-74c1-eb29a1401981] Failed to properly
> initialize Processor. If still scheduled to run, NiFi will attempt to
> initialize and run the Processor again after the 'Administrative Yield
> Duration' has elapsed. Failure is due to
> java.lang.reflect.InvocationTargetException:
> java.lang.reflect.InvocationTargetException
> java.lang.reflect.InvocationTargetException: null
> at sun.reflect.GeneratedMethodAccessor916.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:142)
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:130)
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:75)
> at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotation(ReflectionUtils.java:52)
> at
> org.apache.nifi.controller.StandardProcessorNode.lambda$initiateStart$4(StandardProcessorNode.java:1499)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
> org.apache.nifi.attribute.expression.language.exception.AttributeExpressionLanguageException:
> Subject is empty
> at
> org.apache.nifi.attribute.expression.language.evaluation.functions.JsonPathEvaluator.evaluate(JsonPathEvaluator.java:66)
> at
> org.apache.nifi.attribute.expression.language.Query.evaluate(Query.java:315)
> at
> org.apache.nifi.attribute.expression.language.Query.evaluateExpression(Query.java:203)
> at
> org.apache.nifi.attribute.expression.language.CompiledExpression.evaluate(CompiledExpression.java:58)
> at
> org.apache.nifi.attribute.expression.language.StandardPreparedQuery.evaluateExpressions(StandardPreparedQuery.java:51)
> at
> org.apache.nifi.attribute.expression.language.StandardPropertyValue.evaluateAttributeExpressions(StandardPropertyValue.java:160)
> at
>
[jira] [Updated] (NIFI-5817) JsonPath expression language exception with QueryRecord processor
[
https://issues.apache.org/jira/browse/NIFI-5817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mandeep Gill updated NIFI-5817:
---
Description:
(From email to the users list)
I'm hitting an issue using the "jsonPath" expression language function to
extract a query to use with the QueryRecord processor. The processor works fine
if the expression language subject is contained within the process group
variable registry, but fails upon starting with an
`AttributeExpressionLanguageException` if the subject was expected to to exist
within a flowfile attribute [1]
I've attached a template generated on NiFi 1.8.0 demonstrating the problem -
it only appears to be an issue with dynamic outputs from the QueryRecord
processor, as the same expression language statement works fine when used as
part of UpdateAttribute processor with the subject in a flowfile attribute as
per the template. I've dug into the codebase and can trace the error to the
`evaluate` function within the `JsonPathEvaluator` class, which throws the
exception if the variable can not be referenced. I have a local fix at
[https://github.com/apache/nifi/compare/master...nstack:fix/jsonpath] that
returns `StringQueryResult("")` if the subject is empty instead of throwing the
exception and this appears to work.
However I'm not sure if this is the correct fix as UpdateAttribute works,
perhaps the problem is instead in QueryRecord eagerly evaluating the queries
thus triggering the `evaluate` function.
[1] 2018-11-13 14:46:24,899 ERROR [Timer-Driven Process Thread-1]
o.a.nifi.processors.standard.QueryRecord
QueryRecord[id=0d5684e2-0167-1000-74c1-eb29a1401981] Failed to properly
initialize Processor. If still scheduled to run, NiFi will attempt to
initialize and run the Processor again after the 'Administrative Yield
Duration' has elapsed. Failure is due to
java.lang.reflect.InvocationTargetException:
java.lang.reflect.InvocationTargetException
java.lang.reflect.InvocationTargetException: null
at sun.reflect.GeneratedMethodAccessor916.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:142)
at
org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:130)
at
org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:75)
at
org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotation(ReflectionUtils.java:52)
at
org.apache.nifi.controller.StandardProcessorNode.lambda$initiateStart$4(StandardProcessorNode.java:1499)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by:
org.apache.nifi.attribute.expression.language.exception.AttributeExpressionLanguageException:
Subject is empty
at
org.apache.nifi.attribute.expression.language.evaluation.functions.JsonPathEvaluator.evaluate(JsonPathEvaluator.java:66)
at org.apache.nifi.attribute.expression.language.Query.evaluate(Query.java:315)
at
org.apache.nifi.attribute.expression.language.Query.evaluateExpression(Query.java:203)
at
org.apache.nifi.attribute.expression.language.CompiledExpression.evaluate(CompiledExpression.java:58)
at
org.apache.nifi.attribute.expression.language.StandardPreparedQuery.evaluateExpressions(StandardPreparedQuery.java:51)
at
org.apache.nifi.attribute.expression.language.StandardPropertyValue.evaluateAttributeExpressions(StandardPropertyValue.java:160)
at
org.apache.nifi.attribute.expression.language.StandardPropertyValue.evaluateAttributeExpressions(StandardPropertyValue.java:148)
at
org.apache.nifi.attribute.expression.language.StandardPropertyValue.evaluateAttributeExpressions(StandardPropertyValue.java:113)
at
org.apache.nifi.processors.standard.QueryRecord.setupQueues(QueryRecord.java:443)
... 14 common frames omitted
was:
(From email to the users list)
I'm hitting an issue using the "jsonPath" expression language function to
extract a query to use with the QueryRecord processor. The processor works fine
if the expression language subject is contained within the process group
variable registry, but fails upon starting with an
`AttributeExpressionLanguageException` if the subject was expected to to exist
within a flowfile attribute [1]
I've attached a template generated on NiFi 1.8.0 demonstrating the problem -
it only appears to be an issue with
[jira] [Created] (NIFI-5817) JsonPath expression language exception with QueryRecord processor
Mandeep Gill created NIFI-5817:
--
Summary: JsonPath expression language exception with QueryRecord
processor
Key: NIFI-5817
URL: https://issues.apache.org/jira/browse/NIFI-5817
Project: Apache NiFi
Issue Type: Bug
Components: Core Framework
Affects Versions: 1.8.0
Environment: Linux (Fedora 29) with OpenJSDK 8 (openjdk version
"1.8.0_191")
Reporter: Mandeep Gill
Attachments: QueryRecord_JsonPath_Issue.xml
(From email to the users list)
I'm hitting an issue using the "jsonPath" expression language function to
extract a query to use with the QueryRecord processor. The processor works fine
if the expression language subject is contained within the process group
variable registry, but fails upon starting with an
`AttributeExpressionLanguageException` if the subject was expected to to exist
within a flowfile attribute [1]
I've attached a template generated on NiFi 1.8.0 demonstrating the problem - it
only appears to be an issue with dynamic outputs from the QueryRecord
processors, as the same expression language statement works fine when used as
part of UpdateAttribute processor with the subject in a flowfile attribute as
per the template. I've dug into the codebase and can trace the error to the
`evaluate` function within the `JsonPathEvaluator` class, which throws the
exception if the variable can not be referenced. I have a local fix at
[https://github.com/apache/nifi/compare/master...nstack:fix/jsonpath] that
returns `StringQueryResult("")` if the subject is empty instead of throwing the
exception and this appears to work.
However I'm not sure if this is the correct fix as UpdateAttribute works,
perhaps the problem is instead in QueryRecord eagerly evaluating the queries
thus triggering the `evaluate` function.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NIFI-5604) Allow GenerateTableFetch to send empty flow files when no rows would be fetched
[
https://issues.apache.org/jira/browse/NIFI-5604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685496#comment-16685496
]
ASF GitHub Bot commented on NIFI-5604:
--
Github user mattyb149 commented on a diff in the pull request:
https://github.com/apache/nifi/pull/3075#discussion_r233142376
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/GenerateTableFetch.java
---
@@ -434,48 +448,53 @@ public void onTrigger(final ProcessContext context,
final ProcessSessionFactory
numberOfFetches = (partitionSize == 0) ? 1 : (rowCount
/ partitionSize) + (rowCount % partitionSize == 0 ? 0 : 1);
}
-// Generate SQL statements to read "pages" of data
-Long limit = partitionSize == 0 ? null : (long)
partitionSize;
-final String fragmentIdentifier =
UUID.randomUUID().toString();
-for (long i = 0; i < numberOfFetches; i++) {
-// Add a right bounding for the partitioning column if
necessary (only on last partition, meaning we don't need the limit)
-if ((i == numberOfFetches - 1) &&
useColumnValsForPaging && (maxValueClauses.isEmpty() || customWhereClause !=
null)) {
-maxValueClauses.add(columnForPartitioning + " <= "
+ maxValueForPartitioning);
-limit = null;
-}
+// If there are no SQL statements to be generated, still
output an empty flow file if specified by the user
+if (numberOfFetches == 0 &&
outputEmptyFlowFileOnZeroResults) {
+session.transfer((fileToProcess == null) ?
session.create() : session.create(fileToProcess), REL_SUCCESS);
--- End diff --
Good call, will make the change.
> Allow GenerateTableFetch to send empty flow files when no rows would be
> fetched
> ---
>
> Key: NIFI-5604
> URL: https://issues.apache.org/jira/browse/NIFI-5604
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Reporter: Matt Burgess
>Assignee: Matt Burgess
>Priority: Major
>
> Currently, GenerateTableFetch will not output a flow file if there are no
> rows to be fetched. However, it may be desired (especially with incoming flow
> files) that a flow file be sent out even if GTF does not generate any SQL.
> This capability, along with the fragment attributes from NIFI-5601, would
> allow the user to handle this downstream.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] nifi pull request #3075: NIFI-5604: Added property to allow empty FlowFile w...
Github user mattyb149 commented on a diff in the pull request:
https://github.com/apache/nifi/pull/3075#discussion_r233142376
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/GenerateTableFetch.java
---
@@ -434,48 +448,53 @@ public void onTrigger(final ProcessContext context,
final ProcessSessionFactory
numberOfFetches = (partitionSize == 0) ? 1 : (rowCount
/ partitionSize) + (rowCount % partitionSize == 0 ? 0 : 1);
}
-// Generate SQL statements to read "pages" of data
-Long limit = partitionSize == 0 ? null : (long)
partitionSize;
-final String fragmentIdentifier =
UUID.randomUUID().toString();
-for (long i = 0; i < numberOfFetches; i++) {
-// Add a right bounding for the partitioning column if
necessary (only on last partition, meaning we don't need the limit)
-if ((i == numberOfFetches - 1) &&
useColumnValsForPaging && (maxValueClauses.isEmpty() || customWhereClause !=
null)) {
-maxValueClauses.add(columnForPartitioning + " <= "
+ maxValueForPartitioning);
-limit = null;
-}
+// If there are no SQL statements to be generated, still
output an empty flow file if specified by the user
+if (numberOfFetches == 0 &&
outputEmptyFlowFileOnZeroResults) {
+session.transfer((fileToProcess == null) ?
session.create() : session.create(fileToProcess), REL_SUCCESS);
--- End diff --
Good call, will make the change.
---
[jira] [Commented] (NIFI-5604) Allow GenerateTableFetch to send empty flow files when no rows would be fetched
[
https://issues.apache.org/jira/browse/NIFI-5604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685476#comment-16685476
]
ASF GitHub Bot commented on NIFI-5604:
--
Github user patricker commented on a diff in the pull request:
https://github.com/apache/nifi/pull/3075#discussion_r233132498
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/GenerateTableFetch.java
---
@@ -434,48 +448,53 @@ public void onTrigger(final ProcessContext context,
final ProcessSessionFactory
numberOfFetches = (partitionSize == 0) ? 1 : (rowCount
/ partitionSize) + (rowCount % partitionSize == 0 ? 0 : 1);
}
-// Generate SQL statements to read "pages" of data
-Long limit = partitionSize == 0 ? null : (long)
partitionSize;
-final String fragmentIdentifier =
UUID.randomUUID().toString();
-for (long i = 0; i < numberOfFetches; i++) {
-// Add a right bounding for the partitioning column if
necessary (only on last partition, meaning we don't need the limit)
-if ((i == numberOfFetches - 1) &&
useColumnValsForPaging && (maxValueClauses.isEmpty() || customWhereClause !=
null)) {
-maxValueClauses.add(columnForPartitioning + " <= "
+ maxValueForPartitioning);
-limit = null;
-}
+// If there are no SQL statements to be generated, still
output an empty flow file if specified by the user
+if (numberOfFetches == 0 &&
outputEmptyFlowFileOnZeroResults) {
+session.transfer((fileToProcess == null) ?
session.create() : session.create(fileToProcess), REL_SUCCESS);
--- End diff --
@mattyb149 It's not just the `fragment` attributes, I think you should add
all the standard attributes. Right now this Flowfile get's routed to success
with no attributes at all.
I would suggest refactoring this to include all the standard attributes
like `tablename`, `offset` etc... just like a real FlowFile would have. This
will make it much easier for downstream processors to use this file like
normal. I think the existing logic would cause `offset` to be `null`, which
would make sense for this scenario too.
> Allow GenerateTableFetch to send empty flow files when no rows would be
> fetched
> ---
>
> Key: NIFI-5604
> URL: https://issues.apache.org/jira/browse/NIFI-5604
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Reporter: Matt Burgess
>Assignee: Matt Burgess
>Priority: Major
>
> Currently, GenerateTableFetch will not output a flow file if there are no
> rows to be fetched. However, it may be desired (especially with incoming flow
> files) that a flow file be sent out even if GTF does not generate any SQL.
> This capability, along with the fragment attributes from NIFI-5601, would
> allow the user to handle this downstream.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] nifi pull request #3075: NIFI-5604: Added property to allow empty FlowFile w...
Github user patricker commented on a diff in the pull request:
https://github.com/apache/nifi/pull/3075#discussion_r233132498
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/GenerateTableFetch.java
---
@@ -434,48 +448,53 @@ public void onTrigger(final ProcessContext context,
final ProcessSessionFactory
numberOfFetches = (partitionSize == 0) ? 1 : (rowCount
/ partitionSize) + (rowCount % partitionSize == 0 ? 0 : 1);
}
-// Generate SQL statements to read "pages" of data
-Long limit = partitionSize == 0 ? null : (long)
partitionSize;
-final String fragmentIdentifier =
UUID.randomUUID().toString();
-for (long i = 0; i < numberOfFetches; i++) {
-// Add a right bounding for the partitioning column if
necessary (only on last partition, meaning we don't need the limit)
-if ((i == numberOfFetches - 1) &&
useColumnValsForPaging && (maxValueClauses.isEmpty() || customWhereClause !=
null)) {
-maxValueClauses.add(columnForPartitioning + " <= "
+ maxValueForPartitioning);
-limit = null;
-}
+// If there are no SQL statements to be generated, still
output an empty flow file if specified by the user
+if (numberOfFetches == 0 &&
outputEmptyFlowFileOnZeroResults) {
+session.transfer((fileToProcess == null) ?
session.create() : session.create(fileToProcess), REL_SUCCESS);
--- End diff --
@mattyb149 It's not just the `fragment` attributes, I think you should add
all the standard attributes. Right now this Flowfile get's routed to success
with no attributes at all.
I would suggest refactoring this to include all the standard attributes
like `tablename`, `offset` etc... just like a real FlowFile would have. This
will make it much easier for downstream processors to use this file like
normal. I think the existing logic would cause `offset` to be `null`, which
would make sense for this scenario too.
---
[jira] [Commented] (NIFI-5604) Allow GenerateTableFetch to send empty flow files when no rows would be fetched
[ https://issues.apache.org/jira/browse/NIFI-5604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685470#comment-16685470 ] ASF GitHub Bot commented on NIFI-5604: -- Github user patricker commented on the issue: https://github.com/apache/nifi/pull/3075 Reviewing > Allow GenerateTableFetch to send empty flow files when no rows would be > fetched > --- > > Key: NIFI-5604 > URL: https://issues.apache.org/jira/browse/NIFI-5604 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Matt Burgess >Assignee: Matt Burgess >Priority: Major > > Currently, GenerateTableFetch will not output a flow file if there are no > rows to be fetched. However, it may be desired (especially with incoming flow > files) that a flow file be sent out even if GTF does not generate any SQL. > This capability, along with the fragment attributes from NIFI-5601, would > allow the user to handle this downstream. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi issue #3075: NIFI-5604: Added property to allow empty FlowFile when no ...
Github user patricker commented on the issue: https://github.com/apache/nifi/pull/3075 Reviewing ---
[jira] [Commented] (MINIFICPP-648) add processor and add processor with linkage nomenclature is confusing
[ https://issues.apache.org/jira/browse/MINIFICPP-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685438#comment-16685438 ] ASF GitHub Bot commented on MINIFICPP-648: -- Github user asfgit closed the pull request at: https://github.com/apache/nifi-minifi-cpp/pull/432 > add processor and add processor with linkage nomenclature is confusing > -- > > Key: MINIFICPP-648 > URL: https://issues.apache.org/jira/browse/MINIFICPP-648 > Project: NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Mr TheSegfault >Assignee: Arpad Boda >Priority: Blocker > Labels: CAPI > Fix For: 0.6.0 > > > add_processor should be changed to always add a processor with linkage > without compelling documentation as why this exists.. As a result we will > need to add a create_processor function to create one without adding it to > the flow ( certain use cases where a flow isn't needed such as invokehttp or > listenhttp ) this can be moved to 0.7.0 if we tag before recent commits. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi-minifi-cpp pull request #432: MINIFICPP-648 - add processor and add pro...
Github user asfgit closed the pull request at: https://github.com/apache/nifi-minifi-cpp/pull/432 ---
[jira] [Created] (MINIFICPP-668) RPG does not correctly account for a non-port URI
Mr TheSegfault created MINIFICPP-668: Summary: RPG does not correctly account for a non-port URI Key: MINIFICPP-668 URL: https://issues.apache.org/jira/browse/MINIFICPP-668 Project: NiFi MiNiFi C++ Issue Type: Improvement Reporter: Mr TheSegfault Assignee: Mr TheSegfault The utility to parse URLs allows there to be no port set; however, the RPG code that does the peer lookup in the agent does not correctly deal with this scenario and injects a port "0" into the URL, which is invalid. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5149) GetSplunk Processor should have input flow, which is currently missing
[ https://issues.apache.org/jira/browse/NIFI-5149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685364#comment-16685364 ] Ariën Vijn commented on NIFI-5149: -- Just as [~bende] and [Mohammad|https://issues.apache.org/jira/secure/ViewProfile.jspa?name=seism] I would like to be able to dynamically generate the query-string. So be able to use Expression Language in the query field. > GetSplunk Processor should have input flow, which is currently missing > -- > > Key: NIFI-5149 > URL: https://issues.apache.org/jira/browse/NIFI-5149 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Affects Versions: 1.6.0 >Reporter: Brajendra >Priority: Critical > Labels: getSplunk > > Hi Team, > We have found there is only 'GetSplunk' processor to connect and query to > Splunk in Apache NiFi. > Hence, we this processor does not take any type or input. > > Do we have another type to Apache NiFi processor which can take parameters > as input (details of Splunk indexes, query, instance etc.) from other > processor? > If not then please suggest when such type of processor can be expected in > upcoming release? > > Environment: NiFi 1.5.0 and 1.6.0 > Brajendra Mishra -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-4130) TransformXml - provide a way to define XSLT without external files
[
https://issues.apache.org/jira/browse/NIFI-4130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685334#comment-16685334
]
ASF GitHub Bot commented on NIFI-4130:
--
Github user bdesert commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1953#discussion_r233019686
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/TransformXml.java
---
@@ -82,12 +94,32 @@
public static final PropertyDescriptor XSLT_FILE_NAME = new
PropertyDescriptor.Builder()
.name("XSLT file name")
-.description("Provides the name (including full path) of the
XSLT file to apply to the flowfile XML content.")
-.required(true)
+.description("Provides the name (including full path) of the
XSLT file to apply to the flowfile XML content."
++ "One of the XSLT file name and XSLT controller
properties must be defined.")
+.required(false)
.expressionLanguageSupported(ExpressionLanguageScope.FLOWFILE_ATTRIBUTES)
.addValidator(StandardValidators.FILE_EXISTS_VALIDATOR)
.build();
+public static final PropertyDescriptor XSLT_CONTROLLER = new
PropertyDescriptor.Builder()
+.name("xslt-controller")
+.displayName("XSLT controller")
+.description("Controller used to store XSLT definitions. One
of the XSLT file name and "
++ "XSLT controller properties must be defined.")
+.required(false)
+.identifiesControllerService(StringLookupService.class)
+.build();
+
+public static final PropertyDescriptor XSLT_CONTROLLER_KEY = new
PropertyDescriptor.Builder()
+.name("xslt-controller-key")
+.displayName("XSLT controller key")
+.description("Key used to retrieve the XSLT definition from
the XSLT controller. This property must be set when using "
++ "the XSLT controller property.")
+.required(false)
+
.expressionLanguageSupported(ExpressionLanguageScope.FLOWFILE_ATTRIBUTES)
+.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
--- End diff --
since this property supports EL, shouldn't it be NON_EMPTY_**EL**_VALIDATOR?
> TransformXml - provide a way to define XSLT without external files
> --
>
> Key: NIFI-4130
> URL: https://issues.apache.org/jira/browse/NIFI-4130
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Reporter: Pierre Villard
>Assignee: Pierre Villard
>Priority: Major
>
> In cluster deployments the need to reference external configuration files can
> be annoying since it requires to access to all the NiFi nodes and to
> correctly deploy the files. It would be interesting to leverage the lookup
> controller services in TransformXml to provide a way to define XSLT directly
> from the UI without external configuration files.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NIFI-4130) TransformXml - provide a way to define XSLT without external files
[
https://issues.apache.org/jira/browse/NIFI-4130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685335#comment-16685335
]
ASF GitHub Bot commented on NIFI-4130:
--
Github user bdesert commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1953#discussion_r233016908
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/TransformXml.java
---
@@ -82,12 +94,32 @@
public static final PropertyDescriptor XSLT_FILE_NAME = new
PropertyDescriptor.Builder()
.name("XSLT file name")
-.description("Provides the name (including full path) of the
XSLT file to apply to the flowfile XML content.")
-.required(true)
+.description("Provides the name (including full path) of the
XSLT file to apply to the flowfile XML content."
++ "One of the XSLT file name and XSLT controller
properties must be defined.")
+.required(false)
.expressionLanguageSupported(ExpressionLanguageScope.FLOWFILE_ATTRIBUTES)
.addValidator(StandardValidators.FILE_EXISTS_VALIDATOR)
.build();
+public static final PropertyDescriptor XSLT_CONTROLLER = new
PropertyDescriptor.Builder()
+.name("xslt-controller")
+.displayName("XSLT controller")
--- End diff --
"XSLT Lookup" Would be more readable.
Description: "Lookup controller used to store..."
And: XSLT_CONTROLLER_KEY: "XSLT Lookup Key" (description looks fine)
> TransformXml - provide a way to define XSLT without external files
> --
>
> Key: NIFI-4130
> URL: https://issues.apache.org/jira/browse/NIFI-4130
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Reporter: Pierre Villard
>Assignee: Pierre Villard
>Priority: Major
>
> In cluster deployments the need to reference external configuration files can
> be annoying since it requires to access to all the NiFi nodes and to
> correctly deploy the files. It would be interesting to leverage the lookup
> controller services in TransformXml to provide a way to define XSLT directly
> from the UI without external configuration files.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] nifi pull request #1953: NIFI-4130 Add lookup controller service in Transfor...
Github user bdesert commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1953#discussion_r233016908
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/TransformXml.java
---
@@ -82,12 +94,32 @@
public static final PropertyDescriptor XSLT_FILE_NAME = new
PropertyDescriptor.Builder()
.name("XSLT file name")
-.description("Provides the name (including full path) of the
XSLT file to apply to the flowfile XML content.")
-.required(true)
+.description("Provides the name (including full path) of the
XSLT file to apply to the flowfile XML content."
++ "One of the XSLT file name and XSLT controller
properties must be defined.")
+.required(false)
.expressionLanguageSupported(ExpressionLanguageScope.FLOWFILE_ATTRIBUTES)
.addValidator(StandardValidators.FILE_EXISTS_VALIDATOR)
.build();
+public static final PropertyDescriptor XSLT_CONTROLLER = new
PropertyDescriptor.Builder()
+.name("xslt-controller")
+.displayName("XSLT controller")
--- End diff --
"XSLT Lookup" Would be more readable.
Description: "Lookup controller used to store..."
And: XSLT_CONTROLLER_KEY: "XSLT Lookup Key" (description looks fine)
---
[GitHub] nifi pull request #1953: NIFI-4130 Add lookup controller service in Transfor...
Github user bdesert commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1953#discussion_r233019686
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/TransformXml.java
---
@@ -82,12 +94,32 @@
public static final PropertyDescriptor XSLT_FILE_NAME = new
PropertyDescriptor.Builder()
.name("XSLT file name")
-.description("Provides the name (including full path) of the
XSLT file to apply to the flowfile XML content.")
-.required(true)
+.description("Provides the name (including full path) of the
XSLT file to apply to the flowfile XML content."
++ "One of the XSLT file name and XSLT controller
properties must be defined.")
+.required(false)
.expressionLanguageSupported(ExpressionLanguageScope.FLOWFILE_ATTRIBUTES)
.addValidator(StandardValidators.FILE_EXISTS_VALIDATOR)
.build();
+public static final PropertyDescriptor XSLT_CONTROLLER = new
PropertyDescriptor.Builder()
+.name("xslt-controller")
+.displayName("XSLT controller")
+.description("Controller used to store XSLT definitions. One
of the XSLT file name and "
++ "XSLT controller properties must be defined.")
+.required(false)
+.identifiesControllerService(StringLookupService.class)
+.build();
+
+public static final PropertyDescriptor XSLT_CONTROLLER_KEY = new
PropertyDescriptor.Builder()
+.name("xslt-controller-key")
+.displayName("XSLT controller key")
+.description("Key used to retrieve the XSLT definition from
the XSLT controller. This property must be set when using "
++ "the XSLT controller property.")
+.required(false)
+
.expressionLanguageSupported(ExpressionLanguageScope.FLOWFILE_ATTRIBUTES)
+.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
--- End diff --
since this property supports EL, shouldn't it be NON_EMPTY_**EL**_VALIDATOR?
---
[jira] [Commented] (NIFI-5333) Create GetMongoRecord processor
[ https://issues.apache.org/jira/browse/NIFI-5333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685330#comment-16685330 ] ASF GitHub Bot commented on NIFI-5333: -- Github user MikeThomsen commented on the issue: https://github.com/apache/nifi/pull/3011 Thanks @zenfenan. Could you and/or @mattyb149 take a look at 4975 as well sometime? That's the GridFS support. Would really like to give NiFi the ability to work natively with that. > Create GetMongoRecord processor > --- > > Key: NIFI-5333 > URL: https://issues.apache.org/jira/browse/NIFI-5333 > Project: Apache NiFi > Issue Type: New Feature >Reporter: Mike Thomsen >Assignee: Mike Thomsen >Priority: Major > > A processor similar to GetMongo that uses the record API should be created. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi issue #3011: NIFI-5333 Added GetMongoRecord.
Github user MikeThomsen commented on the issue: https://github.com/apache/nifi/pull/3011 Thanks @zenfenan. Could you and/or @mattyb149 take a look at 4975 as well sometime? That's the GridFS support. Would really like to give NiFi the ability to work natively with that. ---
[jira] [Commented] (NIFI-5791) Add Apache Daffodil parse/unparse processor
[ https://issues.apache.org/jira/browse/NIFI-5791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685210#comment-16685210 ] ASF GitHub Bot commented on NIFI-5791: -- Github user stevedlawrence commented on the issue: https://github.com/apache/nifi/pull/3130 After some research and reading the [Avro specification](https://avro.apache.org/docs/1.8.1/spec.html) , I'd agree that the DFDL infoset does seem somewhat similar to a Record. DFDL does support all the primitive types (null, boolean, int, long, float, double, bytes, string) and logical types (date, time, decimal), plus a few others (integer, byte, short, signed/unsigned) . But as far as complex types, it only really supports "records" and arrays. Below is the list of things in Avro that the DFDL infoset does not support: * It sort of supports enums, but only in the sense that it can validate that a primitive type is one of the valid enum values via the xsd:restriction. * Maps. In DFDL, a map would be implemented as a sequence of key/value pairs, so there wouldn't be any enforcement of unique keys. * Unions. Each element in the infoset must have an explicit primitive type. Each element can be optional or nulled, but cannot be a union of multiple primitive types. In DFDL, that is handled by an xs:choice of two different elements with different types and some method (often a discriminator) to determine which branch of the choice. * Namespaces are slightly different, but probably similar enough. DFDL uses XML namespacing. * Aliases are not supported. * Sort order. DFDL outputs infoset elements in the order in which they appear in schema. * The DFDL infoset does not contain the schema. One must keep track of the associated schema outside of the data. * The isn't really a concept of different serializations like Avro looks to have. Instead, the DFDL schema defines the physical data format via DFDL annotations, which are used to determine how to serialize/deserialize data. Theoretically, one could have different schemas with the same logical format but with with different DFDL annotations to describe physical formats, but that isn't a comment use case we've come across. The Daffodil devs would be happen to discuss the possibility of integrating Daffodil/DFDL as an alternative to Avro. Not sure if any of the above limitations are blockers. The core of Avro and DFDL definitely do seem to have some overlap. > Add Apache Daffodil parse/unparse processor > --- > > Key: NIFI-5791 > URL: https://issues.apache.org/jira/browse/NIFI-5791 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Reporter: Steve Lawrence >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi issue #3130: NIFI-5791: Add Apache Daffodil (incubating) bundle
Github user stevedlawrence commented on the issue: https://github.com/apache/nifi/pull/3130 After some research and reading the [Avro specification](https://avro.apache.org/docs/1.8.1/spec.html) , I'd agree that the DFDL infoset does seem somewhat similar to a Record. DFDL does support all the primitive types (null, boolean, int, long, float, double, bytes, string) and logical types (date, time, decimal), plus a few others (integer, byte, short, signed/unsigned) . But as far as complex types, it only really supports "records" and arrays. Below is the list of things in Avro that the DFDL infoset does not support: * It sort of supports enums, but only in the sense that it can validate that a primitive type is one of the valid enum values via the xsd:restriction. * Maps. In DFDL, a map would be implemented as a sequence of key/value pairs, so there wouldn't be any enforcement of unique keys. * Unions. Each element in the infoset must have an explicit primitive type. Each element can be optional or nulled, but cannot be a union of multiple primitive types. In DFDL, that is handled by an xs:choice of two different elements with different types and some method (often a discriminator) to determine which branch of the choice. * Namespaces are slightly different, but probably similar enough. DFDL uses XML namespacing. * Aliases are not supported. * Sort order. DFDL outputs infoset elements in the order in which they appear in schema. * The DFDL infoset does not contain the schema. One must keep track of the associated schema outside of the data. * The isn't really a concept of different serializations like Avro looks to have. Instead, the DFDL schema defines the physical data format via DFDL annotations, which are used to determine how to serialize/deserialize data. Theoretically, one could have different schemas with the same logical format but with with different DFDL annotations to describe physical formats, but that isn't a comment use case we've come across. The Daffodil devs would be happen to discuss the possibility of integrating Daffodil/DFDL as an alternative to Avro. Not sure if any of the above limitations are blockers. The core of Avro and DFDL definitely do seem to have some overlap. ---
[jira] [Commented] (NIFIREG-188) Login by hitting Enter in the password field in web UI
[ https://issues.apache.org/jira/browse/NIFIREG-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685163#comment-16685163 ] ASF GitHub Bot commented on NIFIREG-188: GitHub user kotarot opened a pull request: https://github.com/apache/nifi-registry/pull/147 NIFIREG-188: Login by hitting Enter in the input fields in web UI In this improvement, I appended the angular `keyup` event on the both input fields to achieve the feature. Could anyone review it please? You can merge this pull request into a Git repository by running: $ git pull https://github.com/kotarot/nifi-registry NIFIREG-188 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi-registry/pull/147.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #147 commit f72f9dd8e0fafdb929b479041ad16833e378b0e9 Author: Kotaro Terada Date: 2018-11-13T12:16:37Z NIFIREG-188: Login by hitting Enter in the input fields in web UI NIFIREG-188: Fix the case 'keyUp' -> 'keyup' > Login by hitting Enter in the password field in web UI > -- > > Key: NIFIREG-188 > URL: https://issues.apache.org/jira/browse/NIFIREG-188 > Project: NiFi Registry > Issue Type: Improvement >Affects Versions: 0.1.0, 0.2.0 >Reporter: Julian Gimbel >Priority: Minor > > While logging in to Nifi Registry it should be possible to hit enter in the > password field to login instead of using the mouse or tab on to the login > button. > Unfortunately I am not experienced enough with angular to do it myself. > It is not as simple as just adding a tag around the dialog fields and > buttons. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi-registry pull request #147: NIFIREG-188: Login by hitting Enter in the ...
GitHub user kotarot opened a pull request: https://github.com/apache/nifi-registry/pull/147 NIFIREG-188: Login by hitting Enter in the input fields in web UI In this improvement, I appended the angular `keyup` event on the both input fields to achieve the feature. Could anyone review it please? You can merge this pull request into a Git repository by running: $ git pull https://github.com/kotarot/nifi-registry NIFIREG-188 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi-registry/pull/147.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #147 commit f72f9dd8e0fafdb929b479041ad16833e378b0e9 Author: Kotaro Terada Date: 2018-11-13T12:16:37Z NIFIREG-188: Login by hitting Enter in the input fields in web UI NIFIREG-188: Fix the case 'keyUp' -> 'keyup' ---
[jira] [Commented] (NIFI-5816) SFTP cannot connect due to JSch limitations
[ https://issues.apache.org/jira/browse/NIFI-5816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685151#comment-16685151 ] Joseph Witt commented on NIFI-5816: --- SSHJ is ALv2 so that is good. I've not confirmed whether it has any dependencies and if so what they're licensing is but this is a good start. Such a switch would require a lot of testing/verification as the SFTP processors that depend on JSCH are extremely heavy use and for many years type processors. > SFTP cannot connect due to JSch limitations > --- > > Key: NIFI-5816 > URL: https://issues.apache.org/jira/browse/NIFI-5816 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.8.0 >Reporter: Laurenceau Julien >Priority: Minor > > Hi, > The JSch library used for SFTP does not support HostKeyAlgorithms=ed25519 > whereas it is the current standard. This make SFTP / SSH unusable when > dealing with recent openssh config. > On dbeaver project they switched to sshj. > [https://github.com/dbeaver/dbeaver/issues/2202] > [https://community.hortonworks.com/answers/226377/view.html] > > https://stackoverflow.com/questions/2003419/com-jcraft-jsch-jschexception-unknownhostkey > One more argument against JSch is that it does not support rsa key length > other than default (2048). > ssh-keygen -o -t rsa -b 4096 -f id_rsa -> does not work with nifi > ssh-keygen -t rsa -f id_rsa -> works with nifi > Thanks and regards > JL > PS : sorry but I do not know nifi deep enough to fill all fields. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFIREG-188) Login by hitting Enter in the password field in web UI
[ https://issues.apache.org/jira/browse/NIFIREG-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16685137#comment-16685137 ] Kotaro Terada commented on NIFIREG-188: --- I recently started using NiFi Registry, and encountered the same inconvenience. I will work on this issue. Could anyone assign this to me? > Login by hitting Enter in the password field in web UI > -- > > Key: NIFIREG-188 > URL: https://issues.apache.org/jira/browse/NIFIREG-188 > Project: NiFi Registry > Issue Type: Improvement >Affects Versions: 0.1.0, 0.2.0 >Reporter: Julian Gimbel >Priority: Minor > > While logging in to Nifi Registry it should be possible to hit enter in the > password field to login instead of using the mouse or tab on to the login > button. > Unfortunately I am not experienced enough with angular to do it myself. > It is not as simple as just adding a tag around the dialog fields and > buttons. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-5816) SFTP cannot connect due to JSch limitations
[ https://issues.apache.org/jira/browse/NIFI-5816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Laurenceau Julien updated NIFI-5816: Description: Hi, The JSch library used for SFTP does not support HostKeyAlgorithms=ed25519 whereas it is the current standard. This make SFTP / SSH unusable when dealing with recent openssh config. On dbeaver project they switched to sshj. [https://github.com/dbeaver/dbeaver/issues/2202] [https://community.hortonworks.com/answers/226377/view.html] https://stackoverflow.com/questions/2003419/com-jcraft-jsch-jschexception-unknownhostkey One more argument against JSch is that it does not support rsa key length other than default (2048). ssh-keygen -o -t rsa -b 4096 -f id_rsa -> does not work with nifi ssh-keygen -t rsa -f id_rsa -> works with nifi Thanks and regards JL PS : sorry but I do not know nifi deep enough to fill all fields. was: Hi, The JSch library used for SFTP does not support HostKeyAlgorithms=ed25519 whereas it is the current standard. This make SFTP / SSH unusable when dealing with recent openssh config. On dbeaver project they switched to sshj. [https://github.com/dbeaver/dbeaver/issues/2202] [https://community.hortonworks.com/answers/226377/view.html] One more argument against JSch is that it does not support rsa key length other than default (2048). ssh-keygen -o -t rsa -b 4096 -f id_rsa -> does not work with nifi ssh-keygen -t rsa -f id_rsa -> works with nifi Thanks and regards JL PS : sorry but I do not know nifi deep enough to fill all fields. > SFTP cannot connect due to JSch limitations > --- > > Key: NIFI-5816 > URL: https://issues.apache.org/jira/browse/NIFI-5816 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.8.0 >Reporter: Laurenceau Julien >Priority: Minor > > Hi, > The JSch library used for SFTP does not support HostKeyAlgorithms=ed25519 > whereas it is the current standard. This make SFTP / SSH unusable when > dealing with recent openssh config. > On dbeaver project they switched to sshj. > [https://github.com/dbeaver/dbeaver/issues/2202] > [https://community.hortonworks.com/answers/226377/view.html] > > https://stackoverflow.com/questions/2003419/com-jcraft-jsch-jschexception-unknownhostkey > One more argument against JSch is that it does not support rsa key length > other than default (2048). > ssh-keygen -o -t rsa -b 4096 -f id_rsa -> does not work with nifi > ssh-keygen -t rsa -f id_rsa -> works with nifi > Thanks and regards > JL > PS : sorry but I do not know nifi deep enough to fill all fields. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-5816) SFTP cannot connect due to JSch limitations
[ https://issues.apache.org/jira/browse/NIFI-5816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Laurenceau Julien updated NIFI-5816: Description: Hi, The JSch library used for SFTP does not support HostKeyAlgorithms=ed25519 whereas it is the current standard. This make SFTP / SSH unusable when dealing with recent openssh config. On dbeaver project they switched to sshj. [https://github.com/dbeaver/dbeaver/issues/2202] [https://community.hortonworks.com/answers/226377/view.html] One more argument against JSch is that it does not support rsa key length other than default (2048). ssh-keygen -o -t rsa -b 4096 -f id_rsa -> does not work with nifi ssh-keygen -t rsa -f id_rsa -> works with nifi Thanks and regards JL PS : sorry but I do not know nifi deep enough to fill all fields. was: Hi, The JSch library used for SFTP does not support HostKeyAlgorithms=ed25519 whereas it is the current standard. This make SFTP / SSH unusable when dealing with recent openssh config. On dbeaver project they switched to sshj. https://github.com/dbeaver/dbeaver/issues/2202 [https://community.hortonworks.com/answers/226377/view.html] Thanks and regards JL PS : sorry but I do not know nifi deep enough to fill all fields. Summary: SFTP cannot connect due to JSch limitations (was: SFTP cannot connect using ed25519-based key) > SFTP cannot connect due to JSch limitations > --- > > Key: NIFI-5816 > URL: https://issues.apache.org/jira/browse/NIFI-5816 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.8.0 >Reporter: Laurenceau Julien >Priority: Minor > > Hi, > The JSch library used for SFTP does not support HostKeyAlgorithms=ed25519 > whereas it is the current standard. This make SFTP / SSH unusable when > dealing with recent openssh config. > On dbeaver project they switched to sshj. > [https://github.com/dbeaver/dbeaver/issues/2202] > [https://community.hortonworks.com/answers/226377/view.html] > > One more argument against JSch is that it does not support rsa key length > other than default (2048). > ssh-keygen -o -t rsa -b 4096 -f id_rsa -> does not work with nifi > ssh-keygen -t rsa -f id_rsa -> works with nifi > Thanks and regards > JL > PS : sorry but I do not know nifi deep enough to fill all fields. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5815) PutORC processor "Restricted" still requires access to restricted components regardless of restriction
[
https://issues.apache.org/jira/browse/NIFI-5815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16684878#comment-16684878
]
ASF GitHub Bot commented on NIFI-5815:
--
Github user pvillard31 commented on a diff in the pull request:
https://github.com/apache/nifi/pull/3169#discussion_r232937372
--- Diff:
nifi-nar-bundles/nifi-hive-bundle/nifi-hive3-processors/src/main/java/org/apache/nifi/processors/orc/PutORC.java
---
@@ -63,7 +65,11 @@
+ "the path is the directory that contains this ORC file
on HDFS. For example, this processor can send flow files downstream to
ReplaceText to set the content "
+ "to this DDL (plus the LOCATION clause as described),
then to PutHiveQL processor to create the table if it doesn't exist.")
})
-@Restricted("Provides operator the ability to write to any file that NiFi
has access to in HDFS or the local filesystem.")
+@Restricted(restrictions = {
+@Restriction(
+requiredPermission = RequiredPermission.WRITE_FILESYSTEM,
+explanation = "Provides operator the ability to delete any
file that NiFi has access to in HDFS or the local filesystem.")
--- End diff --
copy/paste stupid error... thanks @ijokarumawak !
> PutORC processor "Restricted" still requires access to restricted components
> regardless of restriction
> --
>
> Key: NIFI-5815
> URL: https://issues.apache.org/jira/browse/NIFI-5815
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 1.6.0, 1.7.0, 1.8.0, 1.7.1
>Reporter: Matthew Clarke
>Assignee: Pierre Villard
>Priority: Major
>
> When the new more granular policies were introduced for the "Access
> Restricted Components" access policy, the PutORC processor was missed. It
> still requires that users have full access to all restricted components in
> order to use this processor. This has side affect of any user who needs to
> use this components having access to all components in every sub policy of
> restricted-components.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] nifi pull request #3169: NIFI-5815 - PutORC processor 'Restricted' still req...
Github user pvillard31 commented on a diff in the pull request:
https://github.com/apache/nifi/pull/3169#discussion_r232937372
--- Diff:
nifi-nar-bundles/nifi-hive-bundle/nifi-hive3-processors/src/main/java/org/apache/nifi/processors/orc/PutORC.java
---
@@ -63,7 +65,11 @@
+ "the path is the directory that contains this ORC file
on HDFS. For example, this processor can send flow files downstream to
ReplaceText to set the content "
+ "to this DDL (plus the LOCATION clause as described),
then to PutHiveQL processor to create the table if it doesn't exist.")
})
-@Restricted("Provides operator the ability to write to any file that NiFi
has access to in HDFS or the local filesystem.")
+@Restricted(restrictions = {
+@Restriction(
+requiredPermission = RequiredPermission.WRITE_FILESYSTEM,
+explanation = "Provides operator the ability to delete any
file that NiFi has access to in HDFS or the local filesystem.")
--- End diff --
copy/paste stupid error... thanks @ijokarumawak !
---
