[jira] [Commented] (NIFI-4388) Module path not honored using InvokeScriptedProcessor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4388:
--

GitHub user bdesert opened a pull request:

https://github.com/apache/nifi/pull/2584

NIFI-4388: Modules Not Honored

Modules aren't honored. The bug is not reproducible in Jython (it handles 
modules with every script reload). But Groovy loads JARs and dirs with classes 
only on setup. Cannot provide test cases for Groovy, because it requires custom 
JARs to be provided as part of the package.
-
Thank you for submitting a contribution to Apache NiFi.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced 
 in the commit message?

- [x] Does your PR title start with NIFI- where  is the JIRA number 
you are trying to resolve? Pay particular attention to the hyphen "-" character.

- [x] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [x] Is your initial contribution a single, squashed commit?

### For code changes:
- [x] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [ ] If applicable, have you updated the LICENSE file, including the main 
LICENSE file under nifi-assembly?
- [ ] If applicable, have you updated the NOTICE file, including the main 
NOTICE file found under nifi-assembly?
- [ ] If adding new Properties, have you added .displayName in addition to 
.name (programmatic access) for each of the new properties?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bdesert/nifi NIFI-4388_ISP_Modules_Reload

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/2584.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2584


commit 0280f59a173e82df926acc9c6f50ef3b5302c9fa
Author: Ed 
Date:   2018-03-27T04:22:12Z

NIFI-4388: Modules Not Honored

Modules aren't honored. The bug is not reproducible in Jython (it handles 
modules with every script reload). But Groovy loads JARs and dirs with classes 
only on setup. Cannot provide test cases for Groovy, because it requires custom 
JARs to be provided as part of the package.




> Module path not honored using InvokeScriptedProcessor
> -
>
> Key: NIFI-4388
> URL: https://issues.apache.org/jira/browse/NIFI-4388
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.1.0, 1.3.0, 1.5.0
>Reporter: Patrice Freydiere
>Assignee: Ed Berezitsky
>Priority: Major
>
> When specify modulepath parameter, using groovy scriptedengine, the jars are 
> not added to classpath.
> This is currently not possible to use third party library in scripting



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi pull request #2584: NIFI-4388: Modules Not Honored

[bdesert]

GitHub user bdesert opened a pull request:

https://github.com/apache/nifi/pull/2584

NIFI-4388: Modules Not Honored

Modules aren't honored. The bug is not reproducible in Jython (it handles 
modules with every script reload). But Groovy loads JARs and dirs with classes 
only on setup. Cannot provide test cases for Groovy, because it requires custom 
JARs to be provided as part of the package.
-
Thank you for submitting a contribution to Apache NiFi.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced 
 in the commit message?

- [x] Does your PR title start with NIFI- where  is the JIRA number 
you are trying to resolve? Pay particular attention to the hyphen "-" character.

- [x] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [x] Is your initial contribution a single, squashed commit?

### For code changes:
- [x] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [ ] If applicable, have you updated the LICENSE file, including the main 
LICENSE file under nifi-assembly?
- [ ] If applicable, have you updated the NOTICE file, including the main 
NOTICE file found under nifi-assembly?
- [ ] If adding new Properties, have you added .displayName in addition to 
.name (programmatic access) for each of the new properties?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bdesert/nifi NIFI-4388_ISP_Modules_Reload

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/2584.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2584


commit 0280f59a173e82df926acc9c6f50ef3b5302c9fa
Author: Ed 
Date:   2018-03-27T04:22:12Z

NIFI-4388: Modules Not Honored

Modules aren't honored. The bug is not reproducible in Jython (it handles 
modules with every script reload). But Groovy loads JARs and dirs with classes 
only on setup. Cannot provide test cases for Groovy, because it requires custom 
JARs to be provided as part of the package.




---

[jira] [Commented] (NIFI-4927) Create InfluxDB Query Processor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4927:
--

Github user mans2singh commented on the issue:

https://github.com/apache/nifi/pull/2562
  
@MikeThomsen - I've updated the code based on your comments (added check 
for query result null, changed scheduled query property name).  One note, if we 
use the influxdb-compose.xml file for integration testing, we will need to 
change the name of the db (from test to something else) which the curl loader 
uses, since integration test use their own data.

Please let me know your thoughts/recommendations.

Thanks.


> Create InfluxDB Query Processor
> ---
>
> Key: NIFI-4927
> URL: https://issues.apache.org/jira/browse/NIFI-4927
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: 1.5.0
>Reporter: Mans Singh
>Assignee: Mans Singh
>Priority: Minor
>  Labels: measurements,, query, realtime, timeseries
>
> Create InfluxDB Query processor



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi issue #2562: NIFI-4927 - InfluxDB Query Processor

[mans2singh]

Github user mans2singh commented on the issue:

https://github.com/apache/nifi/pull/2562
  
@MikeThomsen - I've updated the code based on your comments (added check 
for query result null, changed scheduled query property name).  One note, if we 
use the influxdb-compose.xml file for integration testing, we will need to 
change the name of the db (from test to something else) which the curl loader 
uses, since integration test use their own data.

Please let me know your thoughts/recommendations.

Thanks.


---

[jira] [Commented] (NIFI-4927) Create InfluxDB Query Processor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4927:
--

Github user mans2singh commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2562#discussion_r177296540
  
--- Diff: 
nifi-nar-bundles/nifi-influxdb-bundle/nifi-influxdb-processors/src/main/java/org/apache/nifi/processors/influxdb/ExecuteInfluxDBQuery.java
 ---
