[jira] [Updated] (NIFI-12523) Provide a way to populate Initial Node Identities for containered envirronment
[
https://issues.apache.org/jira/browse/NIFI-12523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominique Jean-Prost updated NIFI-12523:
Description:
Currently, when running in a container environment (docker for instance) there
is no way to provide values to populate Initial Node Identity which is expected
in {{authorizers.xml}}
cf
[https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#cluster-node-identities]
The startup scripts of nifi in a docker environment only take care for the
moment of {{{}Initial Admin Identity{}}}, but not {{{}Initial Node
Identity{}}}, cf
[https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#cluster-node-identities]
Instead of using a single value for {{{}NODE_IDENTITY{}}}, it should be used a
values list like {{{}INITIAL_NODE_IDENTITIES{}}}, and iterate through the list
and add as much entries in the file.
We could be inspired by
[https://gist.github.com/fdeantoni/529fb4b8b7555b41b7f15643983fe7fb]
was:
Currently, when running in a container environment (docker for instance) there
is no way to provide values to populate Initial Node Identity which is expected
in {{authorizers.xml}}
cf
[https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#cluster-node-identities]
The startup scripts of nifi in a docker environment only take care for the
moment of {{Initial Admin Identity}}, but not {{Initial Node Identity}}, cf
[https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#cluster-node-identities]
Instead of using a single value for {{NODE_IDENTITY}}, it should be used a
values list like {{INITIAL_NODE_IDENTITIES}}, and iterate thought the list and
add as much entries in the file.
We could be inspired by
[https://gist.github.com/fdeantoni/529fb4b8b7555b41b7f15643983fe7fb]
> Provide a way to populate Initial Node Identities for containered envirronment
> --
>
> Key: NIFI-12523
> URL: https://issues.apache.org/jira/browse/NIFI-12523
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Configuration
>Reporter: Dominique Jean-Prost
>Priority: Major
>
> Currently, when running in a container environment (docker for instance)
> there is no way to provide values to populate Initial Node Identity which is
> expected in {{authorizers.xml}}
> cf
> [https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#cluster-node-identities]
> The startup scripts of nifi in a docker environment only take care for the
> moment of {{{}Initial Admin Identity{}}}, but not {{{}Initial Node
> Identity{}}}, cf
> [https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#cluster-node-identities]
> Instead of using a single value for {{{}NODE_IDENTITY{}}}, it should be used
> a values list like {{{}INITIAL_NODE_IDENTITIES{}}}, and iterate through the
> list and add as much entries in the file.
> We could be inspired by
> [https://gist.github.com/fdeantoni/529fb4b8b7555b41b7f15643983fe7fb]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (NIFI-12523) Provide a way to populate Initial Node Identities for containered envirronment
Dominique Jean-Prost created NIFI-12523:
---
Summary: Provide a way to populate Initial Node Identities for
containered envirronment
Key: NIFI-12523
URL: https://issues.apache.org/jira/browse/NIFI-12523
Project: Apache NiFi
Issue Type: Improvement
Components: Configuration
Reporter: Dominique Jean-Prost
Currently, when running in a container environment (docker for instance) there
is no way to provide values to populate Initial Node Identity which is expected
in {{authorizers.xml}}
cf
[https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#cluster-node-identities]
The startup scripts of nifi in a docker environment only take care for the
moment of {{Initial Admin Identity}}, but not {{Initial Node Identity}}, cf
[https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#cluster-node-identities]
Instead of using a single value for {{NODE_IDENTITY}}, it should be used a
values list like {{INITIAL_NODE_IDENTITIES}}, and iterate thought the list and
add as much entries in the file.
We could be inspired by
[https://gist.github.com/fdeantoni/529fb4b8b7555b41b7f15643983fe7fb]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] NIFI-11958 Azure Data Explorer as sink [nifi]
tanmaya-panda1 commented on code in PR #7624:
URL: https://github.com/apache/nifi/pull/7624#discussion_r1430938458
##
nifi-nar-bundles/nifi-azure-bundle/nifi-azure-processors/src/main/java/org/apache/nifi/processors/azure/data/explorer/PutAzureDataExplorer.java:
##
@@ -0,0 +1,282 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.processors.azure.data.explorer;
+
+import org.apache.commons.lang3.StringUtils;
+import org.apache.nifi.annotation.behavior.InputRequirement;
+import org.apache.nifi.annotation.documentation.CapabilityDescription;
+import org.apache.nifi.annotation.documentation.Tags;
+import org.apache.nifi.annotation.lifecycle.OnScheduled;
+import org.apache.nifi.components.AllowableValue;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.expression.ExpressionLanguageScope;
+import org.apache.nifi.flowfile.FlowFile;
+import org.apache.nifi.processor.AbstractProcessor;
+import org.apache.nifi.processor.ProcessContext;
+import org.apache.nifi.processor.ProcessSession;
+import org.apache.nifi.processor.Relationship;
+import org.apache.nifi.processor.exception.ProcessException;
+import org.apache.nifi.processor.util.StandardValidators;
+import org.apache.nifi.services.azure.data.explorer.KustoIngestDataFormat;
+import org.apache.nifi.services.azure.data.explorer.KustoIngestQueryResponse;
+import org.apache.nifi.services.azure.data.explorer.KustoIngestService;
+import org.apache.nifi.services.azure.data.explorer.KustoIngestionRequest;
+import org.apache.nifi.services.azure.data.explorer.KustoIngestionResult;
+
+import java.io.IOException;
+import java.io.InputStream;
+import java.time.Duration;
+import java.util.List;
+import java.util.Set;
+import java.util.concurrent.TimeUnit;
+
+@Tags({"Azure", "Kusto", "ADX", "Explorer", "Data"})
+@CapabilityDescription("The PutAzureDataExplorer acts as a ADX sink connector
which sends flowFiles using the ADX-Service to the provided Azure Data" +
+"Explorer Ingest Endpoint. The data can be sent through queued
ingestion or streaming ingestion to the Azure Data Explorer cluster.")
+@InputRequirement(InputRequirement.Requirement.INPUT_REQUIRED)
+public class PutAzureDataExplorer extends AbstractProcessor {
+
+public static final String FETCH_TABLE_COMMAND = "%s | count";
+public static final String STREAMING_POLICY_SHOW_COMMAND = ".show %s %s
policy streamingingestion";
+public static final String DATABASE = "database";
+public static final AllowableValue IGNORE_FIRST_RECORD_YES = new
AllowableValue(
+"YES", "YES",
+"Ignore first record during ingestion");
+
+public static final AllowableValue IGNORE_FIRST_RECORD_NO = new
AllowableValue(
+"NO", "NO",
+"Do not ignore first record during ingestion");
+
+public static final PropertyDescriptor DATABASE_NAME = new
PropertyDescriptor.Builder()
+.name("Database Name")
+.displayName("Database Name")
+.description("Azure Data Explorer Database Name for querying")
+.required(true)
+.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
+
.expressionLanguageSupported(ExpressionLanguageScope.FLOWFILE_ATTRIBUTES)
+.build();
+public static final PropertyDescriptor TABLE_NAME = new
PropertyDescriptor.Builder()
+.name("Table Name")
+.displayName("Table Name")
+.description("Azure Data Explorer Table Name for ingesting data")
+.required(true)
+.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
+
.expressionLanguageSupported(ExpressionLanguageScope.FLOWFILE_ATTRIBUTES)
+.build();
+public static final PropertyDescriptor MAPPING_NAME = new
PropertyDescriptor
+.Builder().name("Ingest Mapping name")
+.displayName("Ingest Mapping name")
+.description("The name of the mapping responsible for storing the
data in the appropriate columns.")
+.required(false)
+.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
+.build();
+public static final PropertyDescriptor
[jira] [Updated] (NIFI-12402) MonitorActivity generates inactivity indicator after it is started and threshold duration exceeds without actual activities
[ https://issues.apache.org/jira/browse/NIFI-12402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tan Luu updated NIFI-12402: --- Description: Even though there is no activity, a start or restart of MonitorActivity processor produces an inactive flowfile after "Threshold Duration". This behavior creates a false positive notification cause there was no actual activity. The expected behavior is to only send an inactive indicator if there is activity after the processor is started. (was: Even though there is no activity, a start or restart on MonitorActivity processor produces inactive alert after "Threshold Duration". This beahvior create a false positive no) > MonitorActivity generates inactivity indicator after it is started and > threshold duration exceeds without actual activities > --- > > Key: NIFI-12402 > URL: https://issues.apache.org/jira/browse/NIFI-12402 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.23.2 >Reporter: Tan Luu >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > Even though there is no activity, a start or restart of MonitorActivity > processor produces an inactive flowfile after "Threshold Duration". This > behavior creates a false positive notification cause there was no actual > activity. The expected behavior is to only send an inactive indicator if > there is activity after the processor is started. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12402) MonitorActivity generates inactivity indicator after it is started and threshold duration exceeds without actual activities
[
https://issues.apache.org/jira/browse/NIFI-12402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tan Luu updated NIFI-12402:
---
Description: Even though there is no activity, a start or restart on
MonitorActivity processor produces inactive alert after "Threshold Duration".
This beahvior create a false positive no (was: MonitorActivity @OnScheduled
method sets the "{*}inactive"{*} flag to false when it gets started so after
the threshold duration without activity, an inactive indicator is created even
if there is no actual activity.)
> MonitorActivity generates inactivity indicator after it is started and
> threshold duration exceeds without actual activities
> ---
>
> Key: NIFI-12402
> URL: https://issues.apache.org/jira/browse/NIFI-12402
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: 1.23.2
>Reporter: Tan Luu
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Even though there is no activity, a start or restart on MonitorActivity
> processor produces inactive alert after "Threshold Duration". This beahvior
> create a false positive no
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-11579) InvokeHttp is not working when setting Username and password as grant type
[
https://issues.apache.org/jira/browse/NIFI-11579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798390#comment-17798390
]
Grant Cotton commented on NIFI-11579:
-
I get the same outcome (sometimes) when disabling then enabling the
StandardOAuth2AccessTokenProvider (1.23.2, Auth Strategy: Basic Authentication,
Grant Type: Client Credentials). Later in the logs I get
OAuth2 access token request failed [HTTP 400], response:
{"error":"invalid_client"}
but I've verified the credentials directly and they are correct.
There are also times when the issue just resolves and the Controller starts
working. I haven't been able to isolate why. This issue is also described here:
[https://community.cloudera.com/t5/Support-Questions/NiFi-StandardOauth2AccessTokenProvider-1-23-2-Grant-Type/td-p/378951]
but no response to that post either so far.
> InvokeHttp is not working when setting Username and password as grant type
> --
>
> Key: NIFI-11579
> URL: https://issues.apache.org/jira/browse/NIFI-11579
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.20.0, 1.21.0
>Reporter: Vrinda Palod
>Priority: Major
> Attachments: image-2023-05-22-15-49-35-231.png,
> image-2023-05-22-15-51-44-000.png
>
>
> Hi Team,
> I am trying to run Invokrhttp using StandardOauth2AccessTokenProvider
> controller service. When I set basic authentication and username and password
> in my controller service, it throws below error.
> !image-2023-05-22-15-49-35-231.png!
>
> InvokeHTTP[id=32a98900-0188-1000--88fdac58] 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.io.UncheckedIOException: OAuth2
> access token request failed: java.io.UncheckedIOException: OAuth2 access
> token request failed
> - Caused by: com.fasterxml.jackson.core.JsonParseException: Unrecognized
> token
> 'eyJraWQiOiJlN2RmMGRmNS01ODcwLTQ0MjEtOTA2Mi1iZDkyZmVlYWI0MTMiLCJhbGciOiJQUzUxMiJ9':
> was expecting (JSON String, Number, Array, Object or token 'null', 'true' or
> 'false')
> at [Source:
> (String)"eyJraWQiOiJlN2RmMGRmNS01ODcwLTQ0MjEtOTA2Mi1iZDkyZmVlYWI0MTMiLCJhbGciOiJQUzUxMiJ9.eyJzdWIiOiJhNzA1NjQ5IiwiYXVkIjoiTGRhcFByb3ZpZGVyIiwibmJmIjoxNjg0NzUwNTM5LCJpc3MiOiJMZGFwUHJvdmlkZXIiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJhNzA1NjQ5IiwiZXhwIjoxNjg0NzkzNzM5LCJpYXQiOjE2ODQ3NTA1MzksImp0aSI6ImEwNjc3MjNjLWY5ZTgtNDg2Yi1iNjk5LWM3MThlM2JkYjI0ZSJ9.hnUxMPxCKNluxdLkPrlIy6JWkZAjEvbjWfDRxQjBSVXRyXNrcqgHyBb6Ruvca59xeWmEg1p4wuE5AENuzUEcwnuGX5vX-G0gx-4zY1WYpN7pp6JbXnKUxIXLqr4KMDyHAT0_0aVuNbgqJZ1MLOrfssh4jw_Trxol92N4kb0I4z"[truncated
> 513 chars]; line: 1, column: 81]
>
> Below is how I am setting up my controller service. There is no issue with
> endpoint url we are using.
> !image-2023-05-22-15-51-44-000.png!
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-12513) Regression in InvokeHTTP - Not a valid URL
[
https://issues.apache.org/jira/browse/NIFI-12513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798372#comment-17798372
]
Daniel Stieglitz commented on NIFI-12513:
-
Looks like a lot of low level parsing found
[URLStreamHandler#parseURL|https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/java.base/share/classes/java/net/URLStreamHandler.java#L138]
> Regression in InvokeHTTP - Not a valid URL
> --
>
> Key: NIFI-12513
> URL: https://issues.apache.org/jira/browse/NIFI-12513
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 2.0.0-M1, 1.24.0
>Reporter: Pierre Villard
>Assignee: Daniel Stieglitz
>Priority: Major
>
> On NiFi 1.24 and NiFi 2.0-M1, the below URL
> {code:java}
> https://en.wikipedia.org/w/api.php?action=query=recentchanges=json=user|comment|parsedcomment|timestamp|title|sizes|tags{code}
> Is no longer considered as valid but it was a valid one before.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (NIFI-12513) Regression in InvokeHTTP - Not a valid URL
[
https://issues.apache.org/jira/browse/NIFI-12513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798372#comment-17798372
]
Daniel Stieglitz edited comment on NIFI-12513 at 12/18/23 10:32 PM:
Looks like a lot of low level parsing found in
[URLStreamHandler#parseURL|https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/java.base/share/classes/java/net/URLStreamHandler.java#L138]
was (Author: JIRAUSER294662):
Looks like a lot of low level parsing found
[URLStreamHandler#parseURL|https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/java.base/share/classes/java/net/URLStreamHandler.java#L138]
> Regression in InvokeHTTP - Not a valid URL
> --
>
> Key: NIFI-12513
> URL: https://issues.apache.org/jira/browse/NIFI-12513
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 2.0.0-M1, 1.24.0
>Reporter: Pierre Villard
>Assignee: Daniel Stieglitz
>Priority: Major
>
> On NiFi 1.24 and NiFi 2.0-M1, the below URL
> {code:java}
> https://en.wikipedia.org/w/api.php?action=query=recentchanges=json=user|comment|parsedcomment|timestamp|title|sizes|tags{code}
> Is no longer considered as valid but it was a valid one before.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] MINIFICPP-2273 Update minifi documentation [nifi-site]
szaszm commented on code in PR #79: URL: https://github.com/apache/nifi-site/pull/79#discussion_r1430705043 ## source/minifi/minifi-java-about.md: ## @@ -0,0 +1,4 @@ +### MiNiFi Java +The Java agent is built from the same codebase as NiFi, enabling it to run most of [NiFi's processors](http://nifi.apache.org/docs.html). +However, it results in a larger binary distribution and consumes greater system resources, compared to MiNiFi C++. Review Comment: Another big thing for some people is the requirement to install Java on an edge device. Maybe we could add that to the list, if it's not too out-of-scope. ```suggestion However, it results in a larger binary distribution, consumes greater system resources, and requires JRE, compared to MiNiFi C++. ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (NIFI-12513) Regression in InvokeHTTP - Not a valid URL
[
https://issues.apache.org/jira/browse/NIFI-12513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798365#comment-17798365
]
David Handermann commented on NIFI-12513:
-
[~dstiegli1] Although possible, using regular expressions to parse the URL
could be very prone to error when it comes to path and query components. The
scheme, host, and port are straightforward, but the challenging portions are
the path and query, which may or may not need to be encoded.
This probably warrants a closer evaluation of what the java.net.URL constructor
previously did before it was removed.
> Regression in InvokeHTTP - Not a valid URL
> --
>
> Key: NIFI-12513
> URL: https://issues.apache.org/jira/browse/NIFI-12513
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 2.0.0-M1, 1.24.0
>Reporter: Pierre Villard
>Assignee: Daniel Stieglitz
>Priority: Major
>
> On NiFi 1.24 and NiFi 2.0-M1, the below URL
> {code:java}
> https://en.wikipedia.org/w/api.php?action=query=recentchanges=json=user|comment|parsedcomment|timestamp|title|sizes|tags{code}
> Is no longer considered as valid but it was a valid one before.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-12513) Regression in InvokeHTTP - Not a valid URL
[
https://issues.apache.org/jira/browse/NIFI-12513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798361#comment-17798361
]
Daniel Stieglitz commented on NIFI-12513:
-
[~exceptionfactory] Could we use regular expressions to parse the user entered
URL into the parts necessary to instantiate the java.net.URI instance?
> Regression in InvokeHTTP - Not a valid URL
> --
>
> Key: NIFI-12513
> URL: https://issues.apache.org/jira/browse/NIFI-12513
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 2.0.0-M1, 1.24.0
>Reporter: Pierre Villard
>Assignee: Daniel Stieglitz
>Priority: Major
>
> On NiFi 1.24 and NiFi 2.0-M1, the below URL
> {code:java}
> https://en.wikipedia.org/w/api.php?action=query=recentchanges=json=user|comment|parsedcomment|timestamp|title|sizes|tags{code}
> Is no longer considered as valid but it was a valid one before.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] NIFI-12495 Initial commit of new design [nifi-site]
james-elliott commented on code in PR #78:
URL: https://github.com/apache/nifi-site/pull/78#discussion_r1430640707
##
content/download/_index.md:
##
@@ -0,0 +1,197 @@
+---
+title: "Download"
+---
+
+# Download
+
+Previous releases are available in [release
archives](https://archive.apache.org/dist/nifi/). Archive downloads are
+subject to rate limiting.
+
+OpenPGP [Project Keys](https://downloads.apache.org/nifi/KEYS) can be used for
+[download verification](https://www.apache.org/info/verification.html).
+
+## Apache NiFi {{< param currentProjectVersion >}}
+
+- Released: {{< param currentProjectVersionReleased >}}
+- https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version{{<
param currentProjectVersion >}}">Release Notes
+- [Migration
Guidance](https://cwiki.apache.org/confluence/display/NIFI/Migration+Guidance)
+
+
+
+Sources
+
+
+https://www.apache.org/dyn/closer.lua?path=/nifi/{{< param
currentProjectVersion >}}/nifi-{{< param currentProjectVersion
>}}-source-release.zip">
+ Download
+
+
+ nifi-{{< param
currentProjectVersion >}}-source-release.zip
+
+https://downloads.apache.org/nifi/{{< param
currentProjectVersion >}}/nifi-{{< param currentProjectVersion
>}}-source-release.zip.asc">
+ OpenPGP
+
+https://downloads.apache.org/nifi/{{< param
currentProjectVersion >}}/nifi-{{< param currentProjectVersion
>}}-source-release.zip.sha512">
+ SHA-512
+
+https://downloads.apache.org/nifi/{{< param
currentProjectVersion >}}/nifi-{{< param currentProjectVersion
>}}-source-release.zip.sha256">
+ SHA-256
+
+
+
+
+
+
+
+
+Standard
+
+
+https://www.apache.org/dyn/closer.lua?path=/nifi/{{< param
currentProjectVersion >}}/nifi-{{< param currentProjectVersion
>}}-source-release.zip">
+ Download
+
+
+ nifi-{{< param
currentProjectVersion >}}-bin.zip
+
+https://downloads.apache.org/nifi/{{< param
currentProjectVersion >}}/nifi-{{< param currentProjectVersion
>}}-source-release.zip.asc">
+ OpenPGP
+
+https://downloads.apache.org/nifi/{{< param
currentProjectVersion >}}/nifi-{{< param currentProjectVersion
>}}-source-release.zip.sha512">
+ SHA-512
+
+https://downloads.apache.org/nifi/{{< param
currentProjectVersion >}}/nifi-{{< param currentProjectVersion
>}}-source-release.zip.sha256">
+ SHA-256
+
+
+
+
+
+
+
+
+Stateless
+
+
+https://www.apache.org/dyn/closer.lua?path=/nifi/{{< param
currentProjectVersion >}}/nifi-{{< param currentProjectVersion
>}}-source-release.zip">
+ Download
+
+
+ nifi-stateless-{{< param
currentProjectVersion >}}-bin.zip
+
+https://downloads.apache.org/nifi/{{< param
currentProjectVersion >}}/nifi-{{< param currentProjectVersion
>}}-source-release.zip.asc">
+ OpenPGP
+
+https://downloads.apache.org/nifi/{{< param
currentProjectVersion >}}/nifi-{{< param currentProjectVersion
>}}-source-release.zip.sha512">
+ SHA-512
+
+https://downloads.apache.org/nifi/{{< param
currentProjectVersion >}}/nifi-{{< param currentProjectVersion
>}}-source-release.zip.sha256">
+ SHA-256
+
+
+
+
+
+
+
+
+Kafka Connector
+
+
+https://www.apache.org/dyn/closer.lua?path=/nifi/{{< param
currentProjectVersion >}}/nifi-{{< param currentProjectVersion
>}}-source-release.zip">
+ Download
+
+
+ nifi-kafka-connector-assembly-{{< param currentProjectVersion
>}}.zip
+
+https://downloads.apache.org/nifi/{{< param
currentProjectVersion >}}/nifi-{{< param currentProjectVersion
>}}-source-release.zip.asc">
+ OpenPGP
+
+https://downloads.apache.org/nifi/{{< param
currentProjectVersion >}}/nifi-{{< param currentProjectVersion
>}}-source-release.zip.sha512">
+ SHA-512
+
+https://downloads.apache.org/nifi/{{< param
currentProjectVersion >}}/nifi-{{< param currentProjectVersion
>}}-source-release.zip.sha256">
+ SHA-256
+
+
+
+
+
+
+
+
+Toolkit
+
+
+https://www.apache.org/dyn/closer.lua?path=/nifi/{{< param
currentProjectVersion >}}/nifi-{{< param currentProjectVersion
>}}-source-release.zip">
+ Download
+
+
+ nifi-toolkit-{{< param
currentProjectVersion >}}-bin.zip
+
+https://downloads.apache.org/nifi/{{< param
currentProjectVersion >}}/nifi-{{< param currentProjectVersion
>}}-source-release.zip.asc">
+ OpenPGP
+
+https://downloads.apache.org/nifi/{{< param
currentProjectVersion >}}/nifi-{{< param currentProjectVersion
>}}-source-release.zip.sha512">
+ SHA-512
+
+
[jira] [Comment Edited] (NIFI-12513) Regression in InvokeHTTP - Not a valid URL
[
https://issues.apache.org/jira/browse/NIFI-12513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798356#comment-17798356
]
Daniel Stieglitz edited comment on NIFI-12513 at 12/18/23 8:59 PM:
---
FYI I got this to work
{code:java}
String scheme = "https";
String userInfo = null;
String host = "en.wikipedia.org";
int port = -1;
String path = "/w/api.php";
String query =
"action=query=recentchanges=json=user|comment|parsedcomment|timestamp|title|sizes|tags";
String fragment = null;
URI uri = new URI(scheme, userInfo, host, port, path, query, fragment);
{code}
was (Author: JIRAUSER294662):
FYI I got this to work
{code:java}
String scheme = "https";
String userInfo = null;
String host = "en.wikipedia.org";
int port = -1;
String path = "/w/api.php";
String query =
"action=query=recentchanges=json=user|comment|parsedcomment|timestamp|title|sizes|tags";
String fragment = null;
URI uri = new URI(scheme, userInfo, host, port, path, query, fragment);
{code}
> Regression in InvokeHTTP - Not a valid URL
> --
>
> Key: NIFI-12513
> URL: https://issues.apache.org/jira/browse/NIFI-12513
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 2.0.0-M1, 1.24.0
>Reporter: Pierre Villard
>Assignee: Daniel Stieglitz
>Priority: Major
>
> On NiFi 1.24 and NiFi 2.0-M1, the below URL
> {code:java}
> https://en.wikipedia.org/w/api.php?action=query=recentchanges=json=user|comment|parsedcomment|timestamp|title|sizes|tags{code}
> Is no longer considered as valid but it was a valid one before.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] NIFI-12495 Initial commit of new design [nifi-site]
james-elliott commented on code in PR #78:
URL: https://github.com/apache/nifi-site/pull/78#discussion_r1430640093
##
content/download/_index.md:
##
@@ -0,0 +1,197 @@
+---
+title: "Download"
+---
+
+# Download
+
+Previous releases are available in [release
archives](https://archive.apache.org/dist/nifi/). Archive downloads are
+subject to rate limiting.
+
+OpenPGP [Project Keys](https://downloads.apache.org/nifi/KEYS) can be used for
+[download verification](https://www.apache.org/info/verification.html).
+
+## Apache NiFi {{< param currentProjectVersion >}}
+
+- Released: {{< param currentProjectVersionReleased >}}
+- https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version{{<
param currentProjectVersion >}}">Release Notes
+- [Migration
Guidance](https://cwiki.apache.org/confluence/display/NIFI/Migration+Guidance)
+
+
Review Comment:
Simplified this by converting nearly entirely to using markdown and the
existing link shortcodes.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (NIFI-12513) Regression in InvokeHTTP - Not a valid URL
[
https://issues.apache.org/jira/browse/NIFI-12513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798356#comment-17798356
]
Daniel Stieglitz commented on NIFI-12513:
-
FYI I got this to work
{code:java}
String scheme = "https";
String userInfo = null;
String host = "en.wikipedia.org";
int port = -1;
String path = "/w/api.php";
String query =
"action=query=recentchanges=json=user|comment|parsedcomment|timestamp|title|sizes|tags";
String fragment = null;
URI uri = new URI(scheme, userInfo, host, port, path, query, fragment);
{code}
> Regression in InvokeHTTP - Not a valid URL
> --
>
> Key: NIFI-12513
> URL: https://issues.apache.org/jira/browse/NIFI-12513
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 2.0.0-M1, 1.24.0
>Reporter: Pierre Villard
>Assignee: Daniel Stieglitz
>Priority: Major
>
> On NiFi 1.24 and NiFi 2.0-M1, the below URL
> {code:java}
> https://en.wikipedia.org/w/api.php?action=query=recentchanges=json=user|comment|parsedcomment|timestamp|title|sizes|tags{code}
> Is no longer considered as valid but it was a valid one before.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (NIFI-12513) Regression in InvokeHTTP - Not a valid URL
[
https://issues.apache.org/jira/browse/NIFI-12513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798343#comment-17798343
]
Daniel Stieglitz edited comment on NIFI-12513 at 12/18/23 8:37 PM:
---
[~pvillard] It would seem this issue is not specific to InvokeHttp but with the
StandardValidators.URL_VALIDATOR as the URL you listed fails when called with
{code:java}
URI.create(evaluatedInput).toURL();{code}
The same logic is called in InvokeHTTP but any PropertyDescriptor which uses
the StandardValidators.URL_VALIDATOR will fail to validate.
I found this [Stackoverflow
post|https://stackoverflow.com/questions/75966165/how-to-replace-the-deprecated-url-constructors-in-java-20]
helpful understanding that the issue is probably an encoding issue. I think
using this [URI constructor
|https://docs.oracle.com/javase/8/docs/api/java/net/URI.html#URI-java.lang.String-java.lang.String-java.lang.String-int-java.lang.String-java.lang.String-java.lang.String-]]would
help as it would identify which parts needs to be encoded (escaped). The issue
though is we would need to parse the user entered URL to identify its
components. I found the following [API|https://github.com/smola/galimatias]
(though its a little old) which can handle parsing the components and convert
it to a java.netURL / java.net.URI. Could we wrap the use of this API in a
utility method and then use it in StandardValidators.URL_VALIDATOR and all the
classes which require parsing a URL to a java.netURL / java.net.URI object?
was (Author: JIRAUSER294662):
[~pvillard] It would seem this issue is not specific to InvokeHttp but with the
StandardValidators.URL_VALIDATOR as the URL you listed fails when called with
{code:java}
URI.create(evaluatedInput).toURL();{code}
The same logic is called in InvokeHTTP but any PropertyDescriptor which uses
the StandardValidators.URL_VALIDATOR will fail to validate.
I found this [Stackoverflow
post|https://stackoverflow.com/questions/75966165/how-to-replace-the-deprecated-url-constructors-in-java-20]
helpful understanding that the issue is probably an encoding issue. I think
using this [[URI constructor
|https://docs.oracle.com/javase/8/docs/api/java/net/URI.html#URI-java.lang.String-java.lang.String-java.lang.String-int-java.lang.String-java.lang.String-java.lang.String-]]would
help as it would identify which parts needs to be encoded (escaped). The issue
though is we would need to parse the user entered URL to identify its
components. I found the following [API|https://github.com/smola/galimatias]
(though its a little old) which can handle parsing the components and convert
it to a java.netURL / java.net.URI. Could we wrap the use of this API in a
utility method and then use it in StandardValidators.URL_VALIDATOR and all the
classes which require parsing a URL to a java.netURL / java.net.URI object?
> Regression in InvokeHTTP - Not a valid URL
> --
>
> Key: NIFI-12513
> URL: https://issues.apache.org/jira/browse/NIFI-12513
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 2.0.0-M1, 1.24.0
>Reporter: Pierre Villard
>Assignee: Daniel Stieglitz
>Priority: Major
>
> On NiFi 1.24 and NiFi 2.0-M1, the below URL
> {code:java}
> https://en.wikipedia.org/w/api.php?action=query=recentchanges=json=user|comment|parsedcomment|timestamp|title|sizes|tags{code}
> Is no longer considered as valid but it was a valid one before.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (NIFI-12513) Regression in InvokeHTTP - Not a valid URL
[
https://issues.apache.org/jira/browse/NIFI-12513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798343#comment-17798343
]
Daniel Stieglitz edited comment on NIFI-12513 at 12/18/23 8:37 PM:
---
[~pvillard] It would seem this issue is not specific to InvokeHttp but with the
StandardValidators.URL_VALIDATOR as the URL you listed fails when called with
{code:java}
URI.create(evaluatedInput).toURL();{code}
The same logic is called in InvokeHTTP but any PropertyDescriptor which uses
the StandardValidators.URL_VALIDATOR will fail to validate.
I found this [Stackoverflow
post|https://stackoverflow.com/questions/75966165/how-to-replace-the-deprecated-url-constructors-in-java-20]
helpful understanding that the issue is probably an encoding issue. I think
using this [URI constructor
|https://docs.oracle.com/javase/8/docs/api/java/net/URI.html#URI-java.lang.String-java.lang.String-java.lang.String-int-java.lang.String-java.lang.String-java.lang.String-]would
help as it would identify which parts needs to be encoded (escaped). The issue
though is we would need to parse the user entered URL to identify its
components. I found the following [API|https://github.com/smola/galimatias]
(though its a little old) which can handle parsing the components and convert
it to a java.netURL / java.net.URI. Could we wrap the use of this API in a
utility method and then use it in StandardValidators.URL_VALIDATOR and all the
classes which require parsing a URL to a java.netURL / java.net.URI object?
was (Author: JIRAUSER294662):
[~pvillard] It would seem this issue is not specific to InvokeHttp but with the
StandardValidators.URL_VALIDATOR as the URL you listed fails when called with
{code:java}
URI.create(evaluatedInput).toURL();{code}
The same logic is called in InvokeHTTP but any PropertyDescriptor which uses
the StandardValidators.URL_VALIDATOR will fail to validate.
I found this [Stackoverflow
post|https://stackoverflow.com/questions/75966165/how-to-replace-the-deprecated-url-constructors-in-java-20]
helpful understanding that the issue is probably an encoding issue. I think
using this [URI constructor
|https://docs.oracle.com/javase/8/docs/api/java/net/URI.html#URI-java.lang.String-java.lang.String-java.lang.String-int-java.lang.String-java.lang.String-java.lang.String-]]would
help as it would identify which parts needs to be encoded (escaped). The issue
though is we would need to parse the user entered URL to identify its
components. I found the following [API|https://github.com/smola/galimatias]
(though its a little old) which can handle parsing the components and convert
it to a java.netURL / java.net.URI. Could we wrap the use of this API in a
utility method and then use it in StandardValidators.URL_VALIDATOR and all the
classes which require parsing a URL to a java.netURL / java.net.URI object?
> Regression in InvokeHTTP - Not a valid URL
> --
>
> Key: NIFI-12513
> URL: https://issues.apache.org/jira/browse/NIFI-12513
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 2.0.0-M1, 1.24.0
>Reporter: Pierre Villard
>Assignee: Daniel Stieglitz
>Priority: Major
>
> On NiFi 1.24 and NiFi 2.0-M1, the below URL
> {code:java}
> https://en.wikipedia.org/w/api.php?action=query=recentchanges=json=user|comment|parsedcomment|timestamp|title|sizes|tags{code}
> Is no longer considered as valid but it was a valid one before.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (NIFI-12513) Regression in InvokeHTTP - Not a valid URL
[
https://issues.apache.org/jira/browse/NIFI-12513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798343#comment-17798343
]
Daniel Stieglitz edited comment on NIFI-12513 at 12/18/23 8:36 PM:
---
[~pvillard] It would seem this issue is not specific to InvokeHttp but with the
StandardValidators.URL_VALIDATOR as the URL you listed fails when called with
{code:java}
URI.create(evaluatedInput).toURL();{code}
The same logic is called in InvokeHTTP but any PropertyDescriptor which uses
the StandardValidators.URL_VALIDATOR will fail to validate.
I found this [Stackoverflow
post|https://stackoverflow.com/questions/75966165/how-to-replace-the-deprecated-url-constructors-in-java-20]
helpful understanding that the issue is probably an encoding issue. I think
using this [[URI constructor
|https://docs.oracle.com/javase/8/docs/api/java/net/URI.html#URI-java.lang.String-java.lang.String-java.lang.String-int-java.lang.String-java.lang.String-java.lang.String-]]would
help as it would identify which parts needs to be encoded (escaped). The issue
though is we would need to parse the user entered URL to identify its
components. I found the following [API|https://github.com/smola/galimatias]
(though its a little old) which can handle parsing the components and convert
it to a java.netURL / java.net.URI. Could we wrap the use of this API in a
utility method and then use it in StandardValidators.URL_VALIDATOR and all the
classes which require parsing a URL to a java.netURL / java.net.URI object?
was (Author: JIRAUSER294662):
[~pvillard] It would seem this issue is not specific to InvokeHttp but with the
StandardValidators.URL_VALIDATOR as the URL you listed fails when called with
{code:java}
URI.create(evaluatedInput).toURL();{code}
The same logic is called in InvokeHTTP but any PropertyDescriptor which uses
the StandardValidators.URL_VALIDATOR will fail to validate.
I found this [Stackoverflow
post|https://stackoverflow.com/questions/75966165/how-to-replace-the-deprecated-url-constructors-in-java-20]
helpful understanding that the issue is probably an encoding issue. I think
using this [[URI
constructor|https://docs.oracle.com/javase/8/docs/api/java/net/URI.html#URI-java.lang.String-java.lang.String-java.lang.String-int-java.lang.String-java.lang.String-java.lang.String-]
|https://docs.oracle.com/javase/8/docs/api/java/net/URI.html#URI-java.lang.String-java.lang.String-java.lang.String-java.lang.String-java.lang.String-]would
help as it would identify which parts needs to be encoded (escaped). The issue
though is we would need to parse the user entered URL to identify its
components. I found the following [API|https://github.com/smola/galimatias]
(though its a little old) which can handle parsing the components and convert
it to a java.netURL / java.net.URI. Could we wrap the use of this API in a
utility method and then use it in StandardValidators.URL_VALIDATOR and all the
classes which require parsing a URL to a java.netURL / java.net.URI object?
> Regression in InvokeHTTP - Not a valid URL
> --
>
> Key: NIFI-12513
> URL: https://issues.apache.org/jira/browse/NIFI-12513
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 2.0.0-M1, 1.24.0
>Reporter: Pierre Villard
>Assignee: Daniel Stieglitz
>Priority: Major
>
> On NiFi 1.24 and NiFi 2.0-M1, the below URL
> {code:java}
> https://en.wikipedia.org/w/api.php?action=query=recentchanges=json=user|comment|parsedcomment|timestamp|title|sizes|tags{code}
> Is no longer considered as valid but it was a valid one before.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (NIFI-12513) Regression in InvokeHTTP - Not a valid URL
[
https://issues.apache.org/jira/browse/NIFI-12513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798343#comment-17798343
]
Daniel Stieglitz edited comment on NIFI-12513 at 12/18/23 8:35 PM:
---
[~pvillard] It would seem this issue is not specific to InvokeHttp but with the
StandardValidators.URL_VALIDATOR as the URL you listed fails when called with
{code:java}
URI.create(evaluatedInput).toURL();{code}
The same logic is called in InvokeHTTP but any PropertyDescriptor which uses
the StandardValidators.URL_VALIDATOR will fail to validate.
I found this [Stackoverflow
post|https://stackoverflow.com/questions/75966165/how-to-replace-the-deprecated-url-constructors-in-java-20]
helpful understanding that the issue is probably an encoding issue. I think
using this [[URI
constructor|https://docs.oracle.com/javase/8/docs/api/java/net/URI.html#URI-java.lang.String-java.lang.String-java.lang.String-int-java.lang.String-java.lang.String-java.lang.String-]
|https://docs.oracle.com/javase/8/docs/api/java/net/URI.html#URI-java.lang.String-java.lang.String-java.lang.String-java.lang.String-java.lang.String-]would
help as it would identify which parts needs to be encoded (escaped). The issue
though is we would need to parse the user entered URL to identify its
components. I found the following [API|https://github.com/smola/galimatias]
(though its a little old) which can handle parsing the components and convert
it to a java.netURL / java.net.URI. Could we wrap the use of this API in a
utility method and then use it in StandardValidators.URL_VALIDATOR and all the
classes which require parsing a URL to a java.netURL / java.net.URI object?
was (Author: JIRAUSER294662):
[~pvillard] It would seem this issue is not specific to InvokeHttp but with the
StandardValidators.URL_VALIDATOR as the URL you listed fails when called with
{code:java}
URI.create(evaluatedInput).toURL();{code}
The same logic is called in InvokeHTTP but any PropertyDescriptor which uses
the StandardValidators.URL_VALIDATOR will fail to validate.
I found this [Stackoverflow
post|https://stackoverflow.com/questions/75966165/how-to-replace-the-deprecated-url-constructors-in-java-20]
helpful understanding that the issue is probably an encoding issue. I think
using this [URI constructor
|https://docs.oracle.com/javase/8/docs/api/java/net/URI.html#URI-java.lang.String-java.lang.String-java.lang.String-java.lang.String-java.lang.String-]would
help as it would identify which parts needs to be encoded (escaped). The issue
though is we would need to parse the user entered URL to identify its
components. I found the following [API|https://github.com/smola/galimatias]
(though its a little old) which can handle parsing the components and convert
it to a java.netURL / java.net.URI. Could we wrap the use of this API in a
utility method and then use it in StandardValidators.URL_VALIDATOR and all the
classes which require parsing a URL to a java.netURL / java.net.URI object?
> Regression in InvokeHTTP - Not a valid URL
> --
>
> Key: NIFI-12513
> URL: https://issues.apache.org/jira/browse/NIFI-12513
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 2.0.0-M1, 1.24.0
>Reporter: Pierre Villard
>Assignee: Daniel Stieglitz
>Priority: Major
>
> On NiFi 1.24 and NiFi 2.0-M1, the below URL
> {code:java}
> https://en.wikipedia.org/w/api.php?action=query=recentchanges=json=user|comment|parsedcomment|timestamp|title|sizes|tags{code}
> Is no longer considered as valid but it was a valid one before.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-12513) Regression in InvokeHTTP - Not a valid URL
[
https://issues.apache.org/jira/browse/NIFI-12513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798349#comment-17798349
]
David Handermann commented on NIFI-12513:
-
One thing to note, it is important to avoid introducing any new external
dependencies to the {{nifi-utils}} package, which currently contains the
StandardValidators class. Many components use {{nifi-utils}}, so introducing
new dependencies would have a large downstream impact. This might be a case
where the new behavior should be documented without making changes.
> Regression in InvokeHTTP - Not a valid URL
> --
>
> Key: NIFI-12513
> URL: https://issues.apache.org/jira/browse/NIFI-12513
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 2.0.0-M1, 1.24.0
>Reporter: Pierre Villard
>Assignee: Daniel Stieglitz
>Priority: Major
>
> On NiFi 1.24 and NiFi 2.0-M1, the below URL
> {code:java}
> https://en.wikipedia.org/w/api.php?action=query=recentchanges=json=user|comment|parsedcomment|timestamp|title|sizes|tags{code}
> Is no longer considered as valid but it was a valid one before.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (NIFI-12513) Regression in InvokeHTTP - Not a valid URL
[
https://issues.apache.org/jira/browse/NIFI-12513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798343#comment-17798343
]
Daniel Stieglitz edited comment on NIFI-12513 at 12/18/23 8:22 PM:
---
[~pvillard] It would seem this issue is not specific to InvokeHttp but with the
StandardValidators.URL_VALIDATOR as the URL you listed fails when called with
{code:java}
URI.create(evaluatedInput).toURL();{code}
The same logic is called in InvokeHTTP but any PropertyDescriptor which uses
the StandardValidators.URL_VALIDATOR will fail to validate.
I found this [Stackoverflow
post|https://stackoverflow.com/questions/75966165/how-to-replace-the-deprecated-url-constructors-in-java-20]
helpful understanding that the issue is probably an encoding issue. I think
using this [URI constructor
|https://docs.oracle.com/javase/8/docs/api/java/net/URI.html#URI-java.lang.String-java.lang.String-java.lang.String-java.lang.String-java.lang.String-]would
help as it would identify which parts needs to be encoded (escaped). The issue
though is we would need to parse the user entered URL to identify its
components. I found the following [API|https://github.com/smola/galimatias]
(though its a little old) which can handle parsing the components and convert
it to a java.netURL / java.net.URI. Could we wrap the use of this API in a
utility method and then use it in StandardValidators.URL_VALIDATOR and all the
classes which require parsing a URL to a java.netURL / java.net.URI object?
was (Author: JIRAUSER294662):
[~pvillard] It would seem this issue is not specific to InvokeHttp but with the
StandardValidators.URL_VALIDATOR as the URL you listed fails when called with
{code:java}
URI.create(evaluatedInput).toURL();{code}
The same logic is called in InvokeHTTP but any PropertyDescriptor which uses
the StandardValidators.URL_VALIDATOR will fail to validate.
I found this [Stackoverflow
post|https://stackoverflow.com/questions/75966165/how-to-replace-the-deprecated-url-constructors-in-java-20]
helpful understanding that the issue is probably an encoding issue. I think
using this [URI constructor
|https://docs.oracle.com/javase/8/docs/api/java/net/URI.html#URI-java.lang.String-java.lang.String-java.lang.String-java.lang.String-java.lang.String-]would
help as it would identify which parts needs to be encoded (escaped). The issue
though is we would need to parse the user entered URL to identify its
components. I found the following [API|https://github.com/smola/galimatias]
(though its a little old) which can handle parsing the components and convert
it to a java.netURL / java.net.URI. Could we wrap the use of this API in a
utility method and then use it in StandardValidators.URL_VALIDATOR and all the
classes which require parsing a URL to a java.netURL / java.net.URI object.
> Regression in InvokeHTTP - Not a valid URL
> --
>
> Key: NIFI-12513
> URL: https://issues.apache.org/jira/browse/NIFI-12513
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 2.0.0-M1, 1.24.0
>Reporter: Pierre Villard
>Assignee: Daniel Stieglitz
>Priority: Major
>
> On NiFi 1.24 and NiFi 2.0-M1, the below URL
> {code:java}
> https://en.wikipedia.org/w/api.php?action=query=recentchanges=json=user|comment|parsedcomment|timestamp|title|sizes|tags{code}
> Is no longer considered as valid but it was a valid one before.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (NIFI-12513) Regression in InvokeHTTP - Not a valid URL
[
https://issues.apache.org/jira/browse/NIFI-12513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798343#comment-17798343
]
Daniel Stieglitz edited comment on NIFI-12513 at 12/18/23 8:20 PM:
---
[~pvillard] It would seem this issue is not specific to InvokeHttp but with the
StandardValidators.URL_VALIDATOR as the URL you listed fails when called with
{code:java}
URI.create(evaluatedInput).toURL();{code}
The same logic is called in InvokeHTTP but any PropertyDescriptor which uses
the StandardValidators.URL_VALIDATOR will fail to validate.
I found this [Stackoverflow
post|https://stackoverflow.com/questions/75966165/how-to-replace-the-deprecated-url-constructors-in-java-20]
helpful understanding that the issue is probably an encoding issue. I think
using this [URI constructor
|https://docs.oracle.com/javase/8/docs/api/java/net/URI.html#URI-java.lang.String-java.lang.String-java.lang.String-java.lang.String-java.lang.String-]would
help as it would identify which parts needs to be encoded (escaped). The issue
though is we would need to parse the user entered URL to identify its
components. I found the following [API|https://github.com/smola/galimatias]
(though its a little old) which can handle parsing the components and convert
it to a java.netURL / java.net.URI. Could we wrap the use of this API in a
utility method and then use it in StandardValidators.URL_VALIDATOR and all the
classes which require parsing a URL to a java.netURL / java.net.URI object.
was (Author: JIRAUSER294662):
[~pvillard] It would seem this issue is not specific to InvokeHttp but with the
StandardValidators.URL_VALIDATOR as the URL you listed fails when called with
{code:java}
URI.create(evaluatedInput).toURL();{code}
The same logic is called in InvokeHTTP but any PropertyDescriptor which uses
the StandardValidators.URL_VALIDATOR will fail to validate.
I found this [Stackoverflow
post|https://stackoverflow.com/questions/75966165/how-to-replace-the-deprecated-url-constructors-in-java-20]
helpful understanding that the issue is probably an encoding issue. I think
using this [URI constructor
|https://docs.oracle.com/javase/8/docs/api/java/net/URI.html#URI-java.lang.String-java.lang.String-java.lang.String-java.lang.String-java.lang.String-]would
help as it would identify which parts needs to be encoded (escaped). The issue
though is we would need to parse the user entered URL to identify its
components. I found the following [API|https://github.com/smola/galimatias]
(though its a little old) which can handle parsing the components and convert
it to a java.netURL / java.net.URI
> Regression in InvokeHTTP - Not a valid URL
> --
>
> Key: NIFI-12513
> URL: https://issues.apache.org/jira/browse/NIFI-12513
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 2.0.0-M1, 1.24.0
>Reporter: Pierre Villard
>Assignee: Daniel Stieglitz
>Priority: Major
>
> On NiFi 1.24 and NiFi 2.0-M1, the below URL
> {code:java}
> https://en.wikipedia.org/w/api.php?action=query=recentchanges=json=user|comment|parsedcomment|timestamp|title|sizes|tags{code}
> Is no longer considered as valid but it was a valid one before.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (NIFI-12513) Regression in InvokeHTTP - Not a valid URL
[
https://issues.apache.org/jira/browse/NIFI-12513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798343#comment-17798343
]
Daniel Stieglitz edited comment on NIFI-12513 at 12/18/23 8:18 PM:
---
[~pvillard] It would seem this issue is not specific to InvokeHttp but with the
StandardValidators.URL_VALIDATOR as the URL you listed fails when called with
{code:java}
URI.create(evaluatedInput).toURL();{code}
The same logic is called in InvokeHTTP but any PropertyDescriptor which uses
the StandardValidators.URL_VALIDATOR will fail to validate.
I found this [Stackoverflow
post|https://stackoverflow.com/questions/75966165/how-to-replace-the-deprecated-url-constructors-in-java-20]
helpful understanding that the issue is probably an encoding issue. I think
using this [URI constructor
|https://docs.oracle.com/javase/8/docs/api/java/net/URI.html#URI-java.lang.String-java.lang.String-java.lang.String-java.lang.String-java.lang.String-]would
help as it would identify which parts needs to be encoded (escaped). The issue
though is we would need to parse the user entered URL to identify its
components. I found the following [API|https://github.com/smola/galimatias]
(though its a little old) which can handle parsing the components and convert
it to a java.netURL / java.net.URI
was (Author: JIRAUSER294662):
[~pvillard] It would seem this issue is not specific to InvokeHttp but with the
StandardValidators.URL_VALIDATOR as the URL you listed fails when called with
{code:java}
URI.create(evaluatedInput).toURL();{code}
The same logic is called in InvokeHTTP but any PropertyDescriptor which uses
the StandardValidators.URL_VALIDATOR will fail to validate.
I found this [Stackoverflow
post|https://stackoverflow.com/questions/75966165/how-to-replace-the-deprecated-url-constructors-in-java-20]
helpful understanding that the issue is probably an encoding issue. I think
using this [URI constructor
|https://docs.oracle.com/javase/8/docs/api/java/net/URI.html#URI-java.lang.String-java.lang.String-java.lang.String-java.lang.String-java.lang.String-]would
help as it would identify which parts needs to be encoded (escaped). The issue
though is we would need to parse the user entered URL to identify its
components. I found the following [API|https://github.com/smola/galimatias]
(though its a little old) it can handle parsing the components and convert it
to a java.netURL / java.net.URI
> Regression in InvokeHTTP - Not a valid URL
> --
>
> Key: NIFI-12513
> URL: https://issues.apache.org/jira/browse/NIFI-12513
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 2.0.0-M1, 1.24.0
>Reporter: Pierre Villard
>Assignee: Daniel Stieglitz
>Priority: Major
>
> On NiFi 1.24 and NiFi 2.0-M1, the below URL
> {code:java}
> https://en.wikipedia.org/w/api.php?action=query=recentchanges=json=user|comment|parsedcomment|timestamp|title|sizes|tags{code}
> Is no longer considered as valid but it was a valid one before.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (NIFI-12513) Regression in InvokeHTTP - Not a valid URL
[
https://issues.apache.org/jira/browse/NIFI-12513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798343#comment-17798343
]
Daniel Stieglitz edited comment on NIFI-12513 at 12/18/23 8:17 PM:
---
[~pvillard] It would seem this issue is not specific to InvokeHttp but with the
StandardValidators.URL_VALIDATOR as the URL you listed fails when called with
{code:java}
URI.create(evaluatedInput).toURL();{code}
The same logic is called in InvokeHTTP but any PropertyDescriptor which uses
the StandardValidators.URL_VALIDATOR will fail to validate.
I found this [Stackoverflow
post|https://stackoverflow.com/questions/75966165/how-to-replace-the-deprecated-url-constructors-in-java-20]
helpful understanding that the issue is probably an encoding issue. I think
using this [URI constructor
|https://docs.oracle.com/javase/8/docs/api/java/net/URI.html#URI-java.lang.String-java.lang.String-java.lang.String-java.lang.String-java.lang.String-]would
help as it would identify which parts needs to be encoded (escaped). The issue
though is we would need to parse the user entered URL to identify its
components. I found the following [API|https://github.com/smola/galimatias]
(though its a little old) it can handle parsing the components and convert it
to a java.netURL / java.net.URI
was (Author: JIRAUSER294662):
[~pvillard] It would seem this issue is not specific to InvokeHttp but with the
StandardValidators.URL_VALIDATOR as the URL you listed fails when called with
{code:java}
URI.create(evaluatedInput).toURL();{code}
The same logic is called in InvokeHTTP but any PropertyDescriptor which uses
the StandardValidators.URL_VALIDATOR will fail to validate.
I found this [Stackoverflow
post|https://stackoverflow.com/questions/75966165/how-to-replace-the-deprecated-url-constructors-in-java-20]
helpful understanding that the issue is probably an encoding issue. I think
using this [URI constructor
|https://docs.oracle.com/javase/8/docs/api/java/net/URI.html#URI-java.lang.String-java.lang.String-java.lang.String-java.lang.String-java.lang.String-]would
help as it would identify which parts needs to be encoded (escaped). The issue
though is we would need code to parse the entered URL to identify its
components. I found the following [API|https://github.com/smola/galimatias]
(though its a little old) it can handle parsing the components and convert it
to a java.netURL / java.net.URI
> Regression in InvokeHTTP - Not a valid URL
> --
>
> Key: NIFI-12513
> URL: https://issues.apache.org/jira/browse/NIFI-12513
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 2.0.0-M1, 1.24.0
>Reporter: Pierre Villard
>Assignee: Daniel Stieglitz
>Priority: Major
>
> On NiFi 1.24 and NiFi 2.0-M1, the below URL
> {code:java}
> https://en.wikipedia.org/w/api.php?action=query=recentchanges=json=user|comment|parsedcomment|timestamp|title|sizes|tags{code}
> Is no longer considered as valid but it was a valid one before.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (NIFI-12513) Regression in InvokeHTTP - Not a valid URL
[
https://issues.apache.org/jira/browse/NIFI-12513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798343#comment-17798343
]
Daniel Stieglitz edited comment on NIFI-12513 at 12/18/23 8:16 PM:
---
[~pvillard] It would seem this issue is not specific to InvokeHttp but with the
StandardValidators.URL_VALIDATOR as the URL you listed fails when called with
{code:java}
URI.create(evaluatedInput).toURL();{code}
The same logic is called in InvokeHTTP but any PropertyDescriptor which uses
the StandardValidators.URL_VALIDATOR will fail to validate.
I found this [Stackoverflow
post|https://stackoverflow.com/questions/75966165/how-to-replace-the-deprecated-url-constructors-in-java-20]
helpful understanding that the issue is probably an encoding issue. I think
using this [URI constructor
|https://docs.oracle.com/javase/8/docs/api/java/net/URI.html#URI-java.lang.String-java.lang.String-java.lang.String-java.lang.String-java.lang.String-]would
help as it would identify which parts needs to be encoded (escaped). The issue
though is we would need code to parse the entered URL to identify its
components. I found the following [API|https://github.com/smola/galimatias]
(though its a little old) it can handle parsing the components and convert it
to a java.netURL / java.net.URI
was (Author: JIRAUSER294662):
[~pvillard] It would seem this issue is not specific to InvokeHttp but with the
StandardValidators.URL_VALIDATOR as the [link title|http://example.com]URL you
listed fails when called with
{code:java}
URI.create(evaluatedInput).toURL();{code}
The same logic is called in InvokeHTTP but any PropertyDescriptor which uses
the StandardValidators.URL_VALIDATOR will fail to validate.
I found this [Stackoverflow
post|https://stackoverflow.com/questions/75966165/how-to-replace-the-deprecated-url-constructors-in-java-20]
helpful understanding that the issue is probably an encoding issue. I think
using this [URI constructor
|https://docs.oracle.com/javase/8/docs/api/java/net/URI.html#URI-java.lang.String-java.lang.String-java.lang.String-java.lang.String-java.lang.String-]would
help as it would identify which parts needs to be encoded (escaped). The issue
though is we would need code to parse the entered URL to identify its
components. I found the following [API|https://github.com/smola/galimatias]
(though its a little old) it can handle parsing the components and convert it
to a java.netURL / java.net.URI
> Regression in InvokeHTTP - Not a valid URL
> --
>
> Key: NIFI-12513
> URL: https://issues.apache.org/jira/browse/NIFI-12513
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 2.0.0-M1, 1.24.0
>Reporter: Pierre Villard
>Assignee: Daniel Stieglitz
>Priority: Major
>
> On NiFi 1.24 and NiFi 2.0-M1, the below URL
> {code:java}
> https://en.wikipedia.org/w/api.php?action=query=recentchanges=json=user|comment|parsedcomment|timestamp|title|sizes|tags{code}
> Is no longer considered as valid but it was a valid one before.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (NIFI-12513) Regression in InvokeHTTP - Not a valid URL
[
https://issues.apache.org/jira/browse/NIFI-12513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798343#comment-17798343
]
Daniel Stieglitz edited comment on NIFI-12513 at 12/18/23 8:15 PM:
---
[~pvillard] It would seem this issue is not specific to InvokeHttp but with the
StandardValidators.URL_VALIDATOR as the [link title|http://example.com]URL you
listed fails when called with
{code:java}
URI.create(evaluatedInput).toURL();{code}
The same logic is called in InvokeHTTP but any PropertyDescriptor which uses
the StandardValidators.URL_VALIDATOR will fail to validate.
I found this [Stackoverflow
post|https://stackoverflow.com/questions/75966165/how-to-replace-the-deprecated-url-constructors-in-java-20]
helpful understanding that the issue is probably an encoding issue. I think
using this [URI constructor
|https://docs.oracle.com/javase/8/docs/api/java/net/URI.html#URI-java.lang.String-java.lang.String-java.lang.String-java.lang.String-java.lang.String-]would
help as it would identify which parts needs to be encoded (escaped). The issue
though is we would need code to parse the entered URL to identify its
components. I found the following [API|https://github.com/smola/galimatias]
(though its a little old) it can handle parsing the components and convert it
to a java.netURL / java.net.URI
was (Author: JIRAUSER294662):
[~pvillard] It would seem this issue is not specific to InvokeHttp but with the
StandardValidators.URL_VALIDATOR as the URL you listed fails when called with
{code:java}
URI.create(evaluatedInput).toURL();{code}
The same logic is called in InvokeHTTP but any PropertyDescriptor which uses
the StandardValidators.URL_VALIDATOR will fail to validate.
> Regression in InvokeHTTP - Not a valid URL
> --
>
> Key: NIFI-12513
> URL: https://issues.apache.org/jira/browse/NIFI-12513
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 2.0.0-M1, 1.24.0
>Reporter: Pierre Villard
>Assignee: Daniel Stieglitz
>Priority: Major
>
> On NiFi 1.24 and NiFi 2.0-M1, the below URL
> {code:java}
> https://en.wikipedia.org/w/api.php?action=query=recentchanges=json=user|comment|parsedcomment|timestamp|title|sizes|tags{code}
> Is no longer considered as valid but it was a valid one before.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-12487) Add CSRF Filter to Registry Configuration
[ https://issues.apache.org/jira/browse/NIFI-12487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Bende updated NIFI-12487: --- Fix Version/s: 2.0.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Add CSRF Filter to Registry Configuration > - > > Key: NIFI-12487 > URL: https://issues.apache.org/jira/browse/NIFI-12487 > Project: Apache NiFi > Issue Type: Improvement > Components: NiFi Registry, Security >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 2.0.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > NiFi Registry supports several authentication strategies including username > and password, X.509 certificates, and OpenID Connect. Strategies that involve > exchanging temporary credentials produce an Application Bearer Token, which > the Registry interface stores and sends on subsequent requests for the > duration of the session. The Registry interface passes the Bearer Token using > the standard HTTP Authorization header, which requires custom JavaScript > request processing. This approach mitigates general concerns related to > Cross-Site Request Forgery as external requests from a web browser cannot > send the Authorization header. > Despite general protection based on the current implementation, adding > standard Cross-Site Request Forgery checking using Spring Security would > provide additional defenses. Enabling CSRF protection also aligns with > existing capabilities in NiFi, and would provide a basis for future align of > Bearer Token handling strategies. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-12487) Add CSRF Filter to Registry Configuration
[ https://issues.apache.org/jira/browse/NIFI-12487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798346#comment-17798346 ] ASF subversion and git services commented on NIFI-12487: Commit 27941936089ce6ef85ac1ba3a1bb0da536965e53 in nifi's branch refs/heads/main from David Handermann [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=2794193608 ] NIFI-12487 Added CSRF Protection to Registry (#8136) - Added CSRF Token Repository based on existing implementation - Updated Angular Request Interceptor to read cookie and send Request-Token Header > Add CSRF Filter to Registry Configuration > - > > Key: NIFI-12487 > URL: https://issues.apache.org/jira/browse/NIFI-12487 > Project: Apache NiFi > Issue Type: Improvement > Components: NiFi Registry, Security >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > NiFi Registry supports several authentication strategies including username > and password, X.509 certificates, and OpenID Connect. Strategies that involve > exchanging temporary credentials produce an Application Bearer Token, which > the Registry interface stores and sends on subsequent requests for the > duration of the session. The Registry interface passes the Bearer Token using > the standard HTTP Authorization header, which requires custom JavaScript > request processing. This approach mitigates general concerns related to > Cross-Site Request Forgery as external requests from a web browser cannot > send the Authorization header. > Despite general protection based on the current implementation, adding > standard Cross-Site Request Forgery checking using Spring Security would > provide additional defenses. Enabling CSRF protection also aligns with > existing capabilities in NiFi, and would provide a basis for future align of > Bearer Token handling strategies. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] NIFI-12487 Add CSRF Protection to Registry [nifi]
bbende merged PR #8136: URL: https://github.com/apache/nifi/pull/8136 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (NIFI-12513) Regression in InvokeHTTP - Not a valid URL
[
https://issues.apache.org/jira/browse/NIFI-12513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798343#comment-17798343
]
Daniel Stieglitz edited comment on NIFI-12513 at 12/18/23 8:00 PM:
---
[~pvillard] It would seem this issue is not specific to InvokeHttp but with the
StandardValidators.URL_VALIDATOR as the URL you listed fails when called with
{code:java}
URI.create(evaluatedInput).toURL();{code}
The same logic is called in InvokeHTTP but any PropertyDescriptor which uses
the StandardValidators.URL_VALIDATOR will fail to validate.
was (Author: JIRAUSER294662):
[~pvillard] It would seem this issue is not specific to InvokeHttp but with the
StandardValidators.URL_VALIDATOR as the URL you listed fails when called with
{code:java}
URI.create(evaluatedInput).toURL();{code}
The same logic is called in InvokeHTTP but anything PropertyDescriptor which
uses the StandardValidators.URL_VALIDATOR will fail to validate.
> Regression in InvokeHTTP - Not a valid URL
> --
>
> Key: NIFI-12513
> URL: https://issues.apache.org/jira/browse/NIFI-12513
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 2.0.0-M1, 1.24.0
>Reporter: Pierre Villard
>Assignee: Daniel Stieglitz
>Priority: Major
>
> On NiFi 1.24 and NiFi 2.0-M1, the below URL
> {code:java}
> https://en.wikipedia.org/w/api.php?action=query=recentchanges=json=user|comment|parsedcomment|timestamp|title|sizes|tags{code}
> Is no longer considered as valid but it was a valid one before.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-12513) Regression in InvokeHTTP - Not a valid URL
[
https://issues.apache.org/jira/browse/NIFI-12513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798343#comment-17798343
]
Daniel Stieglitz commented on NIFI-12513:
-
[~pvillard] It would seem this issue is not specific to InvokeHttp but with the
StandardValidators.URL_VALIDATOR as the URL you listed fails when called with
{code:java}
URI.create(evaluatedInput).toURL();{code}
The same logic is called in InvokeHTTP but anything PropertyDescriptor which
uses the StandardValidators.URL_VALIDATOR will fail to validate.
> Regression in InvokeHTTP - Not a valid URL
> --
>
> Key: NIFI-12513
> URL: https://issues.apache.org/jira/browse/NIFI-12513
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 2.0.0-M1, 1.24.0
>Reporter: Pierre Villard
>Assignee: Daniel Stieglitz
>Priority: Major
>
> On NiFi 1.24 and NiFi 2.0-M1, the below URL
> {code:java}
> https://en.wikipedia.org/w/api.php?action=query=recentchanges=json=user|comment|parsedcomment|timestamp|title|sizes|tags{code}
> Is no longer considered as valid but it was a valid one before.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-12502) Processor Properties - Go To Parameter and Convert To Parameter
[ https://issues.apache.org/jira/browse/NIFI-12502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Fellows updated NIFI-12502: --- Fix Version/s: 2.0.0 > Processor Properties - Go To Parameter and Convert To Parameter > --- > > Key: NIFI-12502 > URL: https://issues.apache.org/jira/browse/NIFI-12502 > Project: Apache NiFi > Issue Type: Sub-task > Components: Core UI >Reporter: Matt Gilman >Assignee: Matt Gilman >Priority: Major > Fix For: 2.0.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Update Processor Property configuration to support linking to a Parameter and > converting to a Parameter. Included in this is saving the component prior to > navigation if changes have been made. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] NIFI-12502: Handle additional Property Table capabilities [nifi]
rfellows merged PR #8159: URL: https://github.com/apache/nifi/pull/8159 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (NIFI-12502) Processor Properties - Go To Parameter and Convert To Parameter
[ https://issues.apache.org/jira/browse/NIFI-12502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798326#comment-17798326 ] ASF subversion and git services commented on NIFI-12502: Commit 49bbc38b6bd72ce96d4472792ed83bede69d45bf in nifi's branch refs/heads/main from Matt Gilman [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=49bbc38b6b ] NIFI-12502: Handle additional Property Table capabilities (#8159) * NIFI-12502: - Go To Service. - Save before navigating if form dirty. - Go To Parameter. - Convert To Parameter. * NIFI-12502: - Ensuring tests are still bootstrapped correctly. * NIFI-12502: - Addressing review feedback. This closes #8159 > Processor Properties - Go To Parameter and Convert To Parameter > --- > > Key: NIFI-12502 > URL: https://issues.apache.org/jira/browse/NIFI-12502 > Project: Apache NiFi > Issue Type: Sub-task > Components: Core UI >Reporter: Matt Gilman >Assignee: Matt Gilman >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > Update Processor Property configuration to support linking to a Parameter and > converting to a Parameter. Included in this is saving the component prior to > navigation if changes have been made. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12502) Processor Properties - Go To Parameter and Convert To Parameter
[ https://issues.apache.org/jira/browse/NIFI-12502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Fellows updated NIFI-12502: --- Resolution: Fixed Status: Resolved (was: Patch Available) > Processor Properties - Go To Parameter and Convert To Parameter > --- > > Key: NIFI-12502 > URL: https://issues.apache.org/jira/browse/NIFI-12502 > Project: Apache NiFi > Issue Type: Sub-task > Components: Core UI >Reporter: Matt Gilman >Assignee: Matt Gilman >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > Update Processor Property configuration to support linking to a Parameter and > converting to a Parameter. Included in this is saving the component prior to > navigation if changes have been made. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (NIFI-12513) Regression in InvokeHTTP - Not a valid URL
[
https://issues.apache.org/jira/browse/NIFI-12513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Stieglitz reassigned NIFI-12513:
---
Assignee: Daniel Stieglitz
> Regression in InvokeHTTP - Not a valid URL
> --
>
> Key: NIFI-12513
> URL: https://issues.apache.org/jira/browse/NIFI-12513
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 2.0.0-M1, 1.24.0
>Reporter: Pierre Villard
>Assignee: Daniel Stieglitz
>Priority: Major
>
> On NiFi 1.24 and NiFi 2.0-M1, the below URL
> {code:java}
> https://en.wikipedia.org/w/api.php?action=query=recentchanges=json=user|comment|parsedcomment|timestamp|title|sizes|tags{code}
> Is no longer considered as valid but it was a valid one before.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-12418) Identity Provider Groups Missing in Refreshed Bearer Token
[ https://issues.apache.org/jira/browse/NIFI-12418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Bende updated NIFI-12418: --- Fix Version/s: 1.25.0 2.0.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Identity Provider Groups Missing in Refreshed Bearer Token > -- > > Key: NIFI-12418 > URL: https://issues.apache.org/jira/browse/NIFI-12418 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework, Security >Affects Versions: 2.0.0-M1, 1.24.0 >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: backport-needed > Fix For: 1.25.0, 2.0.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The OIDC Bearer Token Refresh Filter is responsible for renewing application > Bearer Tokens when NiFi is integrated with an OpenID Connect Identity > Provider that supports the Refresh Token Grant Type. > NiFi 1.23.0 introduced changes for handling group membership information > supplied from an Identity Provider, passing the groups in the application > Bearer Token instead of persisting the groups in the local database > repository. > As a result of these handling changes, the Identity Provider group membership > information is not retained when the OIDC Bearer Token Refresh Filter > generates a new token. In deployments where the configured User Group > Provider does not provide the group information, this behavior can result in > authorization failures after refreshing the token. > The Bearer Token Refresh Filter should be corrected to retrieve group > membership information from the new Identity Provider token. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-12418) Identity Provider Groups Missing in Refreshed Bearer Token
[ https://issues.apache.org/jira/browse/NIFI-12418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798290#comment-17798290 ] ASF subversion and git services commented on NIFI-12418: Commit db919bc49401262edfad3c5beb00b169433954ce in nifi's branch refs/heads/support/nifi-1.x from David Handermann [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=db919bc494 ] NIFI-12418 Corrected Provider Groups Missing in Refreshed Tokens (#8126) - Updated OidcBearerTokenRefreshFilter to maintain current Identity Provider Groups when generating refreshed application Bearer Tokens - Refactored LoginAuthenticationToken to remove unnecessary optional constructors and use java.time.Instant for expiration - Added Issuer Provider with implementation for Bearer Token Issuer based on host and port properties > Identity Provider Groups Missing in Refreshed Bearer Token > -- > > Key: NIFI-12418 > URL: https://issues.apache.org/jira/browse/NIFI-12418 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework, Security >Affects Versions: 2.0.0-M1, 1.24.0 >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: backport-needed > Time Spent: 0.5h > Remaining Estimate: 0h > > The OIDC Bearer Token Refresh Filter is responsible for renewing application > Bearer Tokens when NiFi is integrated with an OpenID Connect Identity > Provider that supports the Refresh Token Grant Type. > NiFi 1.23.0 introduced changes for handling group membership information > supplied from an Identity Provider, passing the groups in the application > Bearer Token instead of persisting the groups in the local database > repository. > As a result of these handling changes, the Identity Provider group membership > information is not retained when the OIDC Bearer Token Refresh Filter > generates a new token. In deployments where the configured User Group > Provider does not provide the group information, this behavior can result in > authorization failures after refreshing the token. > The Bearer Token Refresh Filter should be corrected to retrieve group > membership information from the new Identity Provider token. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] NIFI-12493 Update Documentation References to Java 21 [nifi]
exceptionfactory commented on PR #8144: URL: https://github.com/apache/nifi/pull/8144#issuecomment-1861093446 Thanks @dan-s1. All of these are worth noting, but fall outside of the intended scope of Documentation References for this particular pull request. Anything that requires code changes probably needs to be more targeted, such as DateTimeFormatter for instance. So for these issues, there may be existing Jira tickets, but if not, it may be worth writing up some of them for tracking. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] NIFI-12493 Update Documentation References to Java 21 [nifi]
dan-s1 commented on PR #8144: URL: https://github.com/apache/nifi/pull/8144#issuecomment-1861080743 @exceptionfactory Thanks for clarifying those. Here a few more to consider - [StandardProcessSession](https://github.com/apache/nifi/blob/f73888e7dd4b0df37f5845bc318a7ad85f22d75d/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-components/src/main/java/org/apache/nifi/controller/repository/StandardProcessSession.java#L972-L974) - [ParseCEF](https://github.com/apache/nifi/blob/f73888e7dd4b0df37f5845bc318a7ad85f22d75d/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/ParseCEF.java#L97) - [pom.xml](https://github.com/apache/nifi/blob/f73888e7dd4b0df37f5845bc318a7ad85f22d75d/pom.xml#L1003) - [pom.xml](https://github.com/apache/nifi/blob/f73888e7dd4b0df37f5845bc318a7ad85f22d75d/pom.xml#L1302) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (NIFI-12418) Identity Provider Groups Missing in Refreshed Bearer Token
[ https://issues.apache.org/jira/browse/NIFI-12418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798283#comment-17798283 ] ASF subversion and git services commented on NIFI-12418: Commit 80700cc6c6c9e50b14ad006f05a649efe9cb1fd5 in nifi's branch refs/heads/main from David Handermann [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=80700cc6c6 ] NIFI-12418 Corrected Provider Groups Missing in Refreshed Tokens (#8126) - Updated OidcBearerTokenRefreshFilter to maintain current Identity Provider Groups when generating refreshed application Bearer Tokens - Refactored LoginAuthenticationToken to remove unnecessary optional constructors and use java.time.Instant for expiration - Added Issuer Provider with implementation for Bearer Token Issuer based on host and port properties > Identity Provider Groups Missing in Refreshed Bearer Token > -- > > Key: NIFI-12418 > URL: https://issues.apache.org/jira/browse/NIFI-12418 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework, Security >Affects Versions: 2.0.0-M1, 1.24.0 >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: backport-needed > Time Spent: 0.5h > Remaining Estimate: 0h > > The OIDC Bearer Token Refresh Filter is responsible for renewing application > Bearer Tokens when NiFi is integrated with an OpenID Connect Identity > Provider that supports the Refresh Token Grant Type. > NiFi 1.23.0 introduced changes for handling group membership information > supplied from an Identity Provider, passing the groups in the application > Bearer Token instead of persisting the groups in the local database > repository. > As a result of these handling changes, the Identity Provider group membership > information is not retained when the OIDC Bearer Token Refresh Filter > generates a new token. In deployments where the configured User Group > Provider does not provide the group information, this behavior can result in > authorization failures after refreshing the token. > The Bearer Token Refresh Filter should be corrected to retrieve group > membership information from the new Identity Provider token. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] NIFI-12418 Correct Provider Groups Missing in Refreshed Tokens [nifi]
bbende merged PR #8126: URL: https://github.com/apache/nifi/pull/8126 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] NIFI-12493 Update Documentation References to Java 21 [nifi]
exceptionfactory commented on PR #8144: URL: https://github.com/apache/nifi/pull/8144#issuecomment-1861027236 > @exceptionfactory The following are other places in the code I found JDK versions other than 21 mentioned: > > * [StandardALPNProcessor](https://github.com/apache/nifi/blob/f73888e7dd4b0df37f5845bc318a7ad85f22d75d/nifi-commons/nifi-jetty-configuration/src/main/java/org/apache/nifi/jetty/configuration/connector/alpn/StandardALPNProcessor.java#L33) > > * [StringUtils](https://github.com/apache/nifi/blob/f73888e7dd4b0df37f5845bc318a7ad85f22d75d/nifi-commons/nifi-property-utils/src/main/java/org/apache/nifi/util/StringUtils.java#L388) > > * [EnforceOrder](https://github.com/apache/nifi/blob/f73888e7dd4b0df37f5845bc318a7ad85f22d75d/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/EnforceOrder.java#L419-L421) > > * [TestDataTypeUtils](https://github.com/apache/nifi/blob/f73888e7dd4b0df37f5845bc318a7ad85f22d75d/nifi-commons/nifi-record/src/test/java/org/apache/nifi/serialization/record/TestDataTypeUtils.java#L104-L105) > > * [TestNiFiRecordSerDe](https://github.com/apache/nifi/blob/f73888e7dd4b0df37f5845bc318a7ad85f22d75d/nifi-nar-bundles/nifi-hive-bundle/nifi-hive3-processors/src/test/java/org/apache/hive/streaming/TestNiFiRecordSerDe.java#L48) > > * [TestPutHive3Streaming](https://github.com/apache/nifi/blob/f73888e7dd4b0df37f5845bc318a7ad85f22d75d/nifi-nar-bundles/nifi-hive-bundle/nifi-hive3-processors/src/test/java/org/apache/nifi/processors/hive/TestPutHive3Streaming.java#L126) @dan-s1 Those code references are for different types of issues. Some of them can be changed, but that should be covered separately. For example, the StandardALPNProcessor is something that will go away with some subsequent upgrades to new Jetty versions. The TestDataTypeUtils is a reference to NiFi 1.8, not Java 1.8. From that perspective, these items are worth noting, but it appears better to handle them on a case-by-case basis. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] NIFI-12493 Update Documentation References to Java 21 [nifi]
dan-s1 commented on PR #8144: URL: https://github.com/apache/nifi/pull/8144#issuecomment-1861011465 @exceptionfactory The following are other places I found JDK versions other than 21 mentioned: - [StandardALPNProcessor](https://github.com/apache/nifi/blob/f73888e7dd4b0df37f5845bc318a7ad85f22d75d/nifi-commons/nifi-jetty-configuration/src/main/java/org/apache/nifi/jetty/configuration/connector/alpn/StandardALPNProcessor.java#L33) - [StringUtils](https://github.com/apache/nifi/blob/f73888e7dd4b0df37f5845bc318a7ad85f22d75d/nifi-commons/nifi-property-utils/src/main/java/org/apache/nifi/util/StringUtils.java#L388) - [EnforceOrder](https://github.com/apache/nifi/blob/f73888e7dd4b0df37f5845bc318a7ad85f22d75d/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/EnforceOrder.java#L419-L421) - [TestDataTypeUtils](https://github.com/apache/nifi/blob/f73888e7dd4b0df37f5845bc318a7ad85f22d75d/nifi-commons/nifi-record/src/test/java/org/apache/nifi/serialization/record/TestDataTypeUtils.java#L104-L105) - [TestNiFiRecordSerDe](https://github.com/apache/nifi/blob/f73888e7dd4b0df37f5845bc318a7ad85f22d75d/nifi-nar-bundles/nifi-hive-bundle/nifi-hive3-processors/src/test/java/org/apache/hive/streaming/TestNiFiRecordSerDe.java#L48) - [TestPutHive3Streaming](https://github.com/apache/nifi/blob/f73888e7dd4b0df37f5845bc318a7ad85f22d75d/nifi-nar-bundles/nifi-hive-bundle/nifi-hive3-processors/src/test/java/org/apache/nifi/processors/hive/TestPutHive3Streaming.java#L126) - -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] MINIFICPP-2273 Update minifi documentation [nifi-site]
martinzink commented on PR #79: URL: https://github.com/apache/nifi-site/pull/79#issuecomment-1860945190 > > > Thanks for making the updates @martinzink. > > > Looking at the latest version, I think it would be better to introducing the new about pages and simply have two separate sections on the main MiNiFi page, one paragraph for Java, and one for CPP. > > > > > > Not sure if I follow you here. :/ Should I remove the MiNiFi Java, MiNiFi C++ dropdowns and include those links in their about md. Which I should simple embed in the landing page? > > Thanks for the reply, sorry for the confusion. > > On further review, I see that the two about pages for Java and C++ are pulled in through an include to the main index.md. Although that content could be moved to the `partials` directory and then included, it seems like it would be best to simple copy the content from the about files into the index.md directly, avoiding the need for separate files. Is there some other reason for having that content in separate files, as opposed to just having it written directly in the index.md? The reason I went with this convoluted way is that I wanted to create a proper up-to-date starting guide/landing page separately for java and c++ aswell and it would have made sense to include these small summaries there aswell. After a little bit of time I felt that those pages are a bit out of the scope of this PR and wanna do them in a followup PR (maybe after the redesign?). But I agree its unneccessary complication for now, so I've removed these in https://github.com/apache/nifi-site/pull/79/commits/30521e9046501bb4ee55e36578343b47a92457b6 and I'll cross this bridge when I come to it :D -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] NIFI-12502: Handle additional Property Table capabilities [nifi]
mcgilman commented on code in PR #8159:
URL: https://github.com/apache/nifi/pull/8159#discussion_r1430362779
##
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-frontend/src/main/nifi/src/app/pages/flow-designer/state/controller-services/controller-services.effects.ts:
##
@@ -234,18 +253,134 @@ export class ControllerServicesEffects {
);
};
-editDialogReference.componentInstance.getServiceLink =
(serviceId: string) => {
-return
this.controllerServiceService.getControllerService(serviceId).pipe(
-take(1),
-map((serviceEntity) => {
-return [
+const goTo = (commands: string[], destination: string):
void => {
+if
(editDialogReference.componentInstance.editControllerServiceForm.dirty) {
+const saveChangesDialogReference =
this.dialog.open(YesNoDialog, {
+data: {
+title: 'Controller Service Configuration',
+message: `Save changes before going to
this ${destination}?`
+},
+panelClass: 'small-dialog'
+});
+
+
saveChangesDialogReference.componentInstance.yes.pipe(take(1)).subscribe(() => {
+
editDialogReference.componentInstance.submitForm(commands);
+});
+
+
saveChangesDialogReference.componentInstance.no.pipe(take(1)).subscribe(() => {
+editDialogReference.close('ROUTED');
+this.router.navigate(commands);
+});
+} else {
+editDialogReference.close('ROUTED');
+this.router.navigate(commands);
+}
+};
+
+if (parameterContext != null) {
+editDialogReference.componentInstance.getParameters =
(sensitive: boolean) => {
+return
this.flowService.getParameterContext(parameterContext.id).pipe(
+take(1),
+map((response) =>
response.component.parameters),
+map((parameterEntities) => {
+return parameterEntities
+.map((parameterEntity:
ParameterEntity) => parameterEntity.parameter)
+.filter((parameter: Parameter) =>
parameter.sensitive == sensitive);
+})
+);
+};
+
+editDialogReference.componentInstance.parameterContext
= parameterContext;
+editDialogReference.componentInstance.goToParameter =
(parameter: string) => {
+const commands: string[] = ['/parameter-contexts',
parameterContext.id];
+goTo(commands, 'Parameter');
+};
+
+
editDialogReference.componentInstance.convertToParameter = (
+name: string,
+sensitive: boolean,
+value: string | null
+) => {
+return
this.parameterService.getParameterContext(parameterContext.id, false).pipe(
+switchMap((parameterContextEntity) => {
+const existingParameters: string[] =
+
parameterContextEntity.component.parameters.map(
+(parameterEntity: ParameterEntity)
=> parameterEntity.parameter.name
+);
+const convertToParameterDialogRequest:
EditParameterRequest = {
+parameter: {
+name,
+value,
+sensitive,
+description: ''
+},
+existingParameters
+};
+const convertToParameterDialogReference =
this.dialog.open(EditParameterDialog, {
+data: convertToParameterDialogRequest,
+panelClass: 'medium-dialog'
+});
+
+
Re: [PR] NIFI-12493 Update Documentation References to Java 21 [nifi]
dan-s1 commented on PR #8144: URL: https://github.com/apache/nifi/pull/8144#issuecomment-1860915655 @exceptionfactory I have found 2 comments in files which reference Java 1.8 `nifi-commons/nifi-security-utils/src/test/java/org/apache/nifi/security/util/KeyStoreUtilsTest.java` on line 184 > // Select Key Protection Algorithm for PKCS12 to avoid unsupported algorithm on Java 1.8.0.292 and `nifi-stateless/nifi-stateless-bootstrap/src/main/java/org/apache/nifi/stateless/bootstrap/AllowListClassLoader.java` lines 102-105 > // If the class has a module whose name is allowed, allow it. > // The module is obtained by calling Class.getModule(). However, that method is only available in Java 9. > // Since this codebase must be Java 8 compatible we can't make that method call. So we use Reflection to determine > // if the getModule method exists (which it will for Java 9+ but not Java 1.8), and if so get the name of the module. Do these comments make sense anymore if this branch only supports Java 21? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (NIFI-12402) MonitorActivity generates inactivity indicator after it is started and threshold duration exceeds without actual activities
[
https://issues.apache.org/jira/browse/NIFI-12402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798242#comment-17798242
]
Daniel Stieglitz commented on NIFI-12402:
-
[~nathluu] Can you please better describe your issue with the MonitorActivity
processor? It seems based on the description of 'Threshold Duration{*}'{*}
??Determines how much time must elapse before considering the flow to be
inactive??
that what you describe is the expected behavior.
> MonitorActivity generates inactivity indicator after it is started and
> threshold duration exceeds without actual activities
> ---
>
> Key: NIFI-12402
> URL: https://issues.apache.org/jira/browse/NIFI-12402
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: 1.23.2
>Reporter: Tan Luu
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> MonitorActivity @OnScheduled method sets the "{*}inactive"{*} flag to false
> when it gets started so after the threshold duration without activity, an
> inactive indicator is created even if there is no actual activity.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (NIFI-12402) MonitorActivity generates inactivity indicator after it is started and threshold duration exceeds without actual activities
[
https://issues.apache.org/jira/browse/NIFI-12402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798242#comment-17798242
]
Daniel Stieglitz edited comment on NIFI-12402 at 12/18/23 3:26 PM:
---
[~nathluu] Can you please better describe your issue with the MonitorActivity
processor? It seems based on the description of 'Threshold Duration{*}'{*}
??Determines how much time must elapse before considering the flow to be
inactive??
that what you describe is the expected behavior.
was (Author: JIRAUSER294662):
[~nathluu] Can you please better describe your issue with the MonitorActivity
processor? It seems based on the description of 'Threshold Duration{*}'{*}
??Determines how much time must elapse before considering the flow to be
inactive??
that what you describe is the expected behavior.
> MonitorActivity generates inactivity indicator after it is started and
> threshold duration exceeds without actual activities
> ---
>
> Key: NIFI-12402
> URL: https://issues.apache.org/jira/browse/NIFI-12402
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Affects Versions: 1.23.2
>Reporter: Tan Luu
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> MonitorActivity @OnScheduled method sets the "{*}inactive"{*} flag to false
> when it gets started so after the threshold duration without activity, an
> inactive indicator is created even if there is no actual activity.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-11308) Add nifi.framework.version System Property for Expression Language
[ https://issues.apache.org/jira/browse/NIFI-11308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-11308: Summary: Add nifi.framework.version System Property for Expression Language (was: Create an Expression Language function to return NiFi version) > Add nifi.framework.version System Property for Expression Language > -- > > Key: NIFI-11308 > URL: https://issues.apache.org/jira/browse/NIFI-11308 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.19.1 >Reporter: Mark Bean >Assignee: Anna Nys >Priority: Major > Fix For: 1.25.0, 2.0.0 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Create a new Expression Language function which returns the version of NiFi > being run. This allows for programmatic access to version information within > the flow. Suggest the function be subjectless as it applies to the instance > making the EL call and be called "nifiVersion()" > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-11308) Create an Expression Language function to return NiFi version
[ https://issues.apache.org/jira/browse/NIFI-11308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798235#comment-17798235 ] ASF subversion and git services commented on NIFI-11308: Commit bbf327fa2733c4beec2eaa9a157dc4367df711fb in nifi's branch refs/heads/support/nifi-1.x from annanys23 [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=bbf327fa27 ] NIFI-11308 Added nifi.framework.version System Property for EL - Updated Expression Language Guide to note the available system property providing the current framework version according to the Framework NAR version This closes #8101 Signed-off-by: David Handermann (cherry picked from commit 93c9efe527e16313a79c954d02f1613c39ba6493) > Create an Expression Language function to return NiFi version > - > > Key: NIFI-11308 > URL: https://issues.apache.org/jira/browse/NIFI-11308 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.19.1 >Reporter: Mark Bean >Assignee: Anna Nys >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Create a new Expression Language function which returns the version of NiFi > being run. This allows for programmatic access to version information within > the flow. Suggest the function be subjectless as it applies to the instance > making the EL call and be called "nifiVersion()" > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-11308) Create an Expression Language function to return NiFi version
[ https://issues.apache.org/jira/browse/NIFI-11308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-11308: Fix Version/s: 1.25.0 2.0.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Create an Expression Language function to return NiFi version > - > > Key: NIFI-11308 > URL: https://issues.apache.org/jira/browse/NIFI-11308 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.19.1 >Reporter: Mark Bean >Assignee: Anna Nys >Priority: Major > Fix For: 1.25.0, 2.0.0 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Create a new Expression Language function which returns the version of NiFi > being run. This allows for programmatic access to version information within > the flow. Suggest the function be subjectless as it applies to the instance > making the EL call and be called "nifiVersion()" > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-11308) Create an Expression Language function to return NiFi version
[ https://issues.apache.org/jira/browse/NIFI-11308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798233#comment-17798233 ] ASF subversion and git services commented on NIFI-11308: Commit 93c9efe527e16313a79c954d02f1613c39ba6493 in nifi's branch refs/heads/main from annanys23 [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=93c9efe527 ] NIFI-11308 Added nifi.framework.version System Property for EL - Updated Expression Language Guide to note the available system property providing the current framework version according to the Framework NAR version This closes #8101 Signed-off-by: David Handermann > Create an Expression Language function to return NiFi version > - > > Key: NIFI-11308 > URL: https://issues.apache.org/jira/browse/NIFI-11308 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.19.1 >Reporter: Mark Bean >Assignee: Anna Nys >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Create a new Expression Language function which returns the version of NiFi > being run. This allows for programmatic access to version information within > the flow. Suggest the function be subjectless as it applies to the instance > making the EL call and be called "nifiVersion()" > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] NIFI-11308 Adding expression language function to return nifi version [nifi]
exceptionfactory closed pull request #8101: NIFI-11308 Adding expression language function to return nifi version URL: https://github.com/apache/nifi/pull/8101 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (NIFI-12480) Improve handling of embedded JSON records
[
https://issues.apache.org/jira/browse/NIFI-12480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-12480:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Improve handling of embedded JSON records
> -
>
> Key: NIFI-12480
> URL: https://issues.apache.org/jira/browse/NIFI-12480
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework, Extensions
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Major
> Fix For: 2.0.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> It proves to be difficult to treat embedded JSON elements as Strings. There
> are times when this is necessary, such as when pushing to a database that
> declares a field of type JSON or interacting with a web service that expects
> incoming JSON as a String. However, there's no easy way to do this in NiFi
> today.
> Instead, what typically happens is that the Record gets converted to a String
> via a call to {{toString()}} and that produces something like
> {{{}MapRecord[name=John Doe, color=blue]{}}}, which is not helpful.
> However, when a JSON Reader is used, we already have a JSON representation of
> the Record in the record's SerializedForm. When {{toString()}} is called, we
> should always use the SerializedForm of a Record, if it is available and only
> fall back to the given version.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-12522) Upgrade Netty to 4.1.104.Final
[ https://issues.apache.org/jira/browse/NIFI-12522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-12522: Summary: Upgrade Netty to 4.1.104.Final (was: Update netty4 version to 4.1.104.final) > Upgrade Netty to 4.1.104.Final > -- > > Key: NIFI-12522 > URL: https://issues.apache.org/jira/browse/NIFI-12522 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Mike R >Assignee: Mike R >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > Update netty4 version to 4.1.104.final -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-12522) Upgrade Netty to 4.1.104.Final
[ https://issues.apache.org/jira/browse/NIFI-12522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann resolved NIFI-12522. - Fix Version/s: 1.25.0 2.0.0 Resolution: Fixed > Upgrade Netty to 4.1.104.Final > -- > > Key: NIFI-12522 > URL: https://issues.apache.org/jira/browse/NIFI-12522 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Mike R >Assignee: Mike R >Priority: Minor > Fix For: 1.25.0, 2.0.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Update netty4 version to 4.1.104.final -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12522) Update netty4 version to 4.1.104.final
[ https://issues.apache.org/jira/browse/NIFI-12522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-12522: Affects Version/s: (was: 2.0.0-M1) > Update netty4 version to 4.1.104.final > -- > > Key: NIFI-12522 > URL: https://issues.apache.org/jira/browse/NIFI-12522 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Mike R >Assignee: Mike R >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > Update netty4 version to 4.1.104.final -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12522) Update netty4 version to 4.1.104.final
[ https://issues.apache.org/jira/browse/NIFI-12522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-12522: Priority: Minor (was: Major) > Update netty4 version to 4.1.104.final > -- > > Key: NIFI-12522 > URL: https://issues.apache.org/jira/browse/NIFI-12522 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 2.0.0-M1 >Reporter: Mike R >Assignee: Mike R >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > Update netty4 version to 4.1.104.final -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-12522) Update netty4 version to 4.1.104.final
[ https://issues.apache.org/jira/browse/NIFI-12522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798225#comment-17798225 ] ASF subversion and git services commented on NIFI-12522: Commit d25e305f091834f13836601e56ac230fb4bb40c8 in nifi's branch refs/heads/support/nifi-1.x from mr1716 [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=d25e305f09 ] NIFI-12522 Upgraded Netty from 4.1.100 to 4.1.104 This closes #8169 Signed-off-by: David Handermann > Update netty4 version to 4.1.104.final > -- > > Key: NIFI-12522 > URL: https://issues.apache.org/jira/browse/NIFI-12522 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 2.0.0-M1 >Reporter: Mike R >Assignee: Mike R >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Update netty4 version to 4.1.104.final -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-12522) Update netty4 version to 4.1.104.final
[ https://issues.apache.org/jira/browse/NIFI-12522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798223#comment-17798223 ] ASF subversion and git services commented on NIFI-12522: Commit facb43ea89fb05ad66e8368b37fcb600a224c130 in nifi's branch refs/heads/main from mr1716 [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=facb43ea89 ] NIFI-12522 Upgraded Netty from 4.1.101 to 4.1.104 This closes #8169 Signed-off-by: David Handermann > Update netty4 version to 4.1.104.final > -- > > Key: NIFI-12522 > URL: https://issues.apache.org/jira/browse/NIFI-12522 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 2.0.0-M1 >Reporter: Mike R >Assignee: Mike R >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Update netty4 version to 4.1.104.final -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-12480) Improve handling of embedded JSON records
[
https://issues.apache.org/jira/browse/NIFI-12480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798224#comment-17798224
]
ASF subversion and git services commented on NIFI-12480:
Commit ba599d29c24a95cec568d0a96614f67506d2e527 in nifi's branch
refs/heads/main from Mark Payne
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=ba599d29c2 ]
NIFI-12480 Updated MapRecord's toString() method to use the SerializedForm of
the record when available and fixed bugs around ensuring that the serialized
form is properly set
This closes #8132
Signed-off-by: David Handermann
> Improve handling of embedded JSON records
> -
>
> Key: NIFI-12480
> URL: https://issues.apache.org/jira/browse/NIFI-12480
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework, Extensions
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Major
> Fix For: 2.0.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> It proves to be difficult to treat embedded JSON elements as Strings. There
> are times when this is necessary, such as when pushing to a database that
> declares a field of type JSON or interacting with a web service that expects
> incoming JSON as a String. However, there's no easy way to do this in NiFi
> today.
> Instead, what typically happens is that the Record gets converted to a String
> via a call to {{toString()}} and that produces something like
> {{{}MapRecord[name=John Doe, color=blue]{}}}, which is not helpful.
> However, when a JSON Reader is used, we already have a JSON representation of
> the Record in the record's SerializedForm. When {{toString()}} is called, we
> should always use the SerializedForm of a Record, if it is available and only
> fall back to the given version.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] NIFI-12480: Updated MapRecord's toString() method to use the Serializ… [nifi]
exceptionfactory closed pull request #8132: NIFI-12480: Updated MapRecord's toString() method to use the Serializ… URL: https://github.com/apache/nifi/pull/8132 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] NIFI-12522 Update netty4 version to 4.1.104.final [nifi]
exceptionfactory closed pull request #8169: NIFI-12522 Update netty4 version to 4.1.104.final URL: https://github.com/apache/nifi/pull/8169 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [NIFI-12519] - deselect parameter when it is deleted. [nifi]
mcgilman commented on PR #8166: URL: https://github.com/apache/nifi/pull/8166#issuecomment-1860618867 Will review... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] MINIFICPP-2273 Update minifi documentation [nifi-site]
exceptionfactory commented on PR #79: URL: https://github.com/apache/nifi-site/pull/79#issuecomment-1860597378 > > Thanks for making the updates @martinzink. > > Looking at the latest version, I think it would be better to introducing the new about pages and simply have two separate sections on the main MiNiFi page, one paragraph for Java, and one for CPP. > > Not sure if I follow you here. :/ Should I remove the MiNiFi Java, MiNiFi C++ dropdowns and include those links in their about md. Which I should simple embed in the landing page? Thanks for the reply, sorry for the confusion. On further review, I see that the two about pages for Java and C++ are pulled in through an include to the main index.md. Although that content could be moved to the `partials` directory and then included, it seems like it would be best to simple copy the content from the about files into the index.md directly, avoiding the need for separate files. Is there some other reason for having that content in separate files, as opposed to just having it written directly in the index.md? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] NIFI-12522 Update netty4 version to 4.1.104.final [nifi]
mr1716 commented on PR #8169: URL: https://github.com/apache/nifi/pull/8169#issuecomment-1860447402 The static analysis ran successfully for the local branch, which is up to date with main when created. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MINIFICPP-2264) GenerateFlowFile: 'Custom Text' is not reevaluated
[ https://issues.apache.org/jira/browse/MINIFICPP-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Zink updated MINIFICPP-2264: --- Status: Patch Available (was: In Progress) > GenerateFlowFile: 'Custom Text' is not reevaluated > --- > > Key: MINIFICPP-2264 > URL: https://issues.apache.org/jira/browse/MINIFICPP-2264 > Project: Apache NiFi MiNiFi C++ > Issue Type: Bug >Reporter: Marton Szasz >Assignee: Martin Zink >Priority: Major > Labels: beginner, beginner-friendly > Time Spent: 10m > Remaining Estimate: 0h > > 'Unique flow files' must be false for the custom text to be evaluated, but in > that case, it should be reevaluated on every trigger, like in NiFi. This > allows EL expressions like now() or nextInt() to return different values each > time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-11671) JoinEnrichment SQL strategy doesn't allow attributes in join statement
[
https://issues.apache.org/jira/browse/NIFI-11671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798147#comment-17798147
]
Philipp Korniets commented on NIFI-11671:
-
[~pvillard] [~markap14] - any update?
> JoinEnrichment SQL strategy doesn't allow attributes in join statement
> --
>
> Key: NIFI-11671
> URL: https://issues.apache.org/jira/browse/NIFI-11671
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 1.18.0, 1.20.0, 1.23.0
>Reporter: Philipp Korniets
>Assignee: Mark Payne
>Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We use ForkEnrichement - JoinEnrichment pattern and want to include filtering
> in join SQL. Filter value is coming from FlowFile attribute
> {code:sql}
> ${test} = 'NewValue'
> SELECT original.*, enrichment.*,'${test}'
> FROM original
> LEFT OUTER JOIN enrichment
> ON original.Underlying = enrichment.Underlying
> WHERE enrichment.MyField = '${test}'
> {code}
> However this doesnt work because JoinEnrichment doesnt use
> evaluateAttributeExpressions
> Additionally in version 1.18,1.23 - doesnt allow whole query to be passed as
> attribute.
> !screenshot-1.png|width=692,height=431!
>
> {code:java}
> 2023-06-28 11:07:16,611 ERROR [Timer-Driven Process Thread-7]
> o.a.n.processors.standard.JoinEnrichment
> JoinEnrichment[id=dbe156ac-0187-1000-4477-0183899e0432] Failed to join
> 'original' FlowFile
> StandardFlowFileRecord[uuid=2ab9f6ad-73a5-4763-b25e-fd26c44835e1,claim=StandardContentClaim
> [resourceClaim=StandardResourceClaim[id=1687948831976-629,
> container=default, section=629], offset=8334082,
> length=600557],offset=0,name=lmr_SY08C41-1_S_514682_20230627.csv,size=600557]
> and 'enrichment' FlowFile
> StandardFlowFileRecord[uuid=e4bb7769-fdce-4dfe-af18-443676103035,claim=StandardContentClaim
> [resourceClaim=StandardResourceClaim[id=1687949723375-631,
> container=default, section=631], offset=5362822,
> length=1999502],offset=0,name=lmr_SY08C41-1_S_514682_20230627.csv,size=1999502];
> routing to failure
> java.sql.SQLException: Error while preparing statement [${instrumentJoinSQL}]
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement_(CalciteConnectionImpl.java:224)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement(CalciteConnectionImpl.java:203)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement(CalciteConnectionImpl.java:99)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareStatement(AvaticaConnection.java:178)
> at
> org.apache.nifi.processors.standard.enrichment.SqlJoinCache.createCalciteParameters(SqlJoinCache.java:91)
> at
> org.apache.nifi.processors.standard.enrichment.SqlJoinCache.getCalciteParameters(SqlJoinCache.java:65)
> at
> org.apache.nifi.processors.standard.enrichment.SqlJoinStrategy.join(SqlJoinStrategy.java:49)
> at
> org.apache.nifi.processors.standard.JoinEnrichment.processBin(JoinEnrichment.java:387)
> at
> org.apache.nifi.processor.util.bin.BinFiles.processBins(BinFiles.java:233)
> at
> org.apache.nifi.processors.standard.JoinEnrichment.processBins(JoinEnrichment.java:503)
> at
> org.apache.nifi.processor.util.bin.BinFiles.onTrigger(BinFiles.java:193)
> at
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1354)
> at
> org.apache.nifi.controller.tasks.ConnectableTask.invoke(ConnectableTask.java:246)
> at
> org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:102)
> at org.apache.nifi.engine.FlowEngine$2.run(FlowEngine.java:110)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> 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:750)
> Caused by: java.lang.RuntimeException: parse failed: Encountered "$" at line
> 1, column 1.
> Was expecting one of:
> "ABS" ...
> {code}
> As I understand issue is in following line of code
>
Re: [PR] MINIFICPP-2273 Update minifi documentation [nifi-site]
martinzink commented on PR #79: URL: https://github.com/apache/nifi-site/pull/79#issuecomment-1859989493 > Thanks for making the updates @martinzink. > > Looking at the latest version, I think it would be better to introducing the new about pages and simply have two separate sections on the main MiNiFi page, one paragraph for Java, and one for CPP. Not sure if I follow you here. :/ Should I remove the MiNiFi Java, MiNiFi C++ dropdowns and include those links in their about md. Which I should simple embed in the landing page? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