@@ -0,0 +1,199 @@
+/*
+ * 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.influxdb;
+import org.apache.nifi.annotation.behavior.EventDriven;
+import org.apache.nifi.annotation.behavior.InputRequirement;
+import org.apache.nifi.annotation.behavior.SupportsBatching;
+import org.apache.nifi.annotation.behavior.WritesAttribute;
+import org.apache.nifi.annotation.behavior.WritesAttributes;
+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.annotation.lifecycle.OnStopped;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.flowfile.FlowFile;
+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.influxdb.dto.Query;
+import org.influxdb.dto.QueryResult;
+import com.google.gson.Gson;
+import java.io.ByteArrayInputStream;
+import java.io.ByteArrayOutputStream;
+import java.net.SocketTimeoutException;
+import java.nio.charset.Charset;
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Map;
+import java.util.Set;
+import java.util.concurrent.TimeUnit;
+import java.util.stream.Collectors;
+
+@InputRequirement(InputRequirement.Requirement.INPUT_REQUIRED)
+@EventDriven
+@SupportsBatching
+@Tags({"influxdb", "measurement","get", "read", "query", "timeseries"})
+@CapabilityDescription("Processor to execute InfluxDB query from the 
content of a FlowFile.  Please check details of the supported queries in 
InfluxDB documentation (https://www.influxdb.com/).")
+@WritesAttributes({
+@WritesAttribute(attribute = 
AbstractInfluxDBProcessor.INFLUX_DB_ERROR_MESSAGE, description = "InfluxDB 
error message"),
+@WritesAttribute(attribute = 
ExecuteInfluxDBQuery.INFLUX_DB_EXECUTED_QUERY, description = "InfluxDB executed 
query"),
+})
+public class ExecuteInfluxDBQuery extends AbstractInfluxDBProcessor {
+
+public static final String INFLUX_DB_EXECUTED_QUERY = 
"influxdb.executed.query";
+
+public static final PropertyDescriptor INFLUX_DB_QUERY_RESULT_TIMEUNIT 
= new PropertyDescriptor.Builder()
+.name("influxdb-query-result-time-unit")
+.displayName("Query Result Time Units")
+.description("The time unit of query results from the 
InfluxDB")
+.defaultValue(TimeUnit.NANOSECONDS.name())
+.required(true)
+.expressionLanguageSupported(true)
+.allowableValues(Arrays.stream(TimeUnit.values()).map( v -> 
v.name()).collect(Collectors.toSet()))
+.sensitive(false)
+.build();
+
+static final Relationship REL_SUCCESS = new 
Relationship.Builder().name("success")
+.description("Successful InfluxDB queries are routed to this 
relationship").build();
+
+static final Relationship REL_FAILURE = new 
Relationship.Builder().name("failure")
+.description("Falied InfluxDB queries are routed to this 
relationship").build();
+
+static final Relationship REL_RETRY = new 

[jira] [Commented] (NIFI-4927) Create InfluxDB Query Processor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4927:
--

Github user mans2singh commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2562#discussion_r177296457
  
--- Diff: 
nifi-nar-bundles/nifi-influxdb-bundle/nifi-influxdb-processors/src/test/java/org/apache/nifi/processors/influxdb/AbstractITInfluxDB.java
 ---
@@ -36,14 +36,7 @@
 
 protected void initInfluxDB() throws InterruptedException, Exception {
 influxDB = InfluxDBFactory.connect(dbUrl,user,password);
-if ( influxDB.databaseExists(dbName) ) {
-QueryResult result = influxDB.query(new Query("DROP 
measurement water", dbName));
-checkError(result);
-result = influxDB.query(new Query("DROP measurement testm", 
dbName));
-checkError(result);
-result = influxDB.query(new Query("DROP database " + dbName, 
dbName));
-Thread.sleep(1000);
-}
+cleanUpDatabase();
--- End diff --

I call the cleanup in setup as a precaution so that if there is any 
conflicting/previously existing data in the test database, it is removed and 
does not fail the integration test which depend on number of rows inserted.  If 
you think it is unnecessary, I can remove it.


> Create InfluxDB Query Processor
> ---
>
> Key: NIFI-4927
> URL: https://issues.apache.org/jira/browse/NIFI-4927
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: 1.5.0
>Reporter: Mans Singh
>Assignee: Mans Singh
>Priority: Minor
>  Labels: measurements,, query, realtime, timeseries
>
> Create InfluxDB Query processor



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi pull request #2562: NIFI-4927 - InfluxDB Query Processor

[mans2singh]

Github user mans2singh commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2562#discussion_r177296540
  
--- Diff: 
nifi-nar-bundles/nifi-influxdb-bundle/nifi-influxdb-processors/src/main/java/org/apache/nifi/processors/influxdb/ExecuteInfluxDBQuery.java
 ---
@@ -0,0 +1,199 @@
+/*
+ * 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.influxdb;
+import org.apache.nifi.annotation.behavior.EventDriven;
+import org.apache.nifi.annotation.behavior.InputRequirement;
+import org.apache.nifi.annotation.behavior.SupportsBatching;
+import org.apache.nifi.annotation.behavior.WritesAttribute;
+import org.apache.nifi.annotation.behavior.WritesAttributes;
+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.annotation.lifecycle.OnStopped;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.flowfile.FlowFile;
+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.influxdb.dto.Query;
+import org.influxdb.dto.QueryResult;
+import com.google.gson.Gson;
+import java.io.ByteArrayInputStream;
+import java.io.ByteArrayOutputStream;
+import java.net.SocketTimeoutException;
+import java.nio.charset.Charset;
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Map;
+import java.util.Set;
+import java.util.concurrent.TimeUnit;
+import java.util.stream.Collectors;
+
+@InputRequirement(InputRequirement.Requirement.INPUT_REQUIRED)
+@EventDriven
+@SupportsBatching
+@Tags({"influxdb", "measurement","get", "read", "query", "timeseries"})
+@CapabilityDescription("Processor to execute InfluxDB query from the 
content of a FlowFile.  Please check details of the supported queries in 
InfluxDB documentation (https://www.influxdb.com/).")
+@WritesAttributes({
+@WritesAttribute(attribute = 
AbstractInfluxDBProcessor.INFLUX_DB_ERROR_MESSAGE, description = "InfluxDB 
error message"),
+@WritesAttribute(attribute = 
ExecuteInfluxDBQuery.INFLUX_DB_EXECUTED_QUERY, description = "InfluxDB executed 
query"),
+})
+public class ExecuteInfluxDBQuery extends AbstractInfluxDBProcessor {
+
+public static final String INFLUX_DB_EXECUTED_QUERY = 
"influxdb.executed.query";
+
+public static final PropertyDescriptor INFLUX_DB_QUERY_RESULT_TIMEUNIT 
= new PropertyDescriptor.Builder()
+.name("influxdb-query-result-time-unit")
+.displayName("Query Result Time Units")
+.description("The time unit of query results from the 
InfluxDB")
+.defaultValue(TimeUnit.NANOSECONDS.name())
+.required(true)
+.expressionLanguageSupported(true)
+.allowableValues(Arrays.stream(TimeUnit.values()).map( v -> 
v.name()).collect(Collectors.toSet()))
+.sensitive(false)
+.build();
+
+static final Relationship REL_SUCCESS = new 
Relationship.Builder().name("success")
+.description("Successful InfluxDB queries are routed to this 
relationship").build();
+
+static final Relationship REL_FAILURE = new 
Relationship.Builder().name("failure")
+.description("Falied InfluxDB queries are routed to this 
relationship").build();
+
+static final Relationship REL_RETRY = new 
Relationship.Builder().name("retry")
+.description("Failed queries that are retryable exception are 
routed to this relationship").build();
+
+private static final Set relationships;
+private static final List 

[GitHub] nifi pull request #2562: NIFI-4927 - InfluxDB Query Processor

[mans2singh]

Github user mans2singh commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2562#discussion_r177296457
  
--- Diff: 
nifi-nar-bundles/nifi-influxdb-bundle/nifi-influxdb-processors/src/test/java/org/apache/nifi/processors/influxdb/AbstractITInfluxDB.java
 ---
@@ -36,14 +36,7 @@
 
 protected void initInfluxDB() throws InterruptedException, Exception {
 influxDB = InfluxDBFactory.connect(dbUrl,user,password);
-if ( influxDB.databaseExists(dbName) ) {
-QueryResult result = influxDB.query(new Query("DROP 
measurement water", dbName));
-checkError(result);
-result = influxDB.query(new Query("DROP measurement testm", 
dbName));
-checkError(result);
-result = influxDB.query(new Query("DROP database " + dbName, 
dbName));
-Thread.sleep(1000);
-}
+cleanUpDatabase();
--- End diff --

I call the cleanup in setup as a precaution so that if there is any 
conflicting/previously existing data in the test database, it is removed and 
does not fail the integration test which depend on number of rows inserted.  If 
you think it is unnecessary, I can remove it.


---

[jira] [Commented] (NIFI-4927) Create InfluxDB Query Processor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4927:
--

Github user mans2singh commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2562#discussion_r177296275
  
--- Diff: 
nifi-nar-bundles/nifi-influxdb-bundle/nifi-influxdb-processors/src/main/java/org/apache/nifi/processors/influxdb/ExecuteInfluxDBQuery.java
 ---
@@ -72,6 +74,16 @@
 .sensitive(false)
 .build();
 
+public static final PropertyDescriptor INFLUX_DB_SCHEDULED_QUERY = new 
PropertyDescriptor.Builder()
+.name("influxdb-scheduled-query")
+.displayName("InfluxDB Schedued Query")
--- End diff --

Changed the attribute to INFLUX_DB_QUERY.  The description mentions that 
flow files and timed query both are allowed.


> Create InfluxDB Query Processor
> ---
>
> Key: NIFI-4927
> URL: https://issues.apache.org/jira/browse/NIFI-4927
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: 1.5.0
>Reporter: Mans Singh
>Assignee: Mans Singh
>Priority: Minor
>  Labels: measurements,, query, realtime, timeseries
>
> Create InfluxDB Query processor



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi pull request #2562: NIFI-4927 - InfluxDB Query Processor

[mans2singh]

Github user mans2singh commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2562#discussion_r177296275
  
--- Diff: 
nifi-nar-bundles/nifi-influxdb-bundle/nifi-influxdb-processors/src/main/java/org/apache/nifi/processors/influxdb/ExecuteInfluxDBQuery.java
 ---
@@ -72,6 +74,16 @@
 .sensitive(false)
 .build();
 
+public static final PropertyDescriptor INFLUX_DB_SCHEDULED_QUERY = new 
PropertyDescriptor.Builder()
+.name("influxdb-scheduled-query")
+.displayName("InfluxDB Schedued Query")
--- End diff --

Changed the attribute to INFLUX_DB_QUERY.  The description mentions that 
flow files and timed query both are allowed.


---

[jira] [Commented] (NIFI-4995) Release Apache NiFi 1.6.0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on NIFI-4995:
---

Commit bc086261dca2143a5be029ba1eca2fc0a67f58a5 in nifi's branch 
refs/heads/NIFI-4995-RC2 from [~joewitt]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=bc08626 ]

NIFI-4995-RC2 prepare for next development iteration


> Release Apache NiFi 1.6.0
> -
>
> Key: NIFI-4995
> URL: https://issues.apache.org/jira/browse/NIFI-4995
> Project: Apache NiFi
>  Issue Type: Task
>  Components: Tools and Build
>Affects Versions: 1.6.0
>Reporter: Joseph Witt
>Assignee: Joseph Witt
>Priority: Blocker
> Fix For: 1.6.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-4995) Release Apache NiFi 1.6.0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on NIFI-4995:
---

Commit 7b5bf265a6d180cbfafd939c82808f016932fbab in nifi's branch 
refs/heads/master from [~joewitt]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=7b5bf26 ]

NIFI-4995 updating copyright year on all notices


> Release Apache NiFi 1.6.0
> -
>
> Key: NIFI-4995
> URL: https://issues.apache.org/jira/browse/NIFI-4995
> Project: Apache NiFi
>  Issue Type: Task
>  Components: Tools and Build
>Affects Versions: 1.6.0
>Reporter: Joseph Witt
>Assignee: Joseph Witt
>Priority: Blocker
> Fix For: 1.6.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-5018) basic snap-to-grid feature for UI

[Joseph Witt (JIRA)]

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

Joseph Witt commented on NIFI-5018:
---

[~rbower] interesting idea.  Do you plan to submit a PR by chance?  Would be 
neat to try that out.  

 

> basic snap-to-grid feature for UI
> -
>
> Key: NIFI-5018
> URL: https://issues.apache.org/jira/browse/NIFI-5018
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core UI
>Affects Versions: 1.5.0
> Environment: Tested on Windows
>Reporter: Ryan Bower
>Priority: Minor
>  Labels: web-ui
>   Original Estimate: 0.25h
>  Remaining Estimate: 0.25h
>
> NiFi 1.2.0 contained the flow alignment feature, detailed:
> *NiFi 1.2.0 has a nice, new little feature that will surely please those who 
> may spend a bit of time – for some, perhaps A LOT of time – getting their 
> flow to line up perfectly. The background grid lines can help with this, but 
> the process can still be quite tedious with many components. Now there is a 
> quick, easy way.*
> **I've made a slight modification to the UI (roughly 8 lines) that results in 
> a "snap-to-grid" for selected components.  See [this 
> video|https://www.youtube.com/watch?v=S7lnBMMO6KE=youtu.be] for an 
> example of it in action.
> Target file: 
> nifi-1.5.0-src\nifi-nar-bundles\nifi-framework-bundle\nifi-framework\nifi-web\nifi-web-ui\src\main\webapp\js\nf\canvas\nf-draggable.js
> Disclaimer: I'm not experienced with javascript.  There's definitely a better 
> way to do this, code-wise, but this works and it's consistent.  
> The processor alignment is based on rounding the component's X and Y 
> coordinates during the drag event.  The result is a consistent "snap" 
> alignment.  I modified nf-draggable.js to achieve this:
> {{var nfDraggable = {}}
> {{  ...}}
> {{  if (dragSelection.empty()) }}{ 
> {{    ...}}
> {{  } else {}}
> {{    // added vars for preview outline rounding}}
> {{    var gridX = 16;}}
>  {{    var gridY = 16;}}
> {{    // update the position of the drag selection}}{{    }}
>  {{    dragSelection.attr('x', function (d) {}}
>  {{      d.x += d3.event.dx;}}
> {{      // rounding the result achieves the "snap" alignment}}
>  {{      var roundedX = Math.round(d.x/gridX) * gridX;}}
>  {{      return roundedX;}}
>  {{    })}}
>  {{      .attr('y', function (d) {}}
>  {{        d.y += d3.event.dy;}}
>  {{        var roundedY = Math.round(d.y/gridY) * gridY;}}
>  {{        return roundedY;}}
>  {{      });}}
>     ...
> {{  updateComponentPosition: function (d, delta) {}}
>      // added vars for position update.  These must match the previous two}}
>  {{    var gridX = 16;}}
>  {{    var gridY = 16;}}
> {{  // perform rounding again for the update}}
>  {{    var newPosition = {}}
>  {{    'x': (Math.round((d.position.x + delta.x)/gridX) * gridX),}}
>  {{    'y': (Math.round((d.position.y + delta.y)/gridY) * gridY),}}
>  {{  };}}
> {{ ...}}
> {{}}}
>  
> The downside of this is that components must start aligned in order to snap 
> to the same alignment on the canvas.  To remedy this, just use the 1.2.0 flow 
> alignment feature.  Note: this is only an issue for old, unaligned flows.  
> New flows and aligned flows don't have this problem.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (NIFI-5018) basic snap-to-grid feature for UI

[Ryan Bower (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-5018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Bower updated NIFI-5018:
-
Description: 
NiFi 1.2.0 contained the flow alignment feature, detailed:

*NiFi 1.2.0 has a nice, new little feature that will surely please those who 
may spend a bit of time – for some, perhaps A LOT of time – getting their flow 
to line up perfectly. The background grid lines can help with this, but the 
process can still be quite tedious with many components. Now there is a quick, 
easy way.*

**I've made a slight modification to the UI (roughly 8 lines) that results in a 
"snap-to-grid" for selected components.  See [this 
video|https://www.youtube.com/watch?v=S7lnBMMO6KE=youtu.be] for an 
example of it in action.

Target file: 

nifi-1.5.0-src\nifi-nar-bundles\nifi-framework-bundle\nifi-framework\nifi-web\nifi-web-ui\src\main\webapp\js\nf\canvas\nf-draggable.js

Disclaimer: I'm not experienced with javascript.  There's definitely a better 
way to do this, code-wise, but this works and it's consistent.  

The processor alignment is based on rounding the component's X and Y 
coordinates during the drag event.  The result is a consistent "snap" 
alignment.  I modified nf-draggable.js to achieve this:

{{var nfDraggable = {}}

{{  ...}}

{{  if (dragSelection.empty()) }}{ 

{{    ...}}

{{  } else {}}

{{    // added vars for preview outline rounding}}

{{    var gridX = 16;}}
 {{    var gridY = 16;}}

{{    // update the position of the drag selection}}{{    }}
 {{    dragSelection.attr('x', function (d) {}}
 {{      d.x += d3.event.dx;}}

{{      // rounding the result achieves the "snap" alignment}}
 {{      var roundedX = Math.round(d.x/gridX) * gridX;}}
 {{      return roundedX;}}
 {{    })}}
 {{      .attr('y', function (d) {}}
 {{        d.y += d3.event.dy;}}
 {{        var roundedY = Math.round(d.y/gridY) * gridY;}}
 {{        return roundedY;}}
 {{      });}}

    ...

{{  updateComponentPosition: function (d, delta) {}}
     // added vars for position update.  These must match the previous two}}
 {{    var gridX = 16;}}
 {{    var gridY = 16;}}

{{  // perform rounding again for the update}}
 {{    var newPosition = {}}
 {{    'x': (Math.round((d.position.x + delta.x)/gridX) * gridX),}}
 {{    'y': (Math.round((d.position.y + delta.y)/gridY) * gridY),}}
 {{  };}}

{{ ...}}

{{}}}

 

The downside of this is that components must start aligned in order to snap to 
the same alignment on the canvas.  To remedy this, just use the 1.2.0 flow 
alignment feature.  Note: this is only an issue for old, unaligned flows.  New 
flows and aligned flows don't have this problem.

 

  was:
NiFi 1.2.0 contained the flow alignment feature, detailed:

*NiFi 1.2.0 has a nice, new little feature that will surely please those who 
may spend a bit of time – for some, perhaps A LOT of time – getting their flow 
to line up perfectly. The background grid lines can help with this, but the 
process can still be quite tedious with many components. Now there is a quick, 
easy way.*

**I've made a slight modification to the UI (roughly 8 lines) that results in a 
"snap-to-grid" for selected components.  See [this 
video|https://www.youtube.com/watch?v=S7lnBMMO6KE=youtu.be] for an 
example of it in action.

Target file: 

nifi-1.5.0-src\nifi-nar-bundles\nifi-framework-bundle\nifi-framework\nifi-web\nifi-web-ui\src\main\webapp\js\nf\canvas\nf-draggable.js

Disclaimer: I'm not experienced with javascript.  There's definitely a better 
way to do this, code-wise, but this works and it's consistent.  

The processor alignment is based on rounding the component's X and Y 
coordinates during the drag event.  The result is a consistent "snap" 
alignment.  I modified nf-draggable.js to achieve this:

{{var nfDraggable = {}}

{{  ...}}{\{    }}

{{  if (dragSelection.empty()) }}{\{{}}\{{    }}

{{    ...}}{\{    }}

{{  } else {}}

{{    // added vars for preview outline rounding}}

{{    var gridX = 16;}}
 {{    var gridY = 16;}}

{{    // update the position of the drag selection}}{{    }}
 {{    dragSelection.attr('x', function (d) {}}
 {{      d.x += d3.event.dx;}}

{{      // rounding the result achieves the "snap" alignment}}
 {{      var roundedX = Math.round(d.x/gridX) * gridX;}}
 {{      return roundedX;}}
 {{    })}}
 {{      .attr('y', function (d) {}}
 {{        d.y += d3.event.dy;}}
 {{        var roundedY = Math.round(d.y/gridY) * gridY;}}
 {{        return roundedY;}}
 {{      });}}

  ...

{{  updateComponentPosition: function (d, delta) {}}
    // added vars for position update.  These must match the previous two}}
 {{    var gridX = 16;}}
 {{    var gridY = 16;}}

{{  // perform rounding again for the update}}
 {{    var newPosition = {}}
 {{    'x': (Math.round((d.position.x + delta.x)/gridX) * gridX),}}
 {{    'y': (Math.round((d.position.y + delta.y)/gridY) * gridY),}}
 {{  };}}

{{ ...}}

{{}}}

 

The downside of this is 

[jira] [Updated] (NIFI-5018) basic snap-to-grid feature for UI

[Ryan Bower (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-5018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Bower updated NIFI-5018:
-
Description: 
NiFi 1.2.0 contained the flow alignment feature, detailed:

*NiFi 1.2.0 has a nice, new little feature that will surely please those who 
may spend a bit of time – for some, perhaps A LOT of time – getting their flow 
to line up perfectly. The background grid lines can help with this, but the 
process can still be quite tedious with many components. Now there is a quick, 
easy way.*

**I've made a slight modification to the UI (roughly 8 lines) that results in a 
"snap-to-grid" for selected components.  See [this 
video|https://www.youtube.com/watch?v=S7lnBMMO6KE=youtu.be] for an 
example of it in action.

Target file: 

nifi-1.5.0-src\nifi-nar-bundles\nifi-framework-bundle\nifi-framework\nifi-web\nifi-web-ui\src\main\webapp\js\nf\canvas\nf-draggable.js

Disclaimer: I'm not experienced with javascript.  There's definitely a better 
way to do this, code-wise, but this works and it's consistent.  

The processor alignment is based on rounding the component's X and Y 
coordinates during the drag event.  The result is a consistent "snap" 
alignment.  I modified nf-draggable.js to achieve this:

{{var nfDraggable = {}}

{{  ...}}{\{    }}

{{  if (dragSelection.empty()) }}{\{{}}\{{    }}

{{    ...}}{\{    }}

{{  } else {}}

{{    // added vars for preview outline rounding}}

{{    var gridX = 16;}}
 {{    var gridY = 16;}}

{{    // update the position of the drag selection}}{{    }}
 {{    dragSelection.attr('x', function (d) {}}
 {{      d.x += d3.event.dx;}}

{{      // rounding the result achieves the "snap" alignment}}
 {{      var roundedX = Math.round(d.x/gridX) * gridX;}}
 {{      return roundedX;}}
 {{    })}}
 {{      .attr('y', function (d) {}}
 {{        d.y += d3.event.dy;}}
 {{        var roundedY = Math.round(d.y/gridY) * gridY;}}
 {{        return roundedY;}}
 {{      });}}

  ...

{{  updateComponentPosition: function (d, delta) {}}
    // added vars for position update.  These must match the previous two}}
 {{    var gridX = 16;}}
 {{    var gridY = 16;}}

{{  // perform rounding again for the update}}
 {{    var newPosition = {}}
 {{    'x': (Math.round((d.position.x + delta.x)/gridX) * gridX),}}
 {{    'y': (Math.round((d.position.y + delta.y)/gridY) * gridY),}}
 {{  };}}

{{ ...}}

{{}}}

 

The downside of this is that components must start aligned in order to snap to 
the same alignment on the canvas.  To remedy this, just use the 1.2.0 flow 
alignment feature.  Note: this is only an issue for old, unaligned flows.  New 
flows and aligned flows don't have this problem.

 

  was:
NiFi 1.2.0 contained the flow alignment feature, detailed:

*NiFi 1.2.0 has a nice, new little feature that will surely please those who 
may spend a bit of time – for some, perhaps A LOT of time – getting their flow 
to line up perfectly. The background grid lines can help with this, but the 
process can still be quite tedious with many components. Now there is a quick, 
easy way.*

**I've made a slight modification to the UI (roughly 8 lines) that results in a 
"snap-to-grid" for selected components.  See [this 
video|https://www.youtube.com/watch?v=S7lnBMMO6KE=youtu.be] for an 
example of it in action.

Target file: 

nifi-1.5.0-src\nifi-nar-bundles\nifi-framework-bundle\nifi-framework\nifi-web\nifi-web-ui\src\main\webapp\js\nf\canvas\nf-draggable.js

Disclaimer: I'm not experienced with javascript.  There's definitely a better 
way to do this, code-wise, but this works and it's consistent.  

The processor alignment is based on rounding the component's X and Y 
coordinates during the drag event.  The result is a consistent "snap" 
alignment.  I modified nf-draggable.js to achieve this:

{{var nfDraggable = {}}

{{  ...}}{\{    }}

{{  if (dragSelection.empty()) }}{\{{}}\{{    }}

{{    ...}}{\{    }}

{{  } else {}}

{{    // added vars for preview outline rounding}}

{{    var gridX = 16;}}
 {{    var gridY = 16;}}

{{    // update the position of the drag selection}}{{    }}
 {{    dragSelection.attr('x', function (d) {}}
 {{      d.x += d3.event.dx;}}

{{      // rounding the result achieves the "snap" alignment}}
 {{      var roundedX = Math.round(d.x/gridX) * gridX;}}
 {{      return roundedX;}}
 {{    })}}
 {{      .attr('y', function (d) {}}
 {{        d.y += d3.event.dy;}}
 {{        var roundedY = Math.round(d.y/gridY) * gridY;}}
 {{        return roundedY;}}
 {{      });}}

{\{  }}}

  ...

{{  updateComponentPosition: function (d, delta) {}}
 \{{   // added vars for position update.  These must match the previous two}}
 {{    var gridX = 16;}}
 {{    var gridY = 16;}}
 \{{     }}

{{  // perform rounding again for the update}}
 {{    var newPosition = {}}
 {{    'x': (Math.round((d.position.x + delta.x)/gridX) * gridX),}}
 {{    'y': (Math.round((d.position.y + delta.y)/gridY) * gridY),}}
 {{  

[jira] [Created] (NIFI-5018) basic snap-to-grid feature for UI

[Ryan Bower (JIRA)]

Ryan Bower created NIFI-5018:


 Summary: basic snap-to-grid feature for UI
 Key: NIFI-5018
 URL: https://issues.apache.org/jira/browse/NIFI-5018
 Project: Apache NiFi
  Issue Type: Improvement
  Components: Core UI
Affects Versions: 1.5.0
 Environment: Tested on Windows
Reporter: Ryan Bower


NiFi 1.2.0 contained the flow alignment feature, detailed:

*NiFi 1.2.0 has a nice, new little feature that will surely please those who 
may spend a bit of time – for some, perhaps A LOT of time – getting their flow 
to line up perfectly. The background grid lines can help with this, but the 
process can still be quite tedious with many components. Now there is a quick, 
easy way.*

**I've made a slight modification to the UI (roughly 8 lines) that results in a 
"snap-to-grid" for selected components.  See [this 
video|https://www.youtube.com/watch?v=S7lnBMMO6KE=youtu.be] for an 
example of it in action.

Target file: 

nifi-1.5.0-src\nifi-nar-bundles\nifi-framework-bundle\nifi-framework\nifi-web\nifi-web-ui\src\main\webapp\js\nf\canvas\nf-draggable.js

Disclaimer: I'm not experienced with javascript.  There's definitely a better 
way to do this, code-wise, but this works and it's consistent.  

The processor alignment is based on rounding the component's X and Y 
coordinates during the drag event.  The result is a consistent "snap" 
alignment.  I modified nf-draggable.js to achieve this:

{{var nfDraggable = {}}

{{  ...}}{{    }}

{{  if (dragSelection.empty()) }}{{{}}{{    }}

{{    ...}}{{    }}

{{  } else {}}

{{    // added vars for preview outline rounding}}

{{    var gridX = 16;}}
{{    var gridY = 16;}}


{{    // update the position of the drag selection}}{{    }}
{{    dragSelection.attr('x', function (d) {}}
{{      d.x += d3.event.dx;}}

{{      // rounding the result achieves the "snap" alignment}}
{{      var roundedX = Math.round(d.x/gridX) * gridX;}}
{{      return roundedX;}}
{{    })}}
{{      .attr('y', function (d) {}}
{{        d.y += d3.event.dy;}}
{{        roundedY = Math.round(d.y/gridY) * gridY;}}
{{        return roundedY;}}
{{      });}}

{{  }}}

  ...

{{  updateComponentPosition: function (d, delta) {}}
{{   // added vars for position update.  These must match the previous two}}
{{    var gridX = 16;}}
{{    var gridY = 16;}}
{{     }}

{{  // perform rounding again for the update}}
{{    var newPosition = {}}
{{    'x': (Math.round((d.position.x + delta.x)/gridX) * gridX),}}
{{    'y': (Math.round((d.position.y + delta.y)/gridY) * gridY),}}
{{  };}}

{{ ...}}

{{}}}

 

The downside of this is that components must start aligned in order to snap to 
the same alignment on the canvas.  To remedy this, just use the 1.2.0 flow 
alignment feature.  Note: this is only an issue for old, unaligned flows.  New 
flows and aligned flows don't have this problem.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (NIFI-5018) basic snap-to-grid feature for UI

[Ryan Bower (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-5018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Bower updated NIFI-5018:
-
Description: 
NiFi 1.2.0 contained the flow alignment feature, detailed:

*NiFi 1.2.0 has a nice, new little feature that will surely please those who 
may spend a bit of time – for some, perhaps A LOT of time – getting their flow 
to line up perfectly. The background grid lines can help with this, but the 
process can still be quite tedious with many components. Now there is a quick, 
easy way.*

**I've made a slight modification to the UI (roughly 8 lines) that results in a 
"snap-to-grid" for selected components.  See [this 
video|https://www.youtube.com/watch?v=S7lnBMMO6KE=youtu.be] for an 
example of it in action.

Target file: 

nifi-1.5.0-src\nifi-nar-bundles\nifi-framework-bundle\nifi-framework\nifi-web\nifi-web-ui\src\main\webapp\js\nf\canvas\nf-draggable.js

Disclaimer: I'm not experienced with javascript.  There's definitely a better 
way to do this, code-wise, but this works and it's consistent.  

The processor alignment is based on rounding the component's X and Y 
coordinates during the drag event.  The result is a consistent "snap" 
alignment.  I modified nf-draggable.js to achieve this:

{{var nfDraggable = {}}

{{  ...}}{\{    }}

{{  if (dragSelection.empty()) }}{\{{}}\{{    }}

{{    ...}}{\{    }}

{{  } else {}}

{{    // added vars for preview outline rounding}}

{{    var gridX = 16;}}
 {{    var gridY = 16;}}

{{    // update the position of the drag selection}}{{    }}
 {{    dragSelection.attr('x', function (d) {}}
 {{      d.x += d3.event.dx;}}

{{      // rounding the result achieves the "snap" alignment}}
 {{      var roundedX = Math.round(d.x/gridX) * gridX;}}
 {{      return roundedX;}}
 {{    })}}
 {{      .attr('y', function (d) {}}
 {{        d.y += d3.event.dy;}}
 {{        var roundedY = Math.round(d.y/gridY) * gridY;}}
 {{        return roundedY;}}
 {{      });}}

{\{  }}}

  ...

{{  updateComponentPosition: function (d, delta) {}}
 \{{   // added vars for position update.  These must match the previous two}}
 {{    var gridX = 16;}}
 {{    var gridY = 16;}}
 \{{     }}

{{  // perform rounding again for the update}}
 {{    var newPosition = {}}
 {{    'x': (Math.round((d.position.x + delta.x)/gridX) * gridX),}}
 {{    'y': (Math.round((d.position.y + delta.y)/gridY) * gridY),}}
 {{  };}}

{{ ...}}

{{}}}

 

The downside of this is that components must start aligned in order to snap to 
the same alignment on the canvas.  To remedy this, just use the 1.2.0 flow 
alignment feature.  Note: this is only an issue for old, unaligned flows.  New 
flows and aligned flows don't have this problem.

 

  was:
NiFi 1.2.0 contained the flow alignment feature, detailed:

*NiFi 1.2.0 has a nice, new little feature that will surely please those who 
may spend a bit of time – for some, perhaps A LOT of time – getting their flow 
to line up perfectly. The background grid lines can help with this, but the 
process can still be quite tedious with many components. Now there is a quick, 
easy way.*

**I've made a slight modification to the UI (roughly 8 lines) that results in a 
"snap-to-grid" for selected components.  See [this 
video|https://www.youtube.com/watch?v=S7lnBMMO6KE=youtu.be] for an 
example of it in action.

Target file: 

nifi-1.5.0-src\nifi-nar-bundles\nifi-framework-bundle\nifi-framework\nifi-web\nifi-web-ui\src\main\webapp\js\nf\canvas\nf-draggable.js

Disclaimer: I'm not experienced with javascript.  There's definitely a better 
way to do this, code-wise, but this works and it's consistent.  

The processor alignment is based on rounding the component's X and Y 
coordinates during the drag event.  The result is a consistent "snap" 
alignment.  I modified nf-draggable.js to achieve this:

{{var nfDraggable = {}}

{{  ...}}{{    }}

{{  if (dragSelection.empty()) }}{{{}}{{    }}

{{    ...}}{{    }}

{{  } else {}}

{{    // added vars for preview outline rounding}}

{{    var gridX = 16;}}
{{    var gridY = 16;}}


{{    // update the position of the drag selection}}{{    }}
{{    dragSelection.attr('x', function (d) {}}
{{      d.x += d3.event.dx;}}

{{      // rounding the result achieves the "snap" alignment}}
{{      var roundedX = Math.round(d.x/gridX) * gridX;}}
{{      return roundedX;}}
{{    })}}
{{      .attr('y', function (d) {}}
{{        d.y += d3.event.dy;}}
{{        roundedY = Math.round(d.y/gridY) * gridY;}}
{{        return roundedY;}}
{{      });}}

{{  }}}

  ...

{{  updateComponentPosition: function (d, delta) {}}
{{   // added vars for position update.  These must match the previous two}}
{{    var gridX = 16;}}
{{    var gridY = 16;}}
{{     }}

{{  // perform rounding again for the update}}
{{    var newPosition = {}}
{{    'x': (Math.round((d.position.x + delta.x)/gridX) * gridX),}}
{{    'y': (Math.round((d.position.y + delta.y)/gridY) * gridY),}}
{{  };}}

[jira] [Updated] (NIFI-5017) ConvertExcelToCSVProcessor should Support Expression Language for Number of Rows to Skip and Columns To Skip

[Arun A K (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Arun A K updated NIFI-5017:
---
Component/s: (was: SDLC)
 Extensions

> ConvertExcelToCSVProcessor  should Support Expression Language for Number of 
> Rows to Skip and Columns To Skip
> -
>
> Key: NIFI-5017
> URL: https://issues.apache.org/jira/browse/NIFI-5017
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: 1.5.0
>Reporter: Arun A K
>Priority: Minor
>
> The ConvertExcelToCSVProcessor should support expression language for fields 
> "Number of Rows to Skip" and "Columns To Skip". These two could be a 
> precomputed attribute or looked up value and need to be configurable via EL. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (NIFI-5017) ConvertExcelToCSVProcessor should Support Expression Language for Number of Rows to Skip and Columns To Skip

[Arun A K (JIRA)]

Arun A K created NIFI-5017:
--

 Summary: ConvertExcelToCSVProcessor  should Support Expression 
Language for Number of Rows to Skip and Columns To Skip
 Key: NIFI-5017
 URL: https://issues.apache.org/jira/browse/NIFI-5017
 Project: Apache NiFi
  Issue Type: Improvement
  Components: SDLC
Affects Versions: 1.5.0
Reporter: Arun A K


The ConvertExcelToCSVProcessor should support expression language for fields 
"Number of Rows to Skip" and "Columns To Skip". These two could be a 
precomputed attribute or looked up value and need to be configurable via EL. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (NIFIREG-158) Should be able to retrieve a flow by id without the bucket it

[Bryan Bende (JIRA)]

Bryan Bende created NIFIREG-158:
---

 Summary: Should be able to retrieve a flow by id without the 
bucket it
 Key: NIFIREG-158
 URL: https://issues.apache.org/jira/browse/NIFIREG-158
 Project: NiFi Registry
  Issue Type: Improvement
Affects Versions: 0.1.0
Reporter: Bryan Bende
Assignee: Bryan Bende


Currently all the flow end-points are nested under a bucket, like:
{code:java}
/buckets/{bucketId}/flows/{flowId}
/buckets/{bucketId}/flows/{flowId}/versions/{version}{code}
The flow identifier is unique across all buckets, so once the flow is create we 
should be able to support end-points without the bucket id:
{code:java}
/flows/{flowId}
/flows/{flowId}/versions/{version}

{code}
We still need to look at the bucket and authorize the bucket id when secure, 
but we'll have the bucket id from retrieving the flow.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFIREG-157) VersionedPropertyDescriptor should indicate if property is sensitive or not

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFIREG-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414476#comment-16414476
 ] 

ASF GitHub Bot commented on NIFIREG-157:


GitHub user bbende opened a pull request:

https://github.com/apache/nifi-registry/pull/107

NIFIREG-157 Adding boolean to VersionedPropertyDescriptor to indicate…

… if sensitive or not

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bbende/nifi-registry NIFIREG-157

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi-registry/pull/107.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #107


commit 4cf4ab5efdff676fe9fb93a0876fd4895d23b2d9
Author: Bryan Bende 
Date:   2018-03-26T20:21:46Z

NIFIREG-157 Adding boolean to VersionedPropertyDescriptor to indicate if 
sensitive or not




> VersionedPropertyDescriptor should indicate if property is sensitive or not
> ---
>
> Key: NIFIREG-157
> URL: https://issues.apache.org/jira/browse/NIFIREG-157
> Project: NiFi Registry
>  Issue Type: Improvement
>Affects Versions: 0.1.0
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Minor
> Fix For: 0.2.0
>
>
> VersionedPropertyDescriptor should indicate if the property is sensitive or 
> not so that consumers of a VersionedFlow can identify which properties were 
> sensitive.
> NiFi would need to be updated to populate this field in 
> NiFiRegistryFlowMapper once this boolean was available.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi-registry pull request #107: NIFIREG-157 Adding boolean to VersionedProp...

[bbende]

GitHub user bbende opened a pull request:

https://github.com/apache/nifi-registry/pull/107

NIFIREG-157 Adding boolean to VersionedPropertyDescriptor to indicate…

… if sensitive or not

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bbende/nifi-registry NIFIREG-157

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi-registry/pull/107.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #107


commit 4cf4ab5efdff676fe9fb93a0876fd4895d23b2d9
Author: Bryan Bende 
Date:   2018-03-26T20:21:46Z

NIFIREG-157 Adding boolean to VersionedPropertyDescriptor to indicate if 
sensitive or not




---

[jira] [Created] (NIFIREG-157) VersionedPropertyDescriptor should indicate if property is sensitive or not

[Bryan Bende (JIRA)]

Bryan Bende created NIFIREG-157:
---

 Summary: VersionedPropertyDescriptor should indicate if property 
is sensitive or not
 Key: NIFIREG-157
 URL: https://issues.apache.org/jira/browse/NIFIREG-157
 Project: NiFi Registry
  Issue Type: Improvement
Affects Versions: 0.1.0
Reporter: Bryan Bende
Assignee: Bryan Bende
 Fix For: 0.2.0


VersionedPropertyDescriptor should indicate if the property is sensitive or not 
so that consumers of a VersionedFlow can identify which properties were 
sensitive.

NiFi would need to be updated to populate this field in NiFiRegistryFlowMapper 
once this boolean was available.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (NIFI-4882) CSVRecordReader should utilize specified date/time/timestamp format at its convertSimpleIfPossible method

[Bryan Bende (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-4882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Bende updated NIFI-4882:
--
Fix Version/s: (was: 1.7.0)
   1.6.0

> CSVRecordReader should utilize specified date/time/timestamp format at its 
> convertSimpleIfPossible method
> -
>
> Key: NIFI-4882
> URL: https://issues.apache.org/jira/browse/NIFI-4882
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Koji Kawamura
>Assignee: Derek Straka
>Priority: Major
> Fix For: 1.6.0
>
>
> CSVRecordReader.convertSimpleIfPossible method is used by ValidateRecord. The 
> method does not coerce values to the target schema field type if the raw 
> string representation in the input CSV file is not compatible.
> The type compatibility check is implemented as follows. But it does not use 
> user specified date/time/timestamp format:
> {code}
> // This will return 'false' for input '01/01/1900' when user 
> specified custom format 'MM/dd/'
> if (DataTypeUtils.isCompatibleDataType(trimmed, dataType)) {
> // The LAZY_DATE_FORMAT should be used to check 
> compatibility, too.
> return DataTypeUtils.convertType(trimmed, dataType, 
> LAZY_DATE_FORMAT, LAZY_TIME_FORMAT, LAZY_TIMESTAMP_FORMAT, fieldName);
> } else {
> return value;
> }
> {code}
> If input date strings have different format than the default format 
> '-MM-dd', then ValidateRecord processor can not validate input records.
> JacksonCSVRecordReader has the identical methods with CSVRecordReader. Those 
> classes should have an abstract class.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (NIFI-4989) PutMongo cannot specify nested fields or multiple lookup keys

[Bryan Bende (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-4989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Bende updated NIFI-4989:
--
Fix Version/s: (was: 1.7.0)
   1.6.0

> PutMongo cannot specify nested fields or multiple lookup keys
> -
>
> Key: NIFI-4989
> URL: https://issues.apache.org/jira/browse/NIFI-4989
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Mike Thomsen
>Assignee: Mike Thomsen
>Priority: Major
> Fix For: 1.6.0
>
>
> From the user mailing list:
> {quote}{color:#22}I am using PutMongo processor to update documents in a 
> mongoDB collection.{color}
> {color:#22}I would like to specify nested field and multiple key in the 
> update Key.{color}
> {color:#22}For exemple :{color}
> {color:#22}- my mongodb documents are {"nom":"HAMEL", 
> "prenom":"Yves",{color}
> {color:#22}"ids":\{"idSoc":"1234", "idInterne":"788"}}{color}
> {color:#22}- I would'd like to set update query key to something like 
> {"ids.idSoc" ,{color}
> {color:#22}"nom"}{color}
> {color:#22}- this would means that I update document with ids.idSoc and 
> nom equals to{color}
> {color:#22}my mew document.{color}
> {quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (NIFI-4631) Improve ListFile performance (using walkFileTree)

[Bryan Bende (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-4631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Bende updated NIFI-4631:
--
Fix Version/s: (was: 1.7.0)
   1.6.0

> Improve ListFile performance (using walkFileTree)
> -
>
> Key: NIFI-4631
> URL: https://issues.apache.org/jira/browse/NIFI-4631
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 1.4.0
>Reporter: Jeroen Dries
>Priority: Major
>  Labels: performance
> Fix For: 1.6.0
>
>
> The listfile processor is quite slow when recursing through large directory 
> structures. (In my case an NFS mounted directory, on Linux.)
> A possible fix would be to use the Files.walkFileTree method, which is 
> reported to be faster.
> Another option is mentioned in NIFI-4039



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (NIFI-5011) Test failure in TestFileSystemRepository causing travis build to be unstable

[Bryan Bende (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-5011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Bende updated NIFI-5011:
--
Fix Version/s: (was: 1.7.0)
   1.6.0

> Test failure in TestFileSystemRepository causing travis build to be unstable
> 
>
> Key: NIFI-5011
> URL: https://issues.apache.org/jira/browse/NIFI-5011
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Critical
> Fix For: 1.6.0
>
>
> We see the following test failure intermittently in travis:
> [ERROR] Tests run: 32, Failures: 0, Errors: 1, Skipped: 1, Time elapsed: 
> 13.143 s <<< FAILURE! - in 
> org.apache.nifi.controller.repository.TestFileSystemRepository [ERROR] 
> testMinimalArchiveCleanupIntervalHonoredAndLogged(org.apache.nifi.controller.repository.TestFileSystemRepository)
>  Time elapsed: 0.211 s <<< ERROR! java.util.ConcurrentModificationException 
> at 
> org.apache.nifi.controller.repository.TestFileSystemRepository.testMinimalArchiveCleanupIntervalHonoredAndLogged(TestFileSystemRepository.java:151)
>  
> This appears to be a threading bug, giving that it's a 
> ConcurrentModificationException that happens sporadically. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (NIFI-5013) NiFi Standard Processors should build a test jar to reduce duplication

[Bryan Bende (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-5013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Bende updated NIFI-5013:
--
Fix Version/s: (was: 1.7.0)
   1.6.0

> NiFi Standard Processors should build a test jar to reduce duplication
> --
>
> Key: NIFI-5013
> URL: https://issues.apache.org/jira/browse/NIFI-5013
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Otto Fowler
>Assignee: Otto Fowler
>Priority: Major
> Fix For: 1.6.0
>
>
> There are some classes, notably TestServer, which are in the nifi standard 
> processors jar which could be used by other processors, either in the project 
> ( already 2 or 3 copies ) or in 3rd party processor/controller projects.
> [link Apache 
> Maven|https://maven.apache.org/plugins/maven-jar-plugin/examples/create-test-jar.html]
>  details how to handle this case in two ways.
>  
>  #  create a test-jar from the project
>  # create a new module to hold shared testing code and scope:test include it
> While #2 is the preferred way, nifi should support #1 in the interim, until 
> some discussion on the location and structure of the test module(s) and the 
> classes that should be moved to them happens.  The scope there will be quite 
> a bit larger.
>  
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (NIFI-4743) Suppress Nulls for PutElasticsearchHttpRecord

[Bryan Bende (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-4743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Bende updated NIFI-4743:
--
Fix Version/s: (was: 1.7.0)
   1.6.0

> Suppress Nulls for PutElasticsearchHttpRecord
> -
>
> Key: NIFI-4743
> URL: https://issues.apache.org/jira/browse/NIFI-4743
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Robert Bruno
>Assignee: Mike Thomsen
>Priority: Minor
> Fix For: 1.6.0
>
> Attachments: NullSuppression.java, PutElasticsearchHttpRecord.java
>
>
> Would be useful for PutElasticsearchHttpRecord to allow you to suppress NULL 
> values in the JSON that is inserted into ES much like the JsonRecordSetWriter 
> allows you to do.  Perhaps PutElasticsearchHttpRecord could some how make use 
> of JsonRecordSetWriter so it would inherit this functionality.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-4977) PutSyslog should support Expression Language for it's Sender properties

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4977:
--

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/2547
  
Awesome, thanks @bbende. I appreciate the review


> PutSyslog should support Expression Language for it's Sender properties
> ---
>
> Key: NIFI-4977
> URL: https://issues.apache.org/jira/browse/NIFI-4977
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Joseph Percivall
>Assignee: Joseph Percivall
>Priority: Minor
> Fix For: 1.6.0
>
>
> As part of the continued effort to add access to the variable registry to 
> processors, the PutSyslog processor should expose expression language to it's 
> sender properties. These properties control where and how the processor sends 
> to. 
> This update should better align PutSyslog with the other PutX processors 
> which support EL on the sender properties (Slack, TCP, UDP).
> These properties are not evaluated per FlowFile and shouldn't be expected to 
> change between onTriggers (since the sender pool is shared) so it will need 
> to be documented as such that the 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi issue #2547: NIFI-4977 Adding expression language support to the Sender...

[JPercivall]

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/2547
  
Awesome, thanks @bbende. I appreciate the review


---

[jira] [Commented] (NIFI-4977) PutSyslog should support Expression Language for it's Sender properties

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on NIFI-4977:
---

Commit 56ad14ad1eb5bc1d716f6d2664618a07fd049e07 in nifi's branch 
refs/heads/master from Joe Percivall
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=56ad14a ]

NIFI-4977 Adding expression language support to the Sender properties of 
PutSyslog

This closes #2547.

Signed-off-by: Bryan Bende 


> PutSyslog should support Expression Language for it's Sender properties
> ---
>
> Key: NIFI-4977
> URL: https://issues.apache.org/jira/browse/NIFI-4977
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Joseph Percivall
>Assignee: Joseph Percivall
>Priority: Minor
> Fix For: 1.6.0
>
>
> As part of the continued effort to add access to the variable registry to 
> processors, the PutSyslog processor should expose expression language to it's 
> sender properties. These properties control where and how the processor sends 
> to. 
> This update should better align PutSyslog with the other PutX processors 
> which support EL on the sender properties (Slack, TCP, UDP).
> These properties are not evaluated per FlowFile and shouldn't be expected to 
> change between onTriggers (since the sender pool is shared) so it will need 
> to be documented as such that the 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-4977) PutSyslog should support Expression Language for it's Sender properties

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4977:
--

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/2547


> PutSyslog should support Expression Language for it's Sender properties
> ---
>
> Key: NIFI-4977
> URL: https://issues.apache.org/jira/browse/NIFI-4977
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Joseph Percivall
>Assignee: Joseph Percivall
>Priority: Minor
> Fix For: 1.6.0
>
>
> As part of the continued effort to add access to the variable registry to 
> processors, the PutSyslog processor should expose expression language to it's 
> sender properties. These properties control where and how the processor sends 
> to. 
> This update should better align PutSyslog with the other PutX processors 
> which support EL on the sender properties (Slack, TCP, UDP).
> These properties are not evaluated per FlowFile and shouldn't be expected to 
> change between onTriggers (since the sender pool is shared) so it will need 
> to be documented as such that the 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (NIFI-4977) PutSyslog should support Expression Language for it's Sender properties

[Bryan Bende (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-4977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Bende updated NIFI-4977:
--
   Resolution: Fixed
Fix Version/s: 1.6.0
   Status: Resolved  (was: Patch Available)

> PutSyslog should support Expression Language for it's Sender properties
> ---
>
> Key: NIFI-4977
> URL: https://issues.apache.org/jira/browse/NIFI-4977
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Joseph Percivall
>Assignee: Joseph Percivall
>Priority: Minor
> Fix For: 1.6.0
>
>
> As part of the continued effort to add access to the variable registry to 
> processors, the PutSyslog processor should expose expression language to it's 
> sender properties. These properties control where and how the processor sends 
> to. 
> This update should better align PutSyslog with the other PutX processors 
> which support EL on the sender properties (Slack, TCP, UDP).
> These properties are not evaluated per FlowFile and shouldn't be expected to 
> change between onTriggers (since the sender pool is shared) so it will need 
> to be documented as such that the 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi pull request #2547: NIFI-4977 Adding expression language support to the...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/2547


---

[jira] [Commented] (NIFI-4977) PutSyslog should support Expression Language for it's Sender properties

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4977:
--

Github user bbende commented on the issue:

https://github.com/apache/nifi/pull/2547
  
Thanks, looks good, will merge


> PutSyslog should support Expression Language for it's Sender properties
> ---
>
> Key: NIFI-4977
> URL: https://issues.apache.org/jira/browse/NIFI-4977
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Joseph Percivall
>Assignee: Joseph Percivall
>Priority: Minor
>
> As part of the continued effort to add access to the variable registry to 
> processors, the PutSyslog processor should expose expression language to it's 
> sender properties. These properties control where and how the processor sends 
> to. 
> This update should better align PutSyslog with the other PutX processors 
> which support EL on the sender properties (Slack, TCP, UDP).
> These properties are not evaluated per FlowFile and shouldn't be expected to 
> change between onTriggers (since the sender pool is shared) so it will need 
> to be documented as such that the 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi issue #2547: NIFI-4977 Adding expression language support to the Sender...

[bbende]

Github user bbende commented on the issue:

https://github.com/apache/nifi/pull/2547
  
Thanks, looks good, will merge


---

[jira] [Created] (NIFI-5016) UI - Variables view with long processor names

[Pierre Villard (JIRA)]

Pierre Villard created NIFI-5016:


 Summary: UI - Variables view with long processor names
 Key: NIFI-5016
 URL: https://issues.apache.org/jira/browse/NIFI-5016
 Project: Apache NiFi
  Issue Type: Improvement
  Components: Core UI
Affects Versions: 1.5.0
 Environment: Firefox 59.0.1
Reporter: Pierre Villard
 Attachments: Screen Shot 2018-03-26 at 9.28.30 PM.png, Screen Shot 
2018-03-26 at 9.28.37 PM.png

In case you have processors with very long names the diplay of the referencing 
components in the variables view of a process group is not perfect (see 
attached pictures)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (NIFI-4325) Create a new ElasticSearch processor that supports the JSON DSL

[Joseph Percivall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-4325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joseph Percivall resolved NIFI-4325.

   Resolution: Fixed
Fix Version/s: 1.6.0

> Create a new ElasticSearch processor that supports the JSON DSL
> ---
>
> Key: NIFI-4325
> URL: https://issues.apache.org/jira/browse/NIFI-4325
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Mike Thomsen
>Assignee: Mike Thomsen
>Priority: Minor
> Fix For: 1.6.0
>
>
> The existing ElasticSearch processors use the Lucene-style syntax for 
> querying, not the JSON DSL. A new processor is needed that can take a full 
> JSON query and execute it. It should also support aggregation queries in this 
> syntax. A user needs to be able to take a query as-is from Kibana and drop it 
> into NiFi and have it just run.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (NIFI-4325) Create a new ElasticSearch processor that supports the JSON DSL

[Joseph Percivall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-4325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joseph Percivall updated NIFI-4325:
---
Issue Type: New Feature  (was: Improvement)

> Create a new ElasticSearch processor that supports the JSON DSL
> ---
>
> Key: NIFI-4325
> URL: https://issues.apache.org/jira/browse/NIFI-4325
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Mike Thomsen
>Assignee: Mike Thomsen
>Priority: Minor
> Fix For: 1.6.0
>
>
> The existing ElasticSearch processors use the Lucene-style syntax for 
> querying, not the JSON DSL. A new processor is needed that can take a full 
> JSON query and execute it. It should also support aggregation queries in this 
> syntax. A user needs to be able to take a query as-is from Kibana and drop it 
> into NiFi and have it just run.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (NIFI-4325) Create a new ElasticSearch processor that supports the JSON DSL

[Joseph Percivall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-4325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joseph Percivall reassigned NIFI-4325:
--

Assignee: Mike Thomsen

> Create a new ElasticSearch processor that supports the JSON DSL
> ---
>
> Key: NIFI-4325
> URL: https://issues.apache.org/jira/browse/NIFI-4325
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Mike Thomsen
>Assignee: Mike Thomsen
>Priority: Minor
>
> The existing ElasticSearch processors use the Lucene-style syntax for 
> querying, not the JSON DSL. A new processor is needed that can take a full 
> JSON query and execute it. It should also support aggregation queries in this 
> syntax. A user needs to be able to take a query as-is from Kibana and drop it 
> into NiFi and have it just run.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-4325) Create a new ElasticSearch processor that supports the JSON DSL

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4325:
--

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/2113


> Create a new ElasticSearch processor that supports the JSON DSL
> ---
>
> Key: NIFI-4325
> URL: https://issues.apache.org/jira/browse/NIFI-4325
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Mike Thomsen
>Priority: Minor
>
> The existing ElasticSearch processors use the Lucene-style syntax for 
> querying, not the JSON DSL. A new processor is needed that can take a full 
> JSON query and execute it. It should also support aggregation queries in this 
> syntax. A user needs to be able to take a query as-is from Kibana and drop it 
> into NiFi and have it just run.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-4325) Create a new ElasticSearch processor that supports the JSON DSL

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on NIFI-4325:
---

Commit aa947e4d3e0e54877d24683fefa5da651332c433 in nifi's branch 
refs/heads/master from [~mike.thomsen]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=aa947e4 ]

NIFI-4325 Added new processor that uses the JSON DSL.

NIFI-4325 Cleaned up how ElasticSearch client service builds SSLContext, added 
query attribute to flowfiles and other changes requested in a code review.

This closes #2113.

Signed-off-by: Joe Percivall 


> Create a new ElasticSearch processor that supports the JSON DSL
> ---
>
> Key: NIFI-4325
> URL: https://issues.apache.org/jira/browse/NIFI-4325
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Mike Thomsen
>Priority: Minor
>
> The existing ElasticSearch processors use the Lucene-style syntax for 
> querying, not the JSON DSL. A new processor is needed that can take a full 
> JSON query and execute it. It should also support aggregation queries in this 
> syntax. A user needs to be able to take a query as-is from Kibana and drop it 
> into NiFi and have it just run.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-4325) Create a new ElasticSearch processor that supports the JSON DSL

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on NIFI-4325:
---

Commit aa947e4d3e0e54877d24683fefa5da651332c433 in nifi's branch 
refs/heads/master from [~mike.thomsen]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=aa947e4 ]

NIFI-4325 Added new processor that uses the JSON DSL.

NIFI-4325 Cleaned up how ElasticSearch client service builds SSLContext, added 
query attribute to flowfiles and other changes requested in a code review.

This closes #2113.

Signed-off-by: Joe Percivall 


> Create a new ElasticSearch processor that supports the JSON DSL
> ---
>
> Key: NIFI-4325
> URL: https://issues.apache.org/jira/browse/NIFI-4325
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Mike Thomsen
>Priority: Minor
>
> The existing ElasticSearch processors use the Lucene-style syntax for 
> querying, not the JSON DSL. A new processor is needed that can take a full 
> JSON query and execute it. It should also support aggregation queries in this 
> syntax. A user needs to be able to take a query as-is from Kibana and drop it 
> into NiFi and have it just run.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi pull request #2113: NIFI-4325 Added new processor that uses the JSON DS...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/2113


---

[jira] [Resolved] (NIFI-4743) Suppress Nulls for PutElasticsearchHttpRecord

[Pierre Villard (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-4743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pierre Villard resolved NIFI-4743.
--
   Resolution: Fixed
Fix Version/s: 1.7.0

> Suppress Nulls for PutElasticsearchHttpRecord
> -
>
> Key: NIFI-4743
> URL: https://issues.apache.org/jira/browse/NIFI-4743
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Robert Bruno
>Assignee: Mike Thomsen
>Priority: Minor
> Fix For: 1.7.0
>
> Attachments: NullSuppression.java, PutElasticsearchHttpRecord.java
>
>
> Would be useful for PutElasticsearchHttpRecord to allow you to suppress NULL 
> values in the JSON that is inserted into ES much like the JsonRecordSetWriter 
> allows you to do.  Perhaps PutElasticsearchHttpRecord could some how make use 
> of JsonRecordSetWriter so it would inherit this functionality.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi pull request #2501: NIFI-4743 Added configurable null suppression to Pu...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/2501


---

[jira] [Commented] (NIFI-4743) Suppress Nulls for PutElasticsearchHttpRecord

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4743:
--

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/2501


> Suppress Nulls for PutElasticsearchHttpRecord
> -
>
> Key: NIFI-4743
> URL: https://issues.apache.org/jira/browse/NIFI-4743
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Robert Bruno
>Assignee: Mike Thomsen
>Priority: Minor
> Attachments: NullSuppression.java, PutElasticsearchHttpRecord.java
>
>
> Would be useful for PutElasticsearchHttpRecord to allow you to suppress NULL 
> values in the JSON that is inserted into ES much like the JsonRecordSetWriter 
> allows you to do.  Perhaps PutElasticsearchHttpRecord could some how make use 
> of JsonRecordSetWriter so it would inherit this functionality.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-4743) Suppress Nulls for PutElasticsearchHttpRecord

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on NIFI-4743:
---

Commit 6b34d3bea9a1fd0923024018d73c3c0b0a807a67 in nifi's branch 
refs/heads/master from [~mike.thomsen]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=6b34d3b ]

NIFI-4743 - Added configurable null suppression to PutElasticsearchHttpRecord

Signed-off-by: Pierre Villard 

This closes #2501.


> Suppress Nulls for PutElasticsearchHttpRecord
> -
>
> Key: NIFI-4743
> URL: https://issues.apache.org/jira/browse/NIFI-4743
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Robert Bruno
>Assignee: Mike Thomsen
>Priority: Minor
> Attachments: NullSuppression.java, PutElasticsearchHttpRecord.java
>
>
> Would be useful for PutElasticsearchHttpRecord to allow you to suppress NULL 
> values in the JSON that is inserted into ES much like the JsonRecordSetWriter 
> allows you to do.  Perhaps PutElasticsearchHttpRecord could some how make use 
> of JsonRecordSetWriter so it would inherit this functionality.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-4325) Create a new ElasticSearch processor that supports the JSON DSL

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4325:
--

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/2113
  
+1 

Overall looks good and works as expected. I've built with contrib check and 
tested using a vanilla instance. I will squash and merge to master. Thanks 
@MikeThomsen.


> Create a new ElasticSearch processor that supports the JSON DSL
> ---
>
> Key: NIFI-4325
> URL: https://issues.apache.org/jira/browse/NIFI-4325
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Mike Thomsen
>Priority: Minor
>
> The existing ElasticSearch processors use the Lucene-style syntax for 
> querying, not the JSON DSL. A new processor is needed that can take a full 
> JSON query and execute it. It should also support aggregation queries in this 
> syntax. A user needs to be able to take a query as-is from Kibana and drop it 
> into NiFi and have it just run.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi issue #2113: NIFI-4325 Added new processor that uses the JSON DSL.

[JPercivall]

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/2113
  
+1 

Overall looks good and works as expected. I've built with contrib check and 
tested using a vanilla instance. I will squash and merge to master. Thanks 
@MikeThomsen.


---

[GitHub] nifi-minifi pull request #117: MINIFI-424 Adding the ability to evaluate boo...

[jzonthemtn]

Github user jzonthemtn commented on a diff in the pull request:

https://github.com/apache/nifi-minifi/pull/117#discussion_r177183684
  
--- Diff: 
minifi-toolkit/minifi-toolkit-configuration/src/main/java/org/apache/nifi/minifi/toolkit/configuration/ConfigMain.java
 ---
@@ -106,10 +108,22 @@ public static void printValidateUsage() {
 }
 
 public int validate(String[] args) {
-if (args.length != 2) {
+if (args.length != 2 && args.length != 3) {
 printValidateUsage();
--- End diff --

Does `printValidateUsage()` need updated?


---

[jira] [Commented] (NIFI-4977) PutSyslog should support Expression Language for it's Sender properties

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4977:
--

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/2547
  
@bbende I've added the changes and rebased to master


> PutSyslog should support Expression Language for it's Sender properties
> ---
>
> Key: NIFI-4977
> URL: https://issues.apache.org/jira/browse/NIFI-4977
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Joseph Percivall
>Assignee: Joseph Percivall
>Priority: Minor
>
> As part of the continued effort to add access to the variable registry to 
> processors, the PutSyslog processor should expose expression language to it's 
> sender properties. These properties control where and how the processor sends 
> to. 
> This update should better align PutSyslog with the other PutX processors 
> which support EL on the sender properties (Slack, TCP, UDP).
> These properties are not evaluated per FlowFile and shouldn't be expected to 
> change between onTriggers (since the sender pool is shared) so it will need 
> to be documented as such that the 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi issue #2547: NIFI-4977 Adding expression language support to the Sender...

[JPercivall]

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/2547
  
@bbende I've added the changes and rebased to master


---

[GitHub] nifi-minifi pull request #117: MINIFI-424 Adding the ability to evaluate boo...

[jzonthemtn]

Github user jzonthemtn commented on a diff in the pull request:

https://github.com/apache/nifi-minifi/pull/117#discussion_r177177296
  
--- Diff: 
minifi-bootstrap/src/main/java/org/apache/nifi/minifi/bootstrap/RunMiNiFi.java 
---
@@ -1176,11 +1191,18 @@ public boolean accept(final File dir, final String 
filename) {
 
 @SuppressWarnings({"rawtypes", "unchecked"})
 public void start() throws IOException, InterruptedException {
+Properties bootstrapProperties = getBootstrapProperties();
+
+final String confDir = 
bootstrapProperties.getProperty(CONF_DIR_KEY);
+final File configFile = new 
File(bootstrapProperties.getProperty(MINIFI_CONFIG_FILE_KEY));
+final Properties transformationConfigProperties = 
getConfigTransformationProperties(bootstrapProperties);
+
+for(String name: 
transformationConfigProperties.stringPropertyNames()) {
+defaultLogger.error("config property: name:[" + name + "] 
value:[" + transformationConfigProperties.getProperty(name) + "] ");
--- End diff --

Would this be better as `info`?


---

[jira] [Commented] (NIFI-4994) Reload instance class loader at every component restart

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4994:
--

Github user bbende commented on the issue:

https://github.com/apache/nifi/pull/2568
  
This may need to be updated based on the recent changes in master that were 
just made today, basically the reloadIfNecessary method is going to return 
immediately if the component has a null fingerprint, so it would never hit the 
new logic in this PR.


> Reload instance class loader at every component restart
> ---
>
> Key: NIFI-4994
> URL: https://issues.apache.org/jira/browse/NIFI-4994
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Koji Kawamura
>Assignee: Koji Kawamura
>Priority: Major
>
> h2. Current Class loader reload mechanism
> NiFi framework provides RequiresInstanceClassLoading to annotate components 
> (Processor, Controller Service or Reporting Task) to use per instance class 
> loader. Instance class loaders are reloaded when associated components are 
> restarted, if any component property flagged as 
> 'dynamicallyModifiesClasspath' is updated. Such component property is used to 
> let user specify additional class pass resource URLs. E.g. PutHDFS 
> 'Additional Classpath Resources'.
> h2. Limitation of current mechanism
> Current mechanism requires component properties to trigger reloading to 
> represent class path resource URLs. That works well in scenarios for users to 
> add/del/mod additional class path resources.
> However there is different needs for reloading instance class loader. That is 
> re-initializing static state in dependencies.
> For example, ReportLineageToAtlas reporting task uses Atlas client library, 
> and the library has static code blocks to initialize its dependencies, such 
> as Kafka client with parameters passed by NiFi reporting task based on user 
> inputs. Once the initialization is done, there is no way to re-initialize 
> those objects, meaning even if NiFi user changes reporting task 
> configuration, those will not be able to reflected. 
> https://github.com/apache/atlas/blob/master/notification/src/main/java/org/apache/atlas/hook/AtlasHook.java#L63
> The only possible operations to reset such static state are, creating another 
> instance, configure the instance again, remove the old one and start new one. 
> Or restart NiFi process. This limitation affects UX negatively.
> h2. Improvement design
> Possible approaches are:
> # Enhance RequiresInstanceClassLoading annotation so that custom components 
> can specify whether it needs to be reloaded on every component restart 
> without condition.
> # Add new PropertyDescriptor instance field to denote that instance class 
> loader needs to be reloaded if a property is changed. Similar to 
> 'dynamicallyModifiesClasspath' but for configurations other than URI. Then, 
> include those property value to 
> AbstractConfiguredComponent.additionalResourcesFingerprint
> No.1 is more naive approach, but require less framework code change. No.2 
> looks redundant, also could be error-prone, e.g. by forgetting to mark some 
> properties.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi issue #2568: WIP NIFI-4994: Enable instance classloader restart without...

[bbende]

Github user bbende commented on the issue:

https://github.com/apache/nifi/pull/2568
  
This may need to be updated based on the recent changes in master that were 
just made today, basically the reloadIfNecessary method is going to return 
immediately if the component has a null fingerprint, so it would never hit the 
new logic in this PR.


---

[jira] [Resolved] (NIFI-5012) Controller Services are not automatically enabled/disabled when joining cluster

[Bryan Bende (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-5012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Bende resolved NIFI-5012.
---
   Resolution: Fixed
Fix Version/s: 1.6.0

> Controller Services are not automatically enabled/disabled when joining 
> cluster
> ---
>
> Key: NIFI-5012
> URL: https://issues.apache.org/jira/browse/NIFI-5012
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Major
> Fix For: 1.6.0
>
>
> If a node is disconnected from the cluster, a user is able to navigate to the 
> disconnected node and stop processors/controller services. Upon re-joining 
> the cluster, the node should inherit the cluster's run state for all 
> components. This works for processors but appears not to enable controller 
> services as expected. To duplicate, we can create a simple flow, as attached 
> in a template.
> Disconnect one node from the cluster. Navigate to the disconnected node, 
> disable the CSVReader controller service. Now re-join back to the cluster. 
> When the node rejoins, instead of the Controller Service being enabled, the 
> service is still disabled on this node, and the ConvertRecord processor is 
> invalid as a result. If you navigate to the Controller Services for the 
> Process Group, though, it shows that the service is enabled. As a result, if 
> the ConvertRecord processor is already running when re-joining, it will show 
> as running but still be invalid on one node.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-5012) Controller Services are not automatically enabled/disabled when joining cluster

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on NIFI-5012:
---

Commit 456c9c8fc0f8ebd0131ea02aaa89fc374e3c6882 in nifi's branch 
refs/heads/master from [~markap14]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=456c9c8 ]

NIFI-5012: When connecting to cluster, esure that controller services 
appropriately enabled/disabled

This closes #2579.

Signed-off-by: Bryan Bende 


> Controller Services are not automatically enabled/disabled when joining 
> cluster
> ---
>
> Key: NIFI-5012
> URL: https://issues.apache.org/jira/browse/NIFI-5012
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Major
>
> If a node is disconnected from the cluster, a user is able to navigate to the 
> disconnected node and stop processors/controller services. Upon re-joining 
> the cluster, the node should inherit the cluster's run state for all 
> components. This works for processors but appears not to enable controller 
> services as expected. To duplicate, we can create a simple flow, as attached 
> in a template.
> Disconnect one node from the cluster. Navigate to the disconnected node, 
> disable the CSVReader controller service. Now re-join back to the cluster. 
> When the node rejoins, instead of the Controller Service being enabled, the 
> service is still disabled on this node, and the ConvertRecord processor is 
> invalid as a result. If you navigate to the Controller Services for the 
> Process Group, though, it shows that the service is enabled. As a result, if 
> the ConvertRecord processor is already running when re-joining, it will show 
> as running but still be invalid on one node.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-5012) Controller Services are not automatically enabled/disabled when joining cluster

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-5012:
--

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/2579


> Controller Services are not automatically enabled/disabled when joining 
> cluster
> ---
>
> Key: NIFI-5012
> URL: https://issues.apache.org/jira/browse/NIFI-5012
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Major
>
> If a node is disconnected from the cluster, a user is able to navigate to the 
> disconnected node and stop processors/controller services. Upon re-joining 
> the cluster, the node should inherit the cluster's run state for all 
> components. This works for processors but appears not to enable controller 
> services as expected. To duplicate, we can create a simple flow, as attached 
> in a template.
> Disconnect one node from the cluster. Navigate to the disconnected node, 
> disable the CSVReader controller service. Now re-join back to the cluster. 
> When the node rejoins, instead of the Controller Service being enabled, the 
> service is still disabled on this node, and the ConvertRecord processor is 
> invalid as a result. If you navigate to the Controller Services for the 
> Process Group, though, it shows that the service is enabled. As a result, if 
> the ConvertRecord processor is already running when re-joining, it will show 
> as running but still be invalid on one node.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi pull request #2579: NIFI-5012: When connecting to cluster, esure that c...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/2579


---

[jira] [Commented] (NIFI-5012) Controller Services are not automatically enabled/disabled when joining cluster

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-5012:
--

Github user bbende commented on the issue:

https://github.com/apache/nifi/pull/2579
  
Looks good, merging


> Controller Services are not automatically enabled/disabled when joining 
> cluster
> ---
>
> Key: NIFI-5012
> URL: https://issues.apache.org/jira/browse/NIFI-5012
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Major
>
> If a node is disconnected from the cluster, a user is able to navigate to the 
> disconnected node and stop processors/controller services. Upon re-joining 
> the cluster, the node should inherit the cluster's run state for all 
> components. This works for processors but appears not to enable controller 
> services as expected. To duplicate, we can create a simple flow, as attached 
> in a template.
> Disconnect one node from the cluster. Navigate to the disconnected node, 
> disable the CSVReader controller service. Now re-join back to the cluster. 
> When the node rejoins, instead of the Controller Service being enabled, the 
> service is still disabled on this node, and the ConvertRecord processor is 
> invalid as a result. If you navigate to the Controller Services for the 
> Process Group, though, it shows that the service is enabled. As a result, if 
> the ConvertRecord processor is already running when re-joining, it will show 
> as running but still be invalid on one node.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi issue #2579: NIFI-5012: When connecting to cluster, esure that controll...

[bbende]

Github user bbende commented on the issue:

https://github.com/apache/nifi/pull/2579
  
Looks good, merging


---

[jira] [Commented] (NIFI-4977) PutSyslog should support Expression Language for it's Sender properties

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4977:
--

Github user JPercivall commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2547#discussion_r177146046
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/AbstractSyslogProcessor.java
 ---
@@ -29,34 +29,28 @@
 public static final AllowableValue TCP_VALUE = new 
AllowableValue("TCP", "TCP");
 public static final AllowableValue UDP_VALUE = new 
AllowableValue("UDP", "UDP");
 
-public static final PropertyDescriptor PROTOCOL = new 
PropertyDescriptor
+public static final PropertyDescriptor PROTOCOL_PROP = new 
PropertyDescriptor
 .Builder().name("Protocol")
 .description("The protocol for Syslog communication.")
 .required(true)
 .allowableValues(TCP_VALUE, UDP_VALUE)
 .defaultValue(UDP_VALUE.getValue())
 .build();
-public static final PropertyDescriptor PORT = new PropertyDescriptor
+public static final PropertyDescriptor.Builder PORT_PROP_BUILDER = new 
PropertyDescriptor
--- End diff --

Yeah, the reason was just that I was shying away from modifying the 
ListenSyslog processor as well but that's probably a better way to go. Will fix


> PutSyslog should support Expression Language for it's Sender properties
> ---
>
> Key: NIFI-4977
> URL: https://issues.apache.org/jira/browse/NIFI-4977
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Joseph Percivall
>Assignee: Joseph Percivall
>Priority: Minor
>
> As part of the continued effort to add access to the variable registry to 
> processors, the PutSyslog processor should expose expression language to it's 
> sender properties. These properties control where and how the processor sends 
> to. 
> This update should better align PutSyslog with the other PutX processors 
> which support EL on the sender properties (Slack, TCP, UDP).
> These properties are not evaluated per FlowFile and shouldn't be expected to 
> change between onTriggers (since the sender pool is shared) so it will need 
> to be documented as such that the 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi pull request #2547: NIFI-4977 Adding expression language support to the...

[JPercivall]

Github user JPercivall commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2547#discussion_r177146046
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/AbstractSyslogProcessor.java
 ---
@@ -29,34 +29,28 @@
 public static final AllowableValue TCP_VALUE = new 
AllowableValue("TCP", "TCP");
 public static final AllowableValue UDP_VALUE = new 
AllowableValue("UDP", "UDP");
 
-public static final PropertyDescriptor PROTOCOL = new 
PropertyDescriptor
+public static final PropertyDescriptor PROTOCOL_PROP = new 
PropertyDescriptor
 .Builder().name("Protocol")
 .description("The protocol for Syslog communication.")
 .required(true)
 .allowableValues(TCP_VALUE, UDP_VALUE)
 .defaultValue(UDP_VALUE.getValue())
 .build();
-public static final PropertyDescriptor PORT = new PropertyDescriptor
+public static final PropertyDescriptor.Builder PORT_PROP_BUILDER = new 
PropertyDescriptor
--- End diff --

Yeah, the reason was just that I was shying away from modifying the 
ListenSyslog processor as well but that's probably a better way to go. Will fix


---

[jira] [Commented] (NIFI-4977) PutSyslog should support Expression Language for it's Sender properties

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4977:
--

Github user JPercivall commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2547#discussion_r177145747
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/AbstractSyslogProcessor.java
 ---
@@ -29,34 +29,28 @@
 public static final AllowableValue TCP_VALUE = new 
AllowableValue("TCP", "TCP");
 public static final AllowableValue UDP_VALUE = new 
AllowableValue("UDP", "UDP");
 
-public static final PropertyDescriptor PROTOCOL = new 
PropertyDescriptor
+public static final PropertyDescriptor PROTOCOL_PROP = new 
PropertyDescriptor
 .Builder().name("Protocol")
 .description("The protocol for Syslog communication.")
 .required(true)
 .allowableValues(TCP_VALUE, UDP_VALUE)
--- End diff --

Yup, you're right will adjust


> PutSyslog should support Expression Language for it's Sender properties
> ---
>
> Key: NIFI-4977
> URL: https://issues.apache.org/jira/browse/NIFI-4977
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Joseph Percivall
>Assignee: Joseph Percivall
>Priority: Minor
>
> As part of the continued effort to add access to the variable registry to 
> processors, the PutSyslog processor should expose expression language to it's 
> sender properties. These properties control where and how the processor sends 
> to. 
> This update should better align PutSyslog with the other PutX processors 
> which support EL on the sender properties (Slack, TCP, UDP).
> These properties are not evaluated per FlowFile and shouldn't be expected to 
> change between onTriggers (since the sender pool is shared) so it will need 
> to be documented as such that the 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi pull request #2547: NIFI-4977 Adding expression language support to the...

[JPercivall]

Github user JPercivall commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2547#discussion_r177145747
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/AbstractSyslogProcessor.java
 ---
@@ -29,34 +29,28 @@
 public static final AllowableValue TCP_VALUE = new 
AllowableValue("TCP", "TCP");
 public static final AllowableValue UDP_VALUE = new 
AllowableValue("UDP", "UDP");
 
-public static final PropertyDescriptor PROTOCOL = new 
PropertyDescriptor
+public static final PropertyDescriptor PROTOCOL_PROP = new 
PropertyDescriptor
 .Builder().name("Protocol")
 .description("The protocol for Syslog communication.")
 .required(true)
 .allowableValues(TCP_VALUE, UDP_VALUE)
--- End diff --

Yup, you're right will adjust


---

[jira] [Commented] (NIFI-4927) Create InfluxDB Query Processor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4927:
--

Github user MikeThomsen commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2562#discussion_r177131556
  
--- Diff: 
nifi-nar-bundles/nifi-influxdb-bundle/nifi-influxdb-processors/src/test/java/org/apache/nifi/processors/influxdb/AbstractITInfluxDB.java
 ---
@@ -36,14 +36,7 @@
 
 protected void initInfluxDB() throws InterruptedException, Exception {
 influxDB = InfluxDBFactory.connect(dbUrl,user,password);
-if ( influxDB.databaseExists(dbName) ) {
-QueryResult result = influxDB.query(new Query("DROP 
measurement water", dbName));
-checkError(result);
-result = influxDB.query(new Query("DROP measurement testm", 
dbName));
-checkError(result);
-result = influxDB.query(new Query("DROP database " + dbName, 
dbName));
-Thread.sleep(1000);
-}
+cleanUpDatabase();
--- End diff --

What I meant was that the cleanup functionality shouldn't be called in the 
init, but should be called from the `@After` annotated method.


> Create InfluxDB Query Processor
> ---
>
> Key: NIFI-4927
> URL: https://issues.apache.org/jira/browse/NIFI-4927
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: 1.5.0
>Reporter: Mans Singh
>Assignee: Mans Singh
>Priority: Minor
>  Labels: measurements,, query, realtime, timeseries
>
> Create InfluxDB Query processor



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-4927) Create InfluxDB Query Processor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4927:
--

Github user MikeThomsen commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2562#discussion_r177120294
  
--- Diff: 
nifi-nar-bundles/nifi-influxdb-bundle/nifi-influxdb-processors/src/main/java/org/apache/nifi/processors/influxdb/ExecuteInfluxDBQuery.java
 ---
@@ -72,6 +74,16 @@
 .sensitive(false)
 .build();
 
+public static final PropertyDescriptor INFLUX_DB_SCHEDULED_QUERY = new 
PropertyDescriptor.Builder()
+.name("influxdb-scheduled-query")
+.displayName("InfluxDB Schedued Query")
--- End diff --

I think calling it a "scheduled query" might be a bit confusing. In other 
places like `GetMongo` it's just `Query` and documents that this field will be 
used if it's filled in, otherwise it'll try to extract the query from the body. 
Might want to also note that you can use this w/ an incoming connection and use 
the flowfile to power the EL.


> Create InfluxDB Query Processor
> ---
>
> Key: NIFI-4927
> URL: https://issues.apache.org/jira/browse/NIFI-4927
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: 1.5.0
>Reporter: Mans Singh
>Assignee: Mans Singh
>Priority: Minor
>  Labels: measurements,, query, realtime, timeseries
>
> Create InfluxDB Query processor



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-4927) Create InfluxDB Query Processor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4927:
--

Github user MikeThomsen commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2562#discussion_r177119360
  
--- Diff: 
nifi-nar-bundles/nifi-influxdb-bundle/nifi-influxdb-processors/src/main/java/org/apache/nifi/processors/influxdb/ExecuteInfluxDBQuery.java
 ---
@@ -0,0 +1,199 @@
+/*
+ * 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.influxdb;
+import org.apache.nifi.annotation.behavior.EventDriven;
+import org.apache.nifi.annotation.behavior.InputRequirement;
+import org.apache.nifi.annotation.behavior.SupportsBatching;
+import org.apache.nifi.annotation.behavior.WritesAttribute;
+import org.apache.nifi.annotation.behavior.WritesAttributes;
+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.annotation.lifecycle.OnStopped;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.flowfile.FlowFile;
+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.influxdb.dto.Query;
+import org.influxdb.dto.QueryResult;
+import com.google.gson.Gson;
+import java.io.ByteArrayInputStream;
+import java.io.ByteArrayOutputStream;
+import java.net.SocketTimeoutException;
+import java.nio.charset.Charset;
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Map;
+import java.util.Set;
+import java.util.concurrent.TimeUnit;
+import java.util.stream.Collectors;
+
+@InputRequirement(InputRequirement.Requirement.INPUT_REQUIRED)
+@EventDriven
+@SupportsBatching
+@Tags({"influxdb", "measurement","get", "read", "query", "timeseries"})
+@CapabilityDescription("Processor to execute InfluxDB query from the 
content of a FlowFile.  Please check details of the supported queries in 
InfluxDB documentation (https://www.influxdb.com/).")
+@WritesAttributes({
+@WritesAttribute(attribute = 
AbstractInfluxDBProcessor.INFLUX_DB_ERROR_MESSAGE, description = "InfluxDB 
error message"),
+@WritesAttribute(attribute = 
ExecuteInfluxDBQuery.INFLUX_DB_EXECUTED_QUERY, description = "InfluxDB executed 
query"),
+})
+public class ExecuteInfluxDBQuery extends AbstractInfluxDBProcessor {
+
+public static final String INFLUX_DB_EXECUTED_QUERY = 
"influxdb.executed.query";
+
+public static final PropertyDescriptor INFLUX_DB_QUERY_RESULT_TIMEUNIT 
= new PropertyDescriptor.Builder()
+.name("influxdb-query-result-time-unit")
+.displayName("Query Result Time Units")
+.description("The time unit of query results from the 
InfluxDB")
+.defaultValue(TimeUnit.NANOSECONDS.name())
+.required(true)
+.expressionLanguageSupported(true)
+.allowableValues(Arrays.stream(TimeUnit.values()).map( v -> 
v.name()).collect(Collectors.toSet()))
+.sensitive(false)
+.build();
+
+static final Relationship REL_SUCCESS = new 
Relationship.Builder().name("success")
+.description("Successful InfluxDB queries are routed to this 
relationship").build();
+
+static final Relationship REL_FAILURE = new 
Relationship.Builder().name("failure")
+.description("Falied InfluxDB queries are routed to this 
relationship").build();
+
+static final Relationship REL_RETRY = new 

[GitHub] nifi pull request #2562: NIFI-4927 - InfluxDB Query Processor

[MikeThomsen]

Github user MikeThomsen commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2562#discussion_r177120294
  
--- Diff: 
nifi-nar-bundles/nifi-influxdb-bundle/nifi-influxdb-processors/src/main/java/org/apache/nifi/processors/influxdb/ExecuteInfluxDBQuery.java
 ---
@@ -72,6 +74,16 @@
 .sensitive(false)
 .build();
 
+public static final PropertyDescriptor INFLUX_DB_SCHEDULED_QUERY = new 
PropertyDescriptor.Builder()
+.name("influxdb-scheduled-query")
+.displayName("InfluxDB Schedued Query")
--- End diff --

I think calling it a "scheduled query" might be a bit confusing. In other 
places like `GetMongo` it's just `Query` and documents that this field will be 
used if it's filled in, otherwise it'll try to extract the query from the body. 
Might want to also note that you can use this w/ an incoming connection and use 
the flowfile to power the EL.


---

[GitHub] nifi pull request #2562: NIFI-4927 - InfluxDB Query Processor

[MikeThomsen]

Github user MikeThomsen commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2562#discussion_r177131556
  
--- Diff: 
nifi-nar-bundles/nifi-influxdb-bundle/nifi-influxdb-processors/src/test/java/org/apache/nifi/processors/influxdb/AbstractITInfluxDB.java
 ---
@@ -36,14 +36,7 @@
 
 protected void initInfluxDB() throws InterruptedException, Exception {
 influxDB = InfluxDBFactory.connect(dbUrl,user,password);
-if ( influxDB.databaseExists(dbName) ) {
-QueryResult result = influxDB.query(new Query("DROP 
measurement water", dbName));
-checkError(result);
-result = influxDB.query(new Query("DROP measurement testm", 
dbName));
-checkError(result);
-result = influxDB.query(new Query("DROP database " + dbName, 
dbName));
-Thread.sleep(1000);
-}
+cleanUpDatabase();
--- End diff --

What I meant was that the cleanup functionality shouldn't be called in the 
init, but should be called from the `@After` annotated method.


---

[jira] [Commented] (NIFI-4995) Release Apache NiFi 1.6.0

[Joseph Witt (JIRA)]

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

Joseph Witt commented on NIFI-4995:
---

thanks will give it a whirl again tonight hopefully.  If i miss that then it'll 
need to be on Wed.

 

Thanks!

> Release Apache NiFi 1.6.0
> -
>
> Key: NIFI-4995
> URL: https://issues.apache.org/jira/browse/NIFI-4995
> Project: Apache NiFi
>  Issue Type: Task
>  Components: Tools and Build
>Affects Versions: 1.6.0
>Reporter: Joseph Witt
>Assignee: Joseph Witt
>Priority: Blocker
> Fix For: 1.6.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-4995) Release Apache NiFi 1.6.0

[Bryan Bende (JIRA)]

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

Bryan Bende commented on NIFI-4995:
---

[~joewitt] the fix for NIFI-4864 has been merged to master, everything should 
be ready to kick out an RC2

> Release Apache NiFi 1.6.0
> -
>
> Key: NIFI-4995
> URL: https://issues.apache.org/jira/browse/NIFI-4995
> Project: Apache NiFi
>  Issue Type: Task
>  Components: Tools and Build
>Affects Versions: 1.6.0
>Reporter: Joseph Witt
>Assignee: Joseph Witt
>Priority: Blocker
> Fix For: 1.6.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-4977) PutSyslog should support Expression Language for it's Sender properties

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4977:
--

Github user bbende commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2547#discussion_r177119368
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/AbstractSyslogProcessor.java
 ---
@@ -29,34 +29,28 @@
 public static final AllowableValue TCP_VALUE = new 
AllowableValue("TCP", "TCP");
 public static final AllowableValue UDP_VALUE = new 
AllowableValue("UDP", "UDP");
 
-public static final PropertyDescriptor PROTOCOL = new 
PropertyDescriptor
+public static final PropertyDescriptor PROTOCOL_PROP = new 
PropertyDescriptor
 .Builder().name("Protocol")
 .description("The protocol for Syslog communication.")
 .required(true)
 .allowableValues(TCP_VALUE, UDP_VALUE)
--- End diff --

Since protocol uses allowable values, there isn't a way for a user to enter 
expression language


> PutSyslog should support Expression Language for it's Sender properties
> ---
>
> Key: NIFI-4977
> URL: https://issues.apache.org/jira/browse/NIFI-4977
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Joseph Percivall
>Assignee: Joseph Percivall
>Priority: Minor
>
> As part of the continued effort to add access to the variable registry to 
> processors, the PutSyslog processor should expose expression language to it's 
> sender properties. These properties control where and how the processor sends 
> to. 
> This update should better align PutSyslog with the other PutX processors 
> which support EL on the sender properties (Slack, TCP, UDP).
> These properties are not evaluated per FlowFile and shouldn't be expected to 
> change between onTriggers (since the sender pool is shared) so it will need 
> to be documented as such that the 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-4864) Additional Resources property pointing at a directory won't find new JARs

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4864:
--

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/2581


> Additional Resources property pointing at a directory won't find new JARs
> -
>
> Key: NIFI-4864
> URL: https://issues.apache.org/jira/browse/NIFI-4864
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.2.0, 1.3.0, 1.4.0, 1.5.0
>Reporter: Bryan Bende
>Assignee: Sivaprasanna Sethuraman
>Priority: Blocker
> Fix For: 1.6.0
>
>
> If you have a processor/Controller Service/Reporting Task that has a property 
> with dynamicallyModifiesClasspath(true) and you set the value to a directory, 
> the resources in that directory will only be calculated when that property 
> changes. This means if you added JARs to the directory later, and stopped and 
> started your processor, those new JARs still won't be available. You would 
> have to change the property to a new directory, or back and forth to some 
> other directory, to force a recalculation.
> The setProperties method in AbstractConfiguredComponent is where it looks at 
> incoming property changes and determines if any were for classpath related 
> properties and then calls reload accordingly.
> We would need to consider the case where setProperties is never even being 
> called, someone just stops and starts the processor and would want to pick up 
> any new JARs added.
> A possible solution might be to computer some kind of hash/fingerprint of the 
> URLs each time reload is called, and then when starting the processor we 
> could recompute the fingerprint and compare it to the previous one. If they 
> are different then we call reload before starting the component.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (NIFI-4864) Additional Resources property pointing at a directory won't find new JARs

[Bryan Bende (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-4864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Bende resolved NIFI-4864.
---
Resolution: Fixed

> Additional Resources property pointing at a directory won't find new JARs
> -
>
> Key: NIFI-4864
> URL: https://issues.apache.org/jira/browse/NIFI-4864
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.2.0, 1.3.0, 1.4.0, 1.5.0
>Reporter: Bryan Bende
>Assignee: Sivaprasanna Sethuraman
>Priority: Blocker
> Fix For: 1.6.0
>
>
> If you have a processor/Controller Service/Reporting Task that has a property 
> with dynamicallyModifiesClasspath(true) and you set the value to a directory, 
> the resources in that directory will only be calculated when that property 
> changes. This means if you added JARs to the directory later, and stopped and 
> started your processor, those new JARs still won't be available. You would 
> have to change the property to a new directory, or back and forth to some 
> other directory, to force a recalculation.
> The setProperties method in AbstractConfiguredComponent is where it looks at 
> incoming property changes and determines if any were for classpath related 
> properties and then calls reload accordingly.
> We would need to consider the case where setProperties is never even being 
> called, someone just stops and starts the processor and would want to pick up 
> any new JARs added.
> A possible solution might be to computer some kind of hash/fingerprint of the 
> URLs each time reload is called, and then when starting the processor we 
> could recompute the fingerprint and compare it to the previous one. If they 
> are different then we call reload before starting the component.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-4977) PutSyslog should support Expression Language for it's Sender properties

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4977:
--

Github user bbende commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2547#discussion_r177121695
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/AbstractSyslogProcessor.java
 ---
@@ -29,34 +29,28 @@
 public static final AllowableValue TCP_VALUE = new 
AllowableValue("TCP", "TCP");
 public static final AllowableValue UDP_VALUE = new 
AllowableValue("UDP", "UDP");
 
-public static final PropertyDescriptor PROTOCOL = new 
PropertyDescriptor
+public static final PropertyDescriptor PROTOCOL_PROP = new 
PropertyDescriptor
 .Builder().name("Protocol")
 .description("The protocol for Syslog communication.")
 .required(true)
 .allowableValues(TCP_VALUE, UDP_VALUE)
 .defaultValue(UDP_VALUE.getValue())
 .build();
-public static final PropertyDescriptor PORT = new PropertyDescriptor
+public static final PropertyDescriptor.Builder PORT_PROP_BUILDER = new 
PropertyDescriptor
--- End diff --

Any reason not to just update the property descriptors directly in 
AbstractSyslogProcessor?

Assuming we don't support EL for protocol, and given the timeout property 
isn't used by ListenSyslog, we'd only have to modify two additional lines in 
ListenSyslog where it evaluates the port and charset.


> PutSyslog should support Expression Language for it's Sender properties
> ---
>
> Key: NIFI-4977
> URL: https://issues.apache.org/jira/browse/NIFI-4977
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Joseph Percivall
>Assignee: Joseph Percivall
>Priority: Minor
>
> As part of the continued effort to add access to the variable registry to 
> processors, the PutSyslog processor should expose expression language to it's 
> sender properties. These properties control where and how the processor sends 
> to. 
> This update should better align PutSyslog with the other PutX processors 
> which support EL on the sender properties (Slack, TCP, UDP).
> These properties are not evaluated per FlowFile and shouldn't be expected to 
> change between onTriggers (since the sender pool is shared) so it will need 
> to be documented as such that the 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-4864) Additional Resources property pointing at a directory won't find new JARs

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4864:
--

Github user bbende commented on the issue:

https://github.com/apache/nifi/pull/2581
  
This looks good, verified it resolves the issue and is no longer reloading 
any components except those that have the classpath property descriptors, going 
to merge


> Additional Resources property pointing at a directory won't find new JARs
> -
>
> Key: NIFI-4864
> URL: https://issues.apache.org/jira/browse/NIFI-4864
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.2.0, 1.3.0, 1.4.0, 1.5.0
>Reporter: Bryan Bende
>Assignee: Sivaprasanna Sethuraman
>Priority: Blocker
> Fix For: 1.6.0
>
>
> If you have a processor/Controller Service/Reporting Task that has a property 
> with dynamicallyModifiesClasspath(true) and you set the value to a directory, 
> the resources in that directory will only be calculated when that property 
> changes. This means if you added JARs to the directory later, and stopped and 
> started your processor, those new JARs still won't be available. You would 
> have to change the property to a new directory, or back and forth to some 
> other directory, to force a recalculation.
> The setProperties method in AbstractConfiguredComponent is where it looks at 
> incoming property changes and determines if any were for classpath related 
> properties and then calls reload accordingly.
> We would need to consider the case where setProperties is never even being 
> called, someone just stops and starts the processor and would want to pick up 
> any new JARs added.
> A possible solution might be to computer some kind of hash/fingerprint of the 
> URLs each time reload is called, and then when starting the processor we 
> could recompute the fingerprint and compare it to the previous one. If they 
> are different then we call reload before starting the component.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-4198) *ElasticsearchHttp processors do not expose Proxy settings

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4198:
--

Github user mattyb149 commented on the issue:

https://github.com/apache/nifi/pull/2094
  
The code LGTM, but I am getting a 401 Unauthorized when trying to use my 
nginx proxy (with authentication). I put a debugger inside the 
proxyAuthenticator callback but it never gets called. I verified the proxy 
requires auth by using the browser to hit the proxy endpoint, it asks for 
user/pass then takes me to the base ES endpoint ("You know, for search"). I can 
hit other endpoints as well (individual docs, etc.) Any pointers on what I'm 
doing wrong?


> *ElasticsearchHttp processors do not expose Proxy settings
> --
>
> Key: NIFI-4198
> URL: https://issues.apache.org/jira/browse/NIFI-4198
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.4.0
>Reporter: Andre F de Miranda
>Assignee: Arun Manivannan
>Priority: Major
> Attachments: NIFI-4198-ElasticProxy-TestFixtures.pdf, 
> NIFI-4198-ElasticProxy.xml
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-4864) Additional Resources property pointing at a directory won't find new JARs

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on NIFI-4864:
---

Commit 3612fbe5222b5a0db10b73b070f8b6fbdc03def2 in nifi's branch 
refs/heads/master from [~sivaprasanna]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=3612fbe ]

NIFI-4864: Improvements to PR #2470

This closes #2581.

Signed-off-by: Bryan Bende 


> Additional Resources property pointing at a directory won't find new JARs
> -
>
> Key: NIFI-4864
> URL: https://issues.apache.org/jira/browse/NIFI-4864
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.2.0, 1.3.0, 1.4.0, 1.5.0
>Reporter: Bryan Bende
>Assignee: Sivaprasanna Sethuraman
>Priority: Blocker
> Fix For: 1.6.0
>
>
> If you have a processor/Controller Service/Reporting Task that has a property 
> with dynamicallyModifiesClasspath(true) and you set the value to a directory, 
> the resources in that directory will only be calculated when that property 
> changes. This means if you added JARs to the directory later, and stopped and 
> started your processor, those new JARs still won't be available. You would 
> have to change the property to a new directory, or back and forth to some 
> other directory, to force a recalculation.
> The setProperties method in AbstractConfiguredComponent is where it looks at 
> incoming property changes and determines if any were for classpath related 
> properties and then calls reload accordingly.
> We would need to consider the case where setProperties is never even being 
> called, someone just stops and starts the processor and would want to pick up 
> any new JARs added.
> A possible solution might be to computer some kind of hash/fingerprint of the 
> URLs each time reload is called, and then when starting the processor we 
> could recompute the fingerprint and compare it to the previous one. If they 
> are different then we call reload before starting the component.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-5009) PutParquet processor requires "read filesystem" restricted component permission but should be "write filesystem" permission instead

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-5009:
--

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/2583


> PutParquet processor requires "read filesystem" restricted component 
> permission but should be "write filesystem" permission instead
> ---
>
> Key: NIFI-5009
> URL: https://issues.apache.org/jira/browse/NIFI-5009
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework, Core UI
>Affects Versions: 1.6.0
>Reporter: Andrew Lim
>Assignee: Matt Gilman
>Priority: Minor
> Fix For: 1.6.0
>
> Attachments: PutParquet_permission.jpg
>
>
> Similar to the other Put*** restricted processors, this is a write 
> processor, so it should require "write filesystem" permissions.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-5009) PutParquet processor requires "read filesystem" restricted component permission but should be "write filesystem" permission instead

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-5009:
--

Github user bbende commented on the issue:

https://github.com/apache/nifi/pull/2583
  
Looks good, will merge


> PutParquet processor requires "read filesystem" restricted component 
> permission but should be "write filesystem" permission instead
> ---
>
> Key: NIFI-5009
> URL: https://issues.apache.org/jira/browse/NIFI-5009
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework, Core UI
>Affects Versions: 1.6.0
>Reporter: Andrew Lim
>Assignee: Matt Gilman
>Priority: Minor
> Attachments: PutParquet_permission.jpg
>
>
> Similar to the other Put*** restricted processors, this is a write 
> processor, so it should require "write filesystem" permissions.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-5009) PutParquet processor requires "read filesystem" restricted component permission but should be "write filesystem" permission instead

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on NIFI-5009:
---

Commit 69a564e4c83c452f8be819d8e978c28d43c13d7b in nifi's branch 
refs/heads/master from [~mcgilman]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=69a564e ]

NIFI-5009:
- Fixing required permission for PutParquet.

NIFI-5008:
- Ensuring all restricted components are tagged as such.

This closes #2583.

Signed-off-by: Bryan Bende 


> PutParquet processor requires "read filesystem" restricted component 
> permission but should be "write filesystem" permission instead
> ---
>
> Key: NIFI-5009
> URL: https://issues.apache.org/jira/browse/NIFI-5009
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework, Core UI
>Affects Versions: 1.6.0
>Reporter: Andrew Lim
>Assignee: Matt Gilman
>Priority: Minor
> Fix For: 1.6.0
>
> Attachments: PutParquet_permission.jpg
>
>
> Similar to the other Put*** restricted processors, this is a write 
> processor, so it should require "write filesystem" permissions.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (NIFI-5008) Components are marked with the "restricted" red shield icon, but are not tagged as "restricted".

[Bryan Bende (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-5008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Bende updated NIFI-5008:
--
   Resolution: Fixed
Fix Version/s: 1.6.0
   Status: Resolved  (was: Patch Available)

> Components are marked with the "restricted" red shield icon, but are not 
> tagged as "restricted".
> 
>
> Key: NIFI-5008
> URL: https://issues.apache.org/jira/browse/NIFI-5008
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Andrew Lim
>Assignee: Matt Gilman
>Priority: Minor
> Fix For: 1.6.0
>
>
> Without the "restricted" tag, the components will not show up when filtering 
> by that tag.
> These are the components that need to have the "restricted" tag added:
>  
> *Processors:*
>  
> ExecuteGroovyScript
> GetHDFSSequenceFile
>  
> *Controller Services:*
>  
> KeytabCredentialsService
>  
> *Reporting Task:*
>  
> ScriptedReportingTask
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (NIFI-5009) PutParquet processor requires "read filesystem" restricted component permission but should be "write filesystem" permission instead

[Bryan Bende (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-5009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Bende updated NIFI-5009:
--
   Resolution: Fixed
Fix Version/s: 1.6.0
   Status: Resolved  (was: Patch Available)

> PutParquet processor requires "read filesystem" restricted component 
> permission but should be "write filesystem" permission instead
> ---
>
> Key: NIFI-5009
> URL: https://issues.apache.org/jira/browse/NIFI-5009
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework, Core UI
>Affects Versions: 1.6.0
>Reporter: Andrew Lim
>Assignee: Matt Gilman
>Priority: Minor
> Fix For: 1.6.0
>
> Attachments: PutParquet_permission.jpg
>
>
> Similar to the other Put*** restricted processors, this is a write 
> processor, so it should require "write filesystem" permissions.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-5008) Components are marked with the "restricted" red shield icon, but are not tagged as "restricted".

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on NIFI-5008:
---

Commit 69a564e4c83c452f8be819d8e978c28d43c13d7b in nifi's branch 
refs/heads/master from [~mcgilman]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=69a564e ]

NIFI-5009:
- Fixing required permission for PutParquet.

NIFI-5008:
- Ensuring all restricted components are tagged as such.

This closes #2583.

Signed-off-by: Bryan Bende 


> Components are marked with the "restricted" red shield icon, but are not 
> tagged as "restricted".
> 
>
> Key: NIFI-5008
> URL: https://issues.apache.org/jira/browse/NIFI-5008
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Andrew Lim
>Assignee: Matt Gilman
>Priority: Minor
>
> Without the "restricted" tag, the components will not show up when filtering 
> by that tag.
> These are the components that need to have the "restricted" tag added:
>  
> *Processors:*
>  
> ExecuteGroovyScript
> GetHDFSSequenceFile
>  
> *Controller Services:*
>  
> KeytabCredentialsService
>  
> *Reporting Task:*
>  
> ScriptedReportingTask
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi pull request #2547: NIFI-4977 Adding expression language support to the...

[bbende]

Github user bbende commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2547#discussion_r177119368
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/AbstractSyslogProcessor.java
 ---
@@ -29,34 +29,28 @@
 public static final AllowableValue TCP_VALUE = new 
AllowableValue("TCP", "TCP");
 public static final AllowableValue UDP_VALUE = new 
AllowableValue("UDP", "UDP");
 
-public static final PropertyDescriptor PROTOCOL = new 
PropertyDescriptor
+public static final PropertyDescriptor PROTOCOL_PROP = new 
PropertyDescriptor
 .Builder().name("Protocol")
 .description("The protocol for Syslog communication.")
 .required(true)
 .allowableValues(TCP_VALUE, UDP_VALUE)
--- End diff --

Since protocol uses allowable values, there isn't a way for a user to enter 
expression language


---

[GitHub] nifi pull request #2547: NIFI-4977 Adding expression language support to the...

[bbende]

Github user bbende commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2547#discussion_r177121695
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/AbstractSyslogProcessor.java
 ---
@@ -29,34 +29,28 @@
 public static final AllowableValue TCP_VALUE = new 
AllowableValue("TCP", "TCP");
 public static final AllowableValue UDP_VALUE = new 
AllowableValue("UDP", "UDP");
 
-public static final PropertyDescriptor PROTOCOL = new 
PropertyDescriptor
+public static final PropertyDescriptor PROTOCOL_PROP = new 
PropertyDescriptor
 .Builder().name("Protocol")
 .description("The protocol for Syslog communication.")
 .required(true)
 .allowableValues(TCP_VALUE, UDP_VALUE)
 .defaultValue(UDP_VALUE.getValue())
 .build();
-public static final PropertyDescriptor PORT = new PropertyDescriptor
+public static final PropertyDescriptor.Builder PORT_PROP_BUILDER = new 
PropertyDescriptor
--- End diff --

Any reason not to just update the property descriptors directly in 
AbstractSyslogProcessor?

Assuming we don't support EL for protocol, and given the timeout property 
isn't used by ListenSyslog, we'd only have to modify two additional lines in 
ListenSyslog where it evaluates the port and charset.


---

[GitHub] nifi pull request #2562: NIFI-4927 - InfluxDB Query Processor

[MikeThomsen]

Github user MikeThomsen commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2562#discussion_r177119360
  
--- Diff: 
nifi-nar-bundles/nifi-influxdb-bundle/nifi-influxdb-processors/src/main/java/org/apache/nifi/processors/influxdb/ExecuteInfluxDBQuery.java
 ---
@@ -0,0 +1,199 @@
+/*
+ * 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.influxdb;
+import org.apache.nifi.annotation.behavior.EventDriven;
+import org.apache.nifi.annotation.behavior.InputRequirement;
+import org.apache.nifi.annotation.behavior.SupportsBatching;
+import org.apache.nifi.annotation.behavior.WritesAttribute;
+import org.apache.nifi.annotation.behavior.WritesAttributes;
+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.annotation.lifecycle.OnStopped;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.flowfile.FlowFile;
+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.influxdb.dto.Query;
+import org.influxdb.dto.QueryResult;
+import com.google.gson.Gson;
+import java.io.ByteArrayInputStream;
+import java.io.ByteArrayOutputStream;
+import java.net.SocketTimeoutException;
+import java.nio.charset.Charset;
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Map;
+import java.util.Set;
+import java.util.concurrent.TimeUnit;
+import java.util.stream.Collectors;
+
+@InputRequirement(InputRequirement.Requirement.INPUT_REQUIRED)
+@EventDriven
+@SupportsBatching
+@Tags({"influxdb", "measurement","get", "read", "query", "timeseries"})
+@CapabilityDescription("Processor to execute InfluxDB query from the 
content of a FlowFile.  Please check details of the supported queries in 
InfluxDB documentation (https://www.influxdb.com/).")
+@WritesAttributes({
+@WritesAttribute(attribute = 
AbstractInfluxDBProcessor.INFLUX_DB_ERROR_MESSAGE, description = "InfluxDB 
error message"),
+@WritesAttribute(attribute = 
ExecuteInfluxDBQuery.INFLUX_DB_EXECUTED_QUERY, description = "InfluxDB executed 
query"),
+})
+public class ExecuteInfluxDBQuery extends AbstractInfluxDBProcessor {
+
+public static final String INFLUX_DB_EXECUTED_QUERY = 
"influxdb.executed.query";
+
+public static final PropertyDescriptor INFLUX_DB_QUERY_RESULT_TIMEUNIT 
= new PropertyDescriptor.Builder()
+.name("influxdb-query-result-time-unit")
+.displayName("Query Result Time Units")
+.description("The time unit of query results from the 
InfluxDB")
+.defaultValue(TimeUnit.NANOSECONDS.name())
+.required(true)
+.expressionLanguageSupported(true)
+.allowableValues(Arrays.stream(TimeUnit.values()).map( v -> 
v.name()).collect(Collectors.toSet()))
+.sensitive(false)
+.build();
+
+static final Relationship REL_SUCCESS = new 
Relationship.Builder().name("success")
+.description("Successful InfluxDB queries are routed to this 
relationship").build();
+
+static final Relationship REL_FAILURE = new 
Relationship.Builder().name("failure")
+.description("Falied InfluxDB queries are routed to this 
relationship").build();
+
+static final Relationship REL_RETRY = new 
Relationship.Builder().name("retry")
+.description("Failed queries that are retryable exception are 
routed to this relationship").build();
+
+private static final Set relationships;
+private static final List 

[GitHub] nifi issue #2094: NIFI-4198 *ElasticsearchHttp processors do not expose Prox...

[mattyb149]

Github user mattyb149 commented on the issue:

https://github.com/apache/nifi/pull/2094
  
The code LGTM, but I am getting a 401 Unauthorized when trying to use my 
nginx proxy (with authentication). I put a debugger inside the 
proxyAuthenticator callback but it never gets called. I verified the proxy 
requires auth by using the browser to hit the proxy endpoint, it asks for 
user/pass then takes me to the base ES endpoint ("You know, for search"). I can 
hit other endpoints as well (individual docs, etc.) Any pointers on what I'm 
doing wrong?


---

[GitHub] nifi pull request #2581: NIFI-4864: Improvements to PR #2470

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/2581


---

[GitHub] nifi issue #2581: NIFI-4864: Improvements to PR #2470

[bbende]

Github user bbende commented on the issue:

https://github.com/apache/nifi/pull/2581
  
This looks good, verified it resolves the issue and is no longer reloading 
any components except those that have the classpath property descriptors, going 
to merge


---

[jira] [Commented] (NIFI-5008) Components are marked with the "restricted" red shield icon, but are not tagged as "restricted".

[Matt Gilman (JIRA)]

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

Matt Gilman commented on NIFI-5008:
---

https://github.com/apache/nifi/pull/2583

> Components are marked with the "restricted" red shield icon, but are not 
> tagged as "restricted".
> 
>
> Key: NIFI-5008
> URL: https://issues.apache.org/jira/browse/NIFI-5008
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Andrew Lim
>Assignee: Matt Gilman
>Priority: Minor
>
> Without the "restricted" tag, the components will not show up when filtering 
> by that tag.
> These are the components that need to have the "restricted" tag added:
>  
> *Processors:*
>  
> ExecuteGroovyScript
> GetHDFSSequenceFile
>  
> *Controller Services:*
>  
> KeytabCredentialsService
>  
> *Reporting Task:*
>  
> ScriptedReportingTask
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NIFI-5009) PutParquet processor requires "read filesystem" restricted component permission but should be "write filesystem" permission instead

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-5009:
--

GitHub user mcgilman opened a pull request:

https://github.com/apache/nifi/pull/2583

[NIFI-5009] [NIFI-5008]: Addressing restricted component annotations

NIFI-5009:
- Fixing required permission for PutParquet.

NIFI-5008:
- Ensuring all restricted components are tagged as such.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mcgilman/nifi NIFI-5009

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/2583.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2583


commit 085891e81aaf69040c81f0ad35a804ddaeb11f6e
Author: Matt Gilman 
Date:   2018-03-26T13:20:40Z

NIFI-5009:
- Fixing required permission for PutParquet.

NIFI-5008:
- Ensuring all restricted components are tagged as such.




> PutParquet processor requires "read filesystem" restricted component 
> permission but should be "write filesystem" permission instead
> ---
>
> Key: NIFI-5009
> URL: https://issues.apache.org/jira/browse/NIFI-5009
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework, Core UI
>Affects Versions: 1.6.0
>Reporter: Andrew Lim
>Assignee: Matt Gilman
>Priority: Minor
> Attachments: PutParquet_permission.jpg
>
>
> Similar to the other Put*** restricted processors, this is a write 
> processor, so it should require "write filesystem" permissions.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (NIFI-5009) PutParquet processor requires "read filesystem" restricted component permission but should be "write filesystem" permission instead

[Matt Gilman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-5009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Gilman updated NIFI-5009:
--
Status: Patch Available  (was: In Progress)

> PutParquet processor requires "read filesystem" restricted component 
> permission but should be "write filesystem" permission instead
> ---
>
> Key: NIFI-5009
> URL: https://issues.apache.org/jira/browse/NIFI-5009
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework, Core UI
>Affects Versions: 1.6.0
>Reporter: Andrew Lim
>Assignee: Matt Gilman
>Priority: Minor
> Attachments: PutParquet_permission.jpg
>
>
> Similar to the other Put*** restricted processors, this is a write 
> processor, so it should require "write filesystem" permissions.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (NIFI-5008) Components are marked with the "restricted" red shield icon, but are not tagged as "restricted".

[Matt Gilman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-5008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Gilman updated NIFI-5008:
--
Status: Patch Available  (was: In Progress)

> Components are marked with the "restricted" red shield icon, but are not 
> tagged as "restricted".
> 
>
> Key: NIFI-5008
> URL: https://issues.apache.org/jira/browse/NIFI-5008
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Andrew Lim
>Assignee: Matt Gilman
>Priority: Minor
>
> Without the "restricted" tag, the components will not show up when filtering 
> by that tag.
> These are the components that need to have the "restricted" tag added:
>  
> *Processors:*
>  
> ExecuteGroovyScript
> GetHDFSSequenceFile
>  
> *Controller Services:*
>  
> KeytabCredentialsService
>  
> *Reporting Task:*
>  
> ScriptedReportingTask
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (NIFI-5009) PutParquet processor requires "read filesystem" restricted component permission but should be "write filesystem" permission instead

[Matt Gilman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-5009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Gilman reassigned NIFI-5009:
-

Assignee: Matt Gilman

> PutParquet processor requires "read filesystem" restricted component 
> permission but should be "write filesystem" permission instead
> ---
>
> Key: NIFI-5009
> URL: https://issues.apache.org/jira/browse/NIFI-5009
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework, Core UI
>Affects Versions: 1.6.0
>Reporter: Andrew Lim
>Assignee: Matt Gilman
>Priority: Minor
> Attachments: PutParquet_permission.jpg
>
>
> Similar to the other Put*** restricted processors, this is a write 
> processor, so it should require "write filesystem" permissions.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (NIFI-5008) Components are marked with the "restricted" red shield icon, but are not tagged as "restricted".

[Matt Gilman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-5008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Gilman reassigned NIFI-5008:
-

Assignee: Matt Gilman

> Components are marked with the "restricted" red shield icon, but are not 
> tagged as "restricted".
> 
>
> Key: NIFI-5008
> URL: https://issues.apache.org/jira/browse/NIFI-5008
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Andrew Lim
>Assignee: Matt Gilman
>Priority: Minor
>
> Without the "restricted" tag, the components will not show up when filtering 
> by that tag.
> These are the components that need to have the "restricted" tag added:
>  
> *Processors:*
>  
> ExecuteGroovyScript
> GetHDFSSequenceFile
>  
> *Controller Services:*
>  
> KeytabCredentialsService
>  
> *Reporting Task:*
>  
> ScriptedReportingTask
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] nifi pull request #2583: [NIFI-5009] [NIFI-5008]: Addressing restricted comp...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/2583


---