[jira] [Commented] (NIFI-1170) TailFile "File to Tail" property should support Wildcards

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-1170:
--

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

https://github.com/apache/nifi/pull/980#discussion_r78673963
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/TailFile.java
 ---
@@ -117,31 +173,78 @@
 .allowableValues(LOCATION_LOCAL, LOCATION_REMOTE)
 .defaultValue(LOCATION_LOCAL.getValue())
 .build();
+
 static final PropertyDescriptor START_POSITION = new 
PropertyDescriptor.Builder()
 .name("Initial Start Position")
-.description("When the Processor first begins to tail data, 
this property specifies where the Processor should begin reading data. Once 
data has been ingested from the file, "
+.description("When the Processor first begins to tail data, 
this property specifies where the Processor should begin reading data. Once 
data has been ingested from a file, "
 + "the Processor will continue from the last point 
from which it has received data.")
 .allowableValues(START_BEGINNING_OF_TIME, START_CURRENT_FILE, 
START_CURRENT_TIME)
 .defaultValue(START_CURRENT_FILE.getValue())
 .required(true)
 .build();
 
+static final PropertyDescriptor RECURSIVE = new 
PropertyDescriptor.Builder()
+.name("tailfile-recursive-lookup")
+.displayName("Recursive lookup")
+.description("When using Multiple files mode, this property 
defines if files must be listed recursively or not"
++ " in the base directory.")
+.allowableValues("true", "false")
+.defaultValue("true")
+.required(true)
+.build();
+
+static final PropertyDescriptor ROLLING_STRATEGY = new 
PropertyDescriptor.Builder()
+.name("tailfile-rolling-strategy")
+.displayName("Rolling Strategy")
+.description("Specifies if the files to tail have a fixed name 
or not.")
+.required(true)
+.allowableValues(FIXED_NAME, CHANGING_NAME)
+.defaultValue(FIXED_NAME.getValue())
+.build();
+
+static final PropertyDescriptor LOOKUP_FREQUENCY = new 
PropertyDescriptor.Builder()
+.name("tailfile-lookup-frequency")
+.displayName("Lookup frequency")
+.description("Only used in Multiple files mode and Changing 
name rolling strategy, it specifies the minimum "
++ "duration the processor will wait before listing 
again the files to tail.")
+.required(false)
+.addValidator(StandardValidators.TIME_PERIOD_VALIDATOR)
+.defaultValue("10 minutes")
--- End diff --

some finite value you think is reasonable is great.  10 mins sounds good.


> TailFile "File to Tail" property should support Wildcards
> -
>
> Key: NIFI-1170
> URL: https://issues.apache.org/jira/browse/NIFI-1170
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 0.4.0
>Reporter: Andre
>
> Because of challenges around log rotation of high volume syslog and app 
> producers, it is customary to logging platform developers to promote file 
> variables based file names such as DynaFiles (rsyslog), Macros(syslog-ng)as 
> alternatives to getting SIGHUPs being sent to the syslog daemon upon every 
> file rotation.
> (To certain extent, used even NiFi's has similar patterns, like for example, 
> when one uses Expression Language to set PutHDFS destination file).
> The current TailFile strategy suggests rotation patterns like:
> {code}
> log_folder/app.log
> log_folder/app.log.1
> log_folder/app.log.2
> log_folder/app.log.3
> {code}
> It is possible to fool the system to accept wildcards by simply using a 
> strategy like:
> {code}
> log_folder/test1
> log_folder/server1
> log_folder/server2
> log_folder/server3
> {code}
> And configure *Rolling Filename Pattern* to * but it feels like a hack, 
> rather than catering for an ever increasingly prevalent use case 
> (DynaFile/macros/etc).
> It would be great if instead, TailFile had the ability to use wildcards on 
> File to Tail property



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #980: NIFI-1170 - Improved TailFile processor to support m...

[joewitt]

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

https://github.com/apache/nifi/pull/980#discussion_r78673963
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/TailFile.java
 ---
@@ -117,31 +173,78 @@
 .allowableValues(LOCATION_LOCAL, LOCATION_REMOTE)
 .defaultValue(LOCATION_LOCAL.getValue())
 .build();
+
 static final PropertyDescriptor START_POSITION = new 
PropertyDescriptor.Builder()
 .name("Initial Start Position")
-.description("When the Processor first begins to tail data, 
this property specifies where the Processor should begin reading data. Once 
data has been ingested from the file, "
+.description("When the Processor first begins to tail data, 
this property specifies where the Processor should begin reading data. Once 
data has been ingested from a file, "
 + "the Processor will continue from the last point 
from which it has received data.")
 .allowableValues(START_BEGINNING_OF_TIME, START_CURRENT_FILE, 
START_CURRENT_TIME)
 .defaultValue(START_CURRENT_FILE.getValue())
 .required(true)
 .build();
 
+static final PropertyDescriptor RECURSIVE = new 
PropertyDescriptor.Builder()
+.name("tailfile-recursive-lookup")
+.displayName("Recursive lookup")
+.description("When using Multiple files mode, this property 
defines if files must be listed recursively or not"
++ " in the base directory.")
+.allowableValues("true", "false")
+.defaultValue("true")
+.required(true)
+.build();
+
+static final PropertyDescriptor ROLLING_STRATEGY = new 
PropertyDescriptor.Builder()
+.name("tailfile-rolling-strategy")
+.displayName("Rolling Strategy")
+.description("Specifies if the files to tail have a fixed name 
or not.")
+.required(true)
+.allowableValues(FIXED_NAME, CHANGING_NAME)
+.defaultValue(FIXED_NAME.getValue())
+.build();
+
+static final PropertyDescriptor LOOKUP_FREQUENCY = new 
PropertyDescriptor.Builder()
+.name("tailfile-lookup-frequency")
+.displayName("Lookup frequency")
+.description("Only used in Multiple files mode and Changing 
name rolling strategy, it specifies the minimum "
++ "duration the processor will wait before listing 
again the files to tail.")
+.required(false)
+.addValidator(StandardValidators.TIME_PERIOD_VALIDATOR)
+.defaultValue("10 minutes")
--- End diff --

some finite value you think is reasonable is great.  10 mins sounds good.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (NIFI-2772) Unsecure RAW Site-to-Site fails with User DN is not known

[Koji Kawamura (JIRA)]

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

Koji Kawamura updated NIFI-2772:

Status: Patch Available  (was: Open)

> Unsecure RAW Site-to-Site fails with User DN is not known
> -
>
> Key: NIFI-2772
> URL: https://issues.apache.org/jira/browse/NIFI-2772
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.1.0
>Reporter: Koji Kawamura
>Assignee: Koji Kawamura
>Priority: Blocker
> Fix For: 1.1.0
>
>
> If Site-to-Site is configured unsecure (nifi.remote.input.secure=false), then 
> Site-to-Site client using RAW transport protocol fails with following error:
> {code}
> [main] ERROR org.apache.nifi.remote.client.socket.EndpointConnectionPool - 
> EndpointConnectionPool[Cluster URL=http://localhost:9444/nifi] failed to 
> communicate with Peer[url=nifi://localhost:10444,CLOSED] due to 
> org.apache.nifi.remote.exception.HandshakeException: Received unexpected 
> response User Not Authorized: User DN is not known
> [main] ERROR org.apache.nifi.remote.client.socket.EndpointConnectionPool - 
> org.apache.nifi.remote.exception.HandshakeException: Received unexpected 
> response User Not Authorized: User DN is not known
>   at 
> org.apache.nifi.remote.protocol.socket.SocketClientProtocol.handshake(SocketClientProtocol.java:179)
>   at 
> org.apache.nifi.remote.protocol.socket.SocketClientProtocol.handshake(SocketClientProtocol.java:105)
>   at 
> org.apache.nifi.remote.client.socket.EndpointConnectionPool.getEndpointConnection(EndpointConnectionPool.java:240)
>   at 
> org.apache.nifi.remote.client.socket.SocketClient.createTransaction(SocketClient.java:127)
> {code}
> This is a regression caused by NIFI-2718.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2772) Unsecure RAW Site-to-Site fails with User DN is not known

[Koji Kawamura (JIRA)]

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

Koji Kawamura updated NIFI-2772:

Description: 
If Site-to-Site is configured unsecure (nifi.remote.input.secure=false), then 
Site-to-Site client using RAW transport protocol fails with following error:

{code}
[main] ERROR org.apache.nifi.remote.client.socket.EndpointConnectionPool - 
EndpointConnectionPool[Cluster URL=http://localhost:9444/nifi] failed to 
communicate with Peer[url=nifi://localhost:10444,CLOSED] due to 
org.apache.nifi.remote.exception.HandshakeException: Received unexpected 
response User Not Authorized: User DN is not known
[main] ERROR org.apache.nifi.remote.client.socket.EndpointConnectionPool - 
org.apache.nifi.remote.exception.HandshakeException: Received unexpected 
response User Not Authorized: User DN is not known
at 
org.apache.nifi.remote.protocol.socket.SocketClientProtocol.handshake(SocketClientProtocol.java:179)
at 
org.apache.nifi.remote.protocol.socket.SocketClientProtocol.handshake(SocketClientProtocol.java:105)
at 
org.apache.nifi.remote.client.socket.EndpointConnectionPool.getEndpointConnection(EndpointConnectionPool.java:240)
at 
org.apache.nifi.remote.client.socket.SocketClient.createTransaction(SocketClient.java:127)
{code}

This is a regression caused by NIFI-2718.

> Unsecure RAW Site-to-Site fails with User DN is not known
> -
>
> Key: NIFI-2772
> URL: https://issues.apache.org/jira/browse/NIFI-2772
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.1.0
>Reporter: Koji Kawamura
>Assignee: Koji Kawamura
>Priority: Blocker
> Fix For: 1.1.0
>
>
> If Site-to-Site is configured unsecure (nifi.remote.input.secure=false), then 
> Site-to-Site client using RAW transport protocol fails with following error:
> {code}
> [main] ERROR org.apache.nifi.remote.client.socket.EndpointConnectionPool - 
> EndpointConnectionPool[Cluster URL=http://localhost:9444/nifi] failed to 
> communicate with Peer[url=nifi://localhost:10444,CLOSED] due to 
> org.apache.nifi.remote.exception.HandshakeException: Received unexpected 
> response User Not Authorized: User DN is not known
> [main] ERROR org.apache.nifi.remote.client.socket.EndpointConnectionPool - 
> org.apache.nifi.remote.exception.HandshakeException: Received unexpected 
> response User Not Authorized: User DN is not known
>   at 
> org.apache.nifi.remote.protocol.socket.SocketClientProtocol.handshake(SocketClientProtocol.java:179)
>   at 
> org.apache.nifi.remote.protocol.socket.SocketClientProtocol.handshake(SocketClientProtocol.java:105)
>   at 
> org.apache.nifi.remote.client.socket.EndpointConnectionPool.getEndpointConnection(EndpointConnectionPool.java:240)
>   at 
> org.apache.nifi.remote.client.socket.SocketClient.createTransaction(SocketClient.java:127)
> {code}
> This is a regression caused by NIFI-2718.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2772) Unsecure RAW Site-to-Site fails with User DN is not known

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2772:
--

GitHub user ijokarumawak opened a pull request:

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

NIFI-2772: Unsecure RAW Site-to-Site fails with User DN is not known



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

$ git pull https://github.com/ijokarumawak/nifi nifi-2772

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

https://github.com/apache/nifi/pull/1019.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 #1019


commit 6b7266cc3e0a2aecdbb0a70b486c5adf598f36a9
Author: Koji Kawamura 
Date:   2016-09-14T00:36:46Z

NIFI-2772: Unsecure RAW Site-to-Site fails with User DN is not known




> Unsecure RAW Site-to-Site fails with User DN is not known
> -
>
> Key: NIFI-2772
> URL: https://issues.apache.org/jira/browse/NIFI-2772
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.1.0
>Reporter: Koji Kawamura
>Assignee: Koji Kawamura
>Priority: Blocker
> Fix For: 1.1.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #1019: NIFI-2772: Unsecure RAW Site-to-Site fails with Use...

[ijokarumawak]

GitHub user ijokarumawak opened a pull request:

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

NIFI-2772: Unsecure RAW Site-to-Site fails with User DN is not known



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

$ git pull https://github.com/ijokarumawak/nifi nifi-2772

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

https://github.com/apache/nifi/pull/1019.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 #1019


commit 6b7266cc3e0a2aecdbb0a70b486c5adf598f36a9
Author: Koji Kawamura 
Date:   2016-09-14T00:36:46Z

NIFI-2772: Unsecure RAW Site-to-Site fails with User DN is not known




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (NIFI-2772) Unsecure RAW Site-to-Site fails with User DN is not known

[Koji Kawamura (JIRA)]

Koji Kawamura created NIFI-2772:
---

 Summary: Unsecure RAW Site-to-Site fails with User DN is not known
 Key: NIFI-2772
 URL: https://issues.apache.org/jira/browse/NIFI-2772
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework
Affects Versions: 1.1.0
Reporter: Koji Kawamura
Assignee: Koji Kawamura
Priority: Blocker
 Fix For: 1.1.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-1170) TailFile "File to Tail" property should support Wildcards

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-1170:
--

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

https://github.com/apache/nifi/pull/980#discussion_r78652271
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/TailFile.java
 ---
@@ -117,31 +173,78 @@
 .allowableValues(LOCATION_LOCAL, LOCATION_REMOTE)
 .defaultValue(LOCATION_LOCAL.getValue())
 .build();
+
 static final PropertyDescriptor START_POSITION = new 
PropertyDescriptor.Builder()
 .name("Initial Start Position")
-.description("When the Processor first begins to tail data, 
this property specifies where the Processor should begin reading data. Once 
data has been ingested from the file, "
+.description("When the Processor first begins to tail data, 
this property specifies where the Processor should begin reading data. Once 
data has been ingested from a file, "
 + "the Processor will continue from the last point 
from which it has received data.")
 .allowableValues(START_BEGINNING_OF_TIME, START_CURRENT_FILE, 
START_CURRENT_TIME)
 .defaultValue(START_CURRENT_FILE.getValue())
 .required(true)
 .build();
 
+static final PropertyDescriptor RECURSIVE = new 
PropertyDescriptor.Builder()
+.name("tailfile-recursive-lookup")
+.displayName("Recursive lookup")
+.description("When using Multiple files mode, this property 
defines if files must be listed recursively or not"
++ " in the base directory.")
+.allowableValues("true", "false")
+.defaultValue("true")
+.required(true)
+.build();
+
+static final PropertyDescriptor ROLLING_STRATEGY = new 
PropertyDescriptor.Builder()
+.name("tailfile-rolling-strategy")
+.displayName("Rolling Strategy")
+.description("Specifies if the files to tail have a fixed name 
or not.")
+.required(true)
+.allowableValues(FIXED_NAME, CHANGING_NAME)
+.defaultValue(FIXED_NAME.getValue())
+.build();
+
+static final PropertyDescriptor LOOKUP_FREQUENCY = new 
PropertyDescriptor.Builder()
+.name("tailfile-lookup-frequency")
+.displayName("Lookup frequency")
+.description("Only used in Multiple files mode and Changing 
name rolling strategy, it specifies the minimum "
++ "duration the processor will wait before listing 
again the files to tail.")
+.required(false)
+.addValidator(StandardValidators.TIME_PERIOD_VALIDATOR)
+.defaultValue("10 minutes")
--- End diff --

In my mind the lookup frequency would depend on the rolling configuration 
of the log files. Let's say there is a daily rollover, then the lookup 
frequency could be something like one hour (in fact the maximum duration the 
user is ready to wait before receiving log messages from a fresh new file). On 
the other side, the maximum age duration is the time we need to wait after the 
last received message in a log file before considering there won't be any more 
message in this file and that we can "forget" about its state (and if it 
happens that we do receive new messages, then we will duplicate data). With a 
daily rollover, it could be 24h.

If we set the lookup frequency to infinity, it means that only the files 
that exist when the processor is started will be considered. I don't know if 
it's really what we want for the user to be the default, don't you think?

On the other hand, I could agree that for the maximum age we set it to 
infinity by default to ensure there is no data duplication unless the user is 
overriding the property. But in any case, how would you set a default value to 
infinity in the property descriptor configuration? ``.defaultValue()`` is 
expecting a String, so I'm not sure to see how you would use Max Long in 
combination with the time period validator. Otherwise, I could use the standard 
'0' to represent this case. Let me know what you think.


> TailFile "File to Tail" property should support Wildcards
> -
>
> Key: NIFI-1170
> URL: https://issues.apache.org/jira/browse/NIFI-1170
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 0.4.0
>Reporter: Andre
>
> Because of 

[GitHub] nifi pull request #980: NIFI-1170 - Improved TailFile processor to support m...

[pvillard31]

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

https://github.com/apache/nifi/pull/980#discussion_r78652271
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/TailFile.java
 ---
@@ -117,31 +173,78 @@
 .allowableValues(LOCATION_LOCAL, LOCATION_REMOTE)
 .defaultValue(LOCATION_LOCAL.getValue())
 .build();
+
 static final PropertyDescriptor START_POSITION = new 
PropertyDescriptor.Builder()
 .name("Initial Start Position")
-.description("When the Processor first begins to tail data, 
this property specifies where the Processor should begin reading data. Once 
data has been ingested from the file, "
+.description("When the Processor first begins to tail data, 
this property specifies where the Processor should begin reading data. Once 
data has been ingested from a file, "
 + "the Processor will continue from the last point 
from which it has received data.")
 .allowableValues(START_BEGINNING_OF_TIME, START_CURRENT_FILE, 
START_CURRENT_TIME)
 .defaultValue(START_CURRENT_FILE.getValue())
 .required(true)
 .build();
 
+static final PropertyDescriptor RECURSIVE = new 
PropertyDescriptor.Builder()
+.name("tailfile-recursive-lookup")
+.displayName("Recursive lookup")
+.description("When using Multiple files mode, this property 
defines if files must be listed recursively or not"
++ " in the base directory.")
+.allowableValues("true", "false")
+.defaultValue("true")
+.required(true)
+.build();
+
+static final PropertyDescriptor ROLLING_STRATEGY = new 
PropertyDescriptor.Builder()
+.name("tailfile-rolling-strategy")
+.displayName("Rolling Strategy")
+.description("Specifies if the files to tail have a fixed name 
or not.")
+.required(true)
+.allowableValues(FIXED_NAME, CHANGING_NAME)
+.defaultValue(FIXED_NAME.getValue())
+.build();
+
+static final PropertyDescriptor LOOKUP_FREQUENCY = new 
PropertyDescriptor.Builder()
+.name("tailfile-lookup-frequency")
+.displayName("Lookup frequency")
+.description("Only used in Multiple files mode and Changing 
name rolling strategy, it specifies the minimum "
++ "duration the processor will wait before listing 
again the files to tail.")
+.required(false)
+.addValidator(StandardValidators.TIME_PERIOD_VALIDATOR)
+.defaultValue("10 minutes")
--- End diff --

In my mind the lookup frequency would depend on the rolling configuration 
of the log files. Let's say there is a daily rollover, then the lookup 
frequency could be something like one hour (in fact the maximum duration the 
user is ready to wait before receiving log messages from a fresh new file). On 
the other side, the maximum age duration is the time we need to wait after the 
last received message in a log file before considering there won't be any more 
message in this file and that we can "forget" about its state (and if it 
happens that we do receive new messages, then we will duplicate data). With a 
daily rollover, it could be 24h.

If we set the lookup frequency to infinity, it means that only the files 
that exist when the processor is started will be considered. I don't know if 
it's really what we want for the user to be the default, don't you think?

On the other hand, I could agree that for the maximum age we set it to 
infinity by default to ensure there is no data duplication unless the user is 
overriding the property. But in any case, how would you set a default value to 
infinity in the property descriptor configuration? ``.defaultValue()`` is 
expecting a String, so I'm not sure to see how you would use Max Long in 
combination with the time period validator. Otherwise, I could use the standard 
'0' to represent this case. Let me know what you think.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-1662) Improve Expression Language to Enable Working with Decimals

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-1662:
--

GitHub user JPercivall opened a pull request:

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

NIFI-1662 adding Expression Language decimal support



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

$ git pull https://github.com/JPercivall/nifi NIFI-1662-2

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

https://github.com/apache/nifi/pull/1018.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 #1018


commit 6b6370ae1386279438bca05a2f65f7bd9d50cda9
Author: jpercivall 
Date:   2016-09-13T21:40:58Z

NIFI-1662 adding Expression Language decimal support




> Improve Expression Language to Enable Working with Decimals
> ---
>
> Key: NIFI-1662
> URL: https://issues.apache.org/jira/browse/NIFI-1662
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Joseph Percivall
>Assignee: Joseph Percivall
>
> Currently the math operations in Expression Language use Longs to evaluate 
> numbers. This leads to any decimal places getting truncated when performing 
> operations like divide. 
> EL should be improved to enable the user to evaluate math expressions using 
> doubles.
> Another desired portion of this would be to open up the static Math class [1] 
> methods (using reflection) to further enable working with Decimals.
> [1] https://docs.oracle.com/javase/7/docs/api/java/lang/Math.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #1018: NIFI-1662 adding Expression Language decimal suppor...

[JPercivall]

GitHub user JPercivall opened a pull request:

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

NIFI-1662 adding Expression Language decimal support



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

$ git pull https://github.com/JPercivall/nifi NIFI-1662-2

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

https://github.com/apache/nifi/pull/1018.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 #1018


commit 6b6370ae1386279438bca05a2f65f7bd9d50cda9
Author: jpercivall 
Date:   2016-09-13T21:40:58Z

NIFI-1662 adding Expression Language decimal support




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi issue #999: NIFI-2266 Enabled TLSv1.1 and TLSv1.2 protocols for GetHTTP...

[alopresto]

Github user alopresto commented on the issue:

https://github.com/apache/nifi/pull/999
  
And, of course, as soon as I comment, it hits me -- `GetHTTP`, unlike 
`PostHTTP`, does not require a flowfile input in order to execute. So when I 
copied the tests I had written for `PostHTTP`, I needed to either remove the 
`enqueue` action of the message content prior to running, or assert that 2 
flowfiles succeeded (the one manually enqueued and the result of the `GET` 
call). I think the current code is correct and successful, but if desired, I 
can push my latest changes which remove the manual enqueuing and assert 
explicitly 1 flowfile succeeded. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2266) GetHTTP and PutHTTP use hard-coded TLS protocol version

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2266:
--

Github user alopresto commented on the issue:

https://github.com/apache/nifi/pull/999
  
And, of course, as soon as I comment, it hits me -- `GetHTTP`, unlike 
`PostHTTP`, does not require a flowfile input in order to execute. So when I 
copied the tests I had written for `PostHTTP`, I needed to either remove the 
`enqueue` action of the message content prior to running, or assert that 2 
flowfiles succeeded (the one manually enqueued and the result of the `GET` 
call). I think the current code is correct and successful, but if desired, I 
can push my latest changes which remove the manual enqueuing and assert 
explicitly 1 flowfile succeeded. 


> GetHTTP and PutHTTP use hard-coded TLS protocol version
> ---
>
> Key: NIFI-2266
> URL: https://issues.apache.org/jira/browse/NIFI-2266
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 0.7.0, 0.6.1
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>  Labels: https, security, tls
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> As pointed out on the mailing list [1], the {{GetHTTP}} (and likely 
> {{PutHTTP}}) processors use a hard-coded TLS protocol version. {{PostHTTP}} 
> also did this and was fixed by [NIFI-1688]. 
> The same fix should apply here and unit tests already exist which can be 
> applied to the other processors as well. 
> For future notice, {{InvokeHTTP}} is a better processor for generic HTTP 
> operations and has supported reading the TLS protocol version from the 
> {{SSLContextService}} for some time. 
> [1] 
> https://lists.apache.org/thread.html/a48e2ebbc2231d685491ae6b856c760620efca5bff2c7249f915b24d@%3Cdev.nifi.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #999: NIFI-2266 Enabled TLSv1.1 and TLSv1.2 protocols for GetHTTP...

[alopresto]

Github user alopresto commented on the issue:

https://github.com/apache/nifi/pull/999
  
@pvillard31 and @mosermw , thanks for noting that. When I re-ran locally, I 
encountered the same issue. I have resolved it, but not to my complete 
satisfaction. The test now accepts that _n_ flowfiles were routed to 
`REL_SUCCESS` instead of _1_ explicitly. As the tests are simply concerned with 
the TLS protocol version used for the communication, this seems a sufficient 
fix. However, I am confused, because it appears from the logs and debugging 
that the test runner "finds" a mock flowfile in the queue even if I assert 
immediately before enqueuing any message that the queue is empty. 

I'll continue investigating, but I did want to push this fix so at least 
the tests pass for anyone reviewing it. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2266) GetHTTP and PutHTTP use hard-coded TLS protocol version

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2266:
--

Github user alopresto commented on the issue:

https://github.com/apache/nifi/pull/999
  
@pvillard31 and @mosermw , thanks for noting that. When I re-ran locally, I 
encountered the same issue. I have resolved it, but not to my complete 
satisfaction. The test now accepts that _n_ flowfiles were routed to 
`REL_SUCCESS` instead of _1_ explicitly. As the tests are simply concerned with 
the TLS protocol version used for the communication, this seems a sufficient 
fix. However, I am confused, because it appears from the logs and debugging 
that the test runner "finds" a mock flowfile in the queue even if I assert 
immediately before enqueuing any message that the queue is empty. 

I'll continue investigating, but I did want to push this fix so at least 
the tests pass for anyone reviewing it. 


> GetHTTP and PutHTTP use hard-coded TLS protocol version
> ---
>
> Key: NIFI-2266
> URL: https://issues.apache.org/jira/browse/NIFI-2266
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 0.7.0, 0.6.1
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>  Labels: https, security, tls
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> As pointed out on the mailing list [1], the {{GetHTTP}} (and likely 
> {{PutHTTP}}) processors use a hard-coded TLS protocol version. {{PostHTTP}} 
> also did this and was fixed by [NIFI-1688]. 
> The same fix should apply here and unit tests already exist which can be 
> applied to the other processors as well. 
> For future notice, {{InvokeHTTP}} is a better processor for generic HTTP 
> operations and has supported reading the TLS protocol version from the 
> {{SSLContextService}} for some time. 
> [1] 
> https://lists.apache.org/thread.html/a48e2ebbc2231d685491ae6b856c760620efca5bff2c7249f915b24d@%3Cdev.nifi.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2763) S3 processors do not work with older S3-compatible object stores

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2763:
--

Github user jvwing commented on the issue:

https://github.com/apache/nifi/pull/1008
  
@baank , what would you think about moving the PropertyDescriptor and the 
configuration code to the AbstractS3Processor class rather than 
AWSAbstractProcessor?


> S3 processors do not work with older S3-compatible object stores
> 
>
> Key: NIFI-2763
> URL: https://issues.apache.org/jira/browse/NIFI-2763
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0
>Reporter: Franco
>  Labels: easyfix
> Fix For: 1.1.0
>
>
> In the 1.0.0 release of NiFi it is using the AWS library for connecting to S3 
> and S3-compatible object stores.
> This library by default expects V4 signer support which if you are using an 
> older object store will not be available and so NiFi will be unusable.
> The fix is simple:
> Allow the user to specify (if they wish) the signer type that AWS library 
> should use.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #1008: NIFI-2763 S3 processors do not work with older S3-compatib...

[jvwing]

Github user jvwing commented on the issue:

https://github.com/apache/nifi/pull/1008
  
@baank , what would you think about moving the PropertyDescriptor and the 
configuration code to the AbstractS3Processor class rather than 
AWSAbstractProcessor?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (NIFI-2752) Correct ReplaceText default pattern and unit tests

[Pierre Villard (JIRA)]

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

Pierre Villard updated NIFI-2752:
-
   Resolution: Fixed
Fix Version/s: 1.1.0
   Status: Resolved  (was: Patch Available)

Full build with contrib-check. Tested fix. +1
Merged to master.
[~jskora] I don't feel it is supposed to go into 0.x, let me know if it should.

> Correct ReplaceText default pattern and unit tests
> --
>
> Key: NIFI-2752
> URL: https://issues.apache.org/jira/browse/NIFI-2752
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.1.0, 0.8.0, 0.7.1
>Reporter: Joe Skora
>Assignee: Joe Skora
> Fix For: 1.1.0
>
>
> [{{ReplaceText.DEFAULT_REGEX}}|https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/ReplaceText.java#L87]
>  is defined as "(?s:\^.\*$)", which is valid PCRE but must be expressed as 
> "(?s)(\^.\*$)" in Java.
> The Java [Pattern class|https://docs.oracle.com/javase/8/docs/api/index.html] 
> specifies that patterns like "(?idmsux-idmsux:X)" are _non-capturing_, so 
> anything but the default pattern and replacement value result in empty 
> output.  This isn't caught by unit tests because the code short circuits if 
> the default pattern and replacement are found in 
> [ReplaceText.onTrigger()|https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/ReplaceText.java#L217].
>   This hides the capture group problem from the unit tests and the default 
> processor configuration, but causes the processor to produce empty output if 
> using non-trivial patterns and replacements.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2752) Correct ReplaceText default pattern and unit tests

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2752:
--

Github user asfgit closed the pull request at:

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


> Correct ReplaceText default pattern and unit tests
> --
>
> Key: NIFI-2752
> URL: https://issues.apache.org/jira/browse/NIFI-2752
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.1.0, 0.8.0, 0.7.1
>Reporter: Joe Skora
>Assignee: Joe Skora
>
> [{{ReplaceText.DEFAULT_REGEX}}|https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/ReplaceText.java#L87]
>  is defined as "(?s:\^.\*$)", which is valid PCRE but must be expressed as 
> "(?s)(\^.\*$)" in Java.
> The Java [Pattern class|https://docs.oracle.com/javase/8/docs/api/index.html] 
> specifies that patterns like "(?idmsux-idmsux:X)" are _non-capturing_, so 
> anything but the default pattern and replacement value result in empty 
> output.  This isn't caught by unit tests because the code short circuits if 
> the default pattern and replacement are found in 
> [ReplaceText.onTrigger()|https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/ReplaceText.java#L217].
>   This hides the capture group problem from the unit tests and the default 
> processor configuration, but causes the processor to produce empty output if 
> using non-trivial patterns and replacements.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #1007: NIFI-2752 Correct ReplaceText default pattern and u...

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2752) Correct ReplaceText default pattern and unit tests

[ASF subversion and git services (JIRA)]

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

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

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

NIFI-2752 Correct ReplaceText default pattern and unit tests
 * Corrected the DEFAULT_REGEX pattern.
 * Added tests to isolate regex capture group problem and verify corrected 
functionality.
 * Removed short circuit logic that masked configuration errors and created 
inconsistent processor behavior.

This closes #1007.


> Correct ReplaceText default pattern and unit tests
> --
>
> Key: NIFI-2752
> URL: https://issues.apache.org/jira/browse/NIFI-2752
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.1.0, 0.8.0, 0.7.1
>Reporter: Joe Skora
>Assignee: Joe Skora
>
> [{{ReplaceText.DEFAULT_REGEX}}|https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/ReplaceText.java#L87]
>  is defined as "(?s:\^.\*$)", which is valid PCRE but must be expressed as 
> "(?s)(\^.\*$)" in Java.
> The Java [Pattern class|https://docs.oracle.com/javase/8/docs/api/index.html] 
> specifies that patterns like "(?idmsux-idmsux:X)" are _non-capturing_, so 
> anything but the default pattern and replacement value result in empty 
> output.  This isn't caught by unit tests because the code short circuits if 
> the default pattern and replacement are found in 
> [ReplaceText.onTrigger()|https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/ReplaceText.java#L217].
>   This hides the capture group problem from the unit tests and the default 
> processor configuration, but causes the processor to produce empty output if 
> using non-trivial patterns and replacements.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (NIFI-1944) Use GzipHandler instead of GzipFilter

[Matt Gilman (JIRA)]

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

Matt Gilman resolved NIFI-1944.
---
Resolution: Duplicate

> Use GzipHandler instead of GzipFilter
> -
>
> Key: NIFI-1944
> URL: https://issues.apache.org/jira/browse/NIFI-1944
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Matt Gilman
>Priority: Minor
>
> From the app log...
> {noformat}
> 2016-05-31 12:32:31,507 WARN [main] o.eclipse.jetty.util.DeprecationWarning 
> Using @Deprecated Class org.eclipse.jetty.servlets.GzipFilter
> 2016-05-31 12:32:31,510 WARN [main] org.eclipse.jetty.servlets.GzipFilter 
> GzipFilter is deprecated. Use GzipHandler
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (NIFI-2771) REST API does not compress responses

[Matt Gilman (JIRA)]

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

Matt Gilman reassigned NIFI-2771:
-

Assignee: Matt Gilman

> REST API does not compress responses
> 
>
> Key: NIFI-2771
> URL: https://issues.apache.org/jira/browse/NIFI-2771
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Mark Payne
>Assignee: Matt Gilman
>Priority: Critical
> Fix For: 1.1.0
>
>
> Responses from the REST API do not appear to be compressed. In the logs, we 
> see warnings:
> 2016-09-13 15:22:23,124 WARN [main] o.eclipse.jetty.util.DeprecationWarning 
> Using @Deprecated Class org.eclipse.jetty.servlets.GzipFilter
> 2016-09-13 15:22:23,124 WARN [main] org.eclipse.jetty.servlets.GzipFilter 
> GzipFilter is deprecated. Use GzipHandler



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2770) flow configuration history action details dialog only shows UUID

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2770:
--

Github user asfgit closed the pull request at:

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


> flow configuration history action details dialog only shows UUID
> 
>
> Key: NIFI-2770
> URL: https://issues.apache.org/jira/browse/NIFI-2770
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Scott Aslan
>Assignee: Scott Aslan
> Fix For: 1.1.0
>
>
> In the NiFi history shell when I click to view details on a particular event 
> the action details dialog just shows the uuid of the component and no actual 
> details



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2770) flow configuration history action details dialog only shows UUID

[Pierre Villard (JIRA)]

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

Pierre Villard updated NIFI-2770:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Merged to master.

> flow configuration history action details dialog only shows UUID
> 
>
> Key: NIFI-2770
> URL: https://issues.apache.org/jira/browse/NIFI-2770
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Scott Aslan
>Assignee: Scott Aslan
> Fix For: 1.1.0
>
>
> In the NiFi history shell when I click to view details on a particular event 
> the action details dialog just shows the uuid of the component and no actual 
> details



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2770) flow configuration history action details dialog only shows UUID

[ASF subversion and git services (JIRA)]

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

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

Commit 02ca2a0d78fe5189a3fb220ee7c8409737e26c18 in nifi's branch 
refs/heads/master from [~scottyaslan]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=02ca2a0 ]

[NIFI-2770] fix action details dialog

This closes #1017.


> flow configuration history action details dialog only shows UUID
> 
>
> Key: NIFI-2770
> URL: https://issues.apache.org/jira/browse/NIFI-2770
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Scott Aslan
>Assignee: Scott Aslan
> Fix For: 1.1.0
>
>
> In the NiFi history shell when I click to view details on a particular event 
> the action details dialog just shows the uuid of the component and no actual 
> details



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #1017: [NIFI-2770] fix action details dialog

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2763) S3 processors do not work with older S3-compatible object stores

[James Wing (JIRA)]

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

James Wing commented on NIFI-2763:
--

May I ask which object store you are using?  Which AWS signature version is 
compatible for you?

> S3 processors do not work with older S3-compatible object stores
> 
>
> Key: NIFI-2763
> URL: https://issues.apache.org/jira/browse/NIFI-2763
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0
>Reporter: Franco
>  Labels: easyfix
> Fix For: 1.1.0
>
>
> In the 1.0.0 release of NiFi it is using the AWS library for connecting to S3 
> and S3-compatible object stores.
> This library by default expects V4 signer support which if you are using an 
> older object store will not be available and so NiFi will be unusable.
> The fix is simple:
> Allow the user to specify (if they wish) the signer type that AWS library 
> should use.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2770) flow configuration history action details dialog only shows UUID

[Scott Aslan (JIRA)]

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

Scott Aslan updated NIFI-2770:
--
Status: Patch Available  (was: In Progress)

> flow configuration history action details dialog only shows UUID
> 
>
> Key: NIFI-2770
> URL: https://issues.apache.org/jira/browse/NIFI-2770
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Scott Aslan
>Assignee: Scott Aslan
> Fix For: 1.1.0
>
>
> In the NiFi history shell when I click to view details on a particular event 
> the action details dialog just shows the uuid of the component and no actual 
> details



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2771) REST API does not compress responses

[Matt Gilman (JIRA)]

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

Matt Gilman commented on NIFI-2771:
---

Looks like the deprecated GzipFilter actually removes the compression 
capabilities.

> REST API does not compress responses
> 
>
> Key: NIFI-2771
> URL: https://issues.apache.org/jira/browse/NIFI-2771
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Mark Payne
>Priority: Critical
> Fix For: 1.1.0
>
>
> Responses from the REST API do not appear to be compressed. In the logs, we 
> see warnings:
> 2016-09-13 15:22:23,124 WARN [main] o.eclipse.jetty.util.DeprecationWarning 
> Using @Deprecated Class org.eclipse.jetty.servlets.GzipFilter
> 2016-09-13 15:22:23,124 WARN [main] org.eclipse.jetty.servlets.GzipFilter 
> GzipFilter is deprecated. Use GzipHandler



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (NIFI-2771) REST API does not compress responses

[Mark Payne (JIRA)]

Mark Payne created NIFI-2771:


 Summary: REST API does not compress responses
 Key: NIFI-2771
 URL: https://issues.apache.org/jira/browse/NIFI-2771
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework
Affects Versions: 1.0.0
Reporter: Mark Payne
Priority: Critical
 Fix For: 1.1.0


Responses from the REST API do not appear to be compressed. In the logs, we see 
warnings:

2016-09-13 15:22:23,124 WARN [main] o.eclipse.jetty.util.DeprecationWarning 
Using @Deprecated Class org.eclipse.jetty.servlets.GzipFilter
2016-09-13 15:22:23,124 WARN [main] org.eclipse.jetty.servlets.GzipFilter 
GzipFilter is deprecated. Use GzipHandler




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2770) flow configuration history action details dialog only shows UUID

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2770:
--

GitHub user scottyaslan opened a pull request:

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

[NIFI-2770] fix action details dialog



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

$ git pull https://github.com/scottyaslan/nifi devBranch

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

https://github.com/apache/nifi/pull/1017.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 #1017


commit 4b05d910223031f4325a63347be6a80f81d7962b
Author: Scott Aslan 
Date:   2016-09-13T19:30:51Z

[NIFI-2770] fix action details dialog




> flow configuration history action details dialog only shows UUID
> 
>
> Key: NIFI-2770
> URL: https://issues.apache.org/jira/browse/NIFI-2770
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Scott Aslan
>Assignee: Scott Aslan
> Fix For: 1.1.0
>
>
> In the NiFi history shell when I click to view details on a particular event 
> the action details dialog just shows the uuid of the component and no actual 
> details



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #1017: [NIFI-2770] fix action details dialog

[scottyaslan]

GitHub user scottyaslan opened a pull request:

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

[NIFI-2770] fix action details dialog



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

$ git pull https://github.com/scottyaslan/nifi devBranch

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

https://github.com/apache/nifi/pull/1017.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 #1017


commit 4b05d910223031f4325a63347be6a80f81d7962b
Author: Scott Aslan 
Date:   2016-09-13T19:30:51Z

[NIFI-2770] fix action details dialog




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (NIFI-2770) flow configuration history action details dialog only shows UUID

[Scott Aslan (JIRA)]

Scott Aslan created NIFI-2770:
-

 Summary: flow configuration history action details dialog only 
shows UUID
 Key: NIFI-2770
 URL: https://issues.apache.org/jira/browse/NIFI-2770
 Project: Apache NiFi
  Issue Type: Bug
Reporter: Scott Aslan
Assignee: Scott Aslan
 Fix For: 1.1.0


In the NiFi history shell when I click to view details on a particular event 
the action details dialog just shows the uuid of the component and no actual 
details



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2724) JMX Processor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2724:
--

GitHub user brianburnett opened a pull request:

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

NIFI-2724 New JMX Processor

Attempt to contribute GetJMX Processor

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

$ git pull https://github.com/brianburnett/nifi nifi-2724

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

https://github.com/apache/nifi/pull/1016.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 #1016


commit acdb3252ad330b829386e1b378eb013072cd4c15
Author: brianburnett 
Date:   2016-09-13T19:13:00Z

NIFI-2724 New JMX Processor




> JMX Processor
> -
>
> Key: NIFI-2724
> URL: https://issues.apache.org/jira/browse/NIFI-2724
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: 1.0.0
> Environment: All platforms with Java RMI support for JMX
>Reporter: Brian Burnett
>Priority: Minor
>  Labels: processor
> Fix For: 1.1.0
>
> Attachments: 0001-NIFI-2724-New-JMX-Processor.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> The JMX Processor feature addition includes only GetJMX without 
> SecurityManager capabilities at this time.  The processor in its current 
> state is capable of pulling MBean Property and Attribute values from a remote 
> RMI Server.  Each set of Mbean data is wrapped in a JSON formatted FlowFile 
> for downstream processing.  It has the ability to control content with 
> whitelist and blacklist properties.
> Possible use for this processor and the reason it was created is to help make 
> sense of Kafka server metrics.
> Will followup with a SecurityManager Context Service and PutJMX Processor.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #1016: NIFI-2724 New JMX Processor

[brianburnett]

GitHub user brianburnett opened a pull request:

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

NIFI-2724 New JMX Processor

Attempt to contribute GetJMX Processor

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

$ git pull https://github.com/brianburnett/nifi nifi-2724

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

https://github.com/apache/nifi/pull/1016.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 #1016


commit acdb3252ad330b829386e1b378eb013072cd4c15
Author: brianburnett 
Date:   2016-09-13T19:13:00Z

NIFI-2724 New JMX Processor




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2266) GetHTTP and PutHTTP use hard-coded TLS protocol version

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2266:
--

Github user mosermw commented on the issue:

https://github.com/apache/nifi/pull/999
  
I had the same unit test failure as @pvillard31.  Once I resolved that 
locally, I confirmed that this change works against the URL listed in 
NIFI-2373.  contrib-check passes.

This also cherry-picks cleanly into the 0.x branch, but the 
testDefaultShouldPreferTLSv1_2() method of TestGetHTTPGroovy.groovy doesn't 
work with Java 7.  It would need the same mods as the corresponding method in 
TestPostHTTPGroovy.groovy.


> GetHTTP and PutHTTP use hard-coded TLS protocol version
> ---
>
> Key: NIFI-2266
> URL: https://issues.apache.org/jira/browse/NIFI-2266
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 0.7.0, 0.6.1
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>  Labels: https, security, tls
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> As pointed out on the mailing list [1], the {{GetHTTP}} (and likely 
> {{PutHTTP}}) processors use a hard-coded TLS protocol version. {{PostHTTP}} 
> also did this and was fixed by [NIFI-1688]. 
> The same fix should apply here and unit tests already exist which can be 
> applied to the other processors as well. 
> For future notice, {{InvokeHTTP}} is a better processor for generic HTTP 
> operations and has supported reading the TLS protocol version from the 
> {{SSLContextService}} for some time. 
> [1] 
> https://lists.apache.org/thread.html/a48e2ebbc2231d685491ae6b856c760620efca5bff2c7249f915b24d@%3Cdev.nifi.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #999: NIFI-2266 Enabled TLSv1.1 and TLSv1.2 protocols for GetHTTP...

[mosermw]

Github user mosermw commented on the issue:

https://github.com/apache/nifi/pull/999
  
I had the same unit test failure as @pvillard31.  Once I resolved that 
locally, I confirmed that this change works against the URL listed in 
NIFI-2373.  contrib-check passes.

This also cherry-picks cleanly into the 0.x branch, but the 
testDefaultShouldPreferTLSv1_2() method of TestGetHTTPGroovy.groovy doesn't 
work with Java 7.  It would need the same mods as the corresponding method in 
TestPostHTTPGroovy.groovy.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2767) Periodically reload properties from file-based variable registry properties files

[Joey Frazee (JIRA)]

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

Joey Frazee commented on NIFI-2767:
---

[~joewitt] I see what you're saying. It occurs to me now that I was not 
thinking of these as containing any of the core NiFi properties, so the 
consequences were limited and would be similar to letting the files be out of 
sync across nodes.



> Periodically reload properties from file-based variable registry properties 
> files
> -
>
> Key: NIFI-2767
> URL: https://issues.apache.org/jira/browse/NIFI-2767
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Joey Frazee
>Priority: Minor
>
> Currently FileBasedVariableRegistry only loads properties when it is injected 
> into the flow controller so making updates to the properties requires a 
> restart.
> Management of data flows would be much easier if these changes could be 
> picked up without doing a (rolling) restart. It'd be helpful from an 
> administrative standpoint if the FileBasedVariableRegistry reloaded 
> properties from the properties files periodically.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (NIFI-2769) Unable to view Component ID of "unknown" components in a provenance lineage graph.

[Matthew Clarke (JIRA)]

Matthew Clarke created NIFI-2769:


 Summary: Unable to view Component ID of "unknown" components in a 
provenance lineage graph.
 Key: NIFI-2769
 URL: https://issues.apache.org/jira/browse/NIFI-2769
 Project: Apache NiFi
  Issue Type: Improvement
  Components: Core Framework
Affects Versions: 1.0.0
Reporter: Matthew Clarke
Priority: Minor


NiFi lineage that includes unknown components does not provide the minimum 
level of information needed to troubleshoot a dataflow in a secured NiFi user 
level component access policies.  Clicking on "view details" of an "unknown" 
component in a lineage graph returns an unauthorized response. User Should be 
able to at least retrieve the UUID for the unknown components.

An example use case:
A user (user M) has permissions to a process group with an input port.  That 
input port is fed by many different parent level connections from other 
components user M does not have permission to.  If user M performs a lineage 
search against a single FlowFile, it is not possible for user M to determine 
which of source connections the data came from.  This makes troubleshooting 
difficult as user must query all source dataflow users to do queries to see if 
they were the source of the data. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-1170) TailFile "File to Tail" property should support Wildcards

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-1170:
--

Github user olegz commented on the issue:

https://github.com/apache/nifi/pull/980
  
@pvillard31 Looked thru changes, tested. Left one more comment, otherwise 
looks good. Will merge once the comment is addressed (not necessarily through 
code, just waned to get your opinion).


> TailFile "File to Tail" property should support Wildcards
> -
>
> Key: NIFI-1170
> URL: https://issues.apache.org/jira/browse/NIFI-1170
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 0.4.0
>Reporter: Andre
>
> Because of challenges around log rotation of high volume syslog and app 
> producers, it is customary to logging platform developers to promote file 
> variables based file names such as DynaFiles (rsyslog), Macros(syslog-ng)as 
> alternatives to getting SIGHUPs being sent to the syslog daemon upon every 
> file rotation.
> (To certain extent, used even NiFi's has similar patterns, like for example, 
> when one uses Expression Language to set PutHDFS destination file).
> The current TailFile strategy suggests rotation patterns like:
> {code}
> log_folder/app.log
> log_folder/app.log.1
> log_folder/app.log.2
> log_folder/app.log.3
> {code}
> It is possible to fool the system to accept wildcards by simply using a 
> strategy like:
> {code}
> log_folder/test1
> log_folder/server1
> log_folder/server2
> log_folder/server3
> {code}
> And configure *Rolling Filename Pattern* to * but it feels like a hack, 
> rather than catering for an ever increasingly prevalent use case 
> (DynaFile/macros/etc).
> It would be great if instead, TailFile had the ability to use wildcards on 
> File to Tail property



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #980: NIFI-1170 - Improved TailFile processor to support multiple...

[olegz]

Github user olegz commented on the issue:

https://github.com/apache/nifi/pull/980
  
@pvillard31 Looked thru changes, tested. Left one more comment, otherwise 
looks good. Will merge once the comment is addressed (not necessarily through 
code, just waned to get your opinion).


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-1170) TailFile "File to Tail" property should support Wildcards

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-1170:
--

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

https://github.com/apache/nifi/pull/980#discussion_r78600733
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/TailFile.java
 ---
@@ -117,31 +173,78 @@
 .allowableValues(LOCATION_LOCAL, LOCATION_REMOTE)
 .defaultValue(LOCATION_LOCAL.getValue())
 .build();
+
 static final PropertyDescriptor START_POSITION = new 
PropertyDescriptor.Builder()
 .name("Initial Start Position")
-.description("When the Processor first begins to tail data, 
this property specifies where the Processor should begin reading data. Once 
data has been ingested from the file, "
+.description("When the Processor first begins to tail data, 
this property specifies where the Processor should begin reading data. Once 
data has been ingested from a file, "
 + "the Processor will continue from the last point 
from which it has received data.")
 .allowableValues(START_BEGINNING_OF_TIME, START_CURRENT_FILE, 
START_CURRENT_TIME)
 .defaultValue(START_CURRENT_FILE.getValue())
 .required(true)
 .build();
 
+static final PropertyDescriptor RECURSIVE = new 
PropertyDescriptor.Builder()
+.name("tailfile-recursive-lookup")
+.displayName("Recursive lookup")
+.description("When using Multiple files mode, this property 
defines if files must be listed recursively or not"
++ " in the base directory.")
+.allowableValues("true", "false")
+.defaultValue("true")
+.required(true)
+.build();
+
+static final PropertyDescriptor ROLLING_STRATEGY = new 
PropertyDescriptor.Builder()
+.name("tailfile-rolling-strategy")
+.displayName("Rolling Strategy")
+.description("Specifies if the files to tail have a fixed name 
or not.")
+.required(true)
+.allowableValues(FIXED_NAME, CHANGING_NAME)
+.defaultValue(FIXED_NAME.getValue())
+.build();
+
+static final PropertyDescriptor LOOKUP_FREQUENCY = new 
PropertyDescriptor.Builder()
+.name("tailfile-lookup-frequency")
+.displayName("Lookup frequency")
+.description("Only used in Multiple files mode and Changing 
name rolling strategy, it specifies the minimum "
++ "duration the processor will wait before listing 
again the files to tail.")
+.required(false)
+.addValidator(StandardValidators.TIME_PERIOD_VALIDATOR)
+.defaultValue("10 minutes")
--- End diff --

Pierre, I am actually wondering if MAX Long is the appropriate default 
here. If I understand it correctly you do NOT want to resist them at all unless 
some time has passed and if so the best "some time" IMHO is infinity while 
letting the user override 


> TailFile "File to Tail" property should support Wildcards
> -
>
> Key: NIFI-1170
> URL: https://issues.apache.org/jira/browse/NIFI-1170
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 0.4.0
>Reporter: Andre
>
> Because of challenges around log rotation of high volume syslog and app 
> producers, it is customary to logging platform developers to promote file 
> variables based file names such as DynaFiles (rsyslog), Macros(syslog-ng)as 
> alternatives to getting SIGHUPs being sent to the syslog daemon upon every 
> file rotation.
> (To certain extent, used even NiFi's has similar patterns, like for example, 
> when one uses Expression Language to set PutHDFS destination file).
> The current TailFile strategy suggests rotation patterns like:
> {code}
> log_folder/app.log
> log_folder/app.log.1
> log_folder/app.log.2
> log_folder/app.log.3
> {code}
> It is possible to fool the system to accept wildcards by simply using a 
> strategy like:
> {code}
> log_folder/test1
> log_folder/server1
> log_folder/server2
> log_folder/server3
> {code}
> And configure *Rolling Filename Pattern* to * but it feels like a hack, 
> rather than catering for an ever increasingly prevalent use case 
> (DynaFile/macros/etc).
> It would be great if instead, TailFile had the ability to use wildcards on 
> File to Tail property



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #980: NIFI-1170 - Improved TailFile processor to support m...

[olegz]

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

https://github.com/apache/nifi/pull/980#discussion_r78600733
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/TailFile.java
 ---
@@ -117,31 +173,78 @@
 .allowableValues(LOCATION_LOCAL, LOCATION_REMOTE)
 .defaultValue(LOCATION_LOCAL.getValue())
 .build();
+
 static final PropertyDescriptor START_POSITION = new 
PropertyDescriptor.Builder()
 .name("Initial Start Position")
-.description("When the Processor first begins to tail data, 
this property specifies where the Processor should begin reading data. Once 
data has been ingested from the file, "
+.description("When the Processor first begins to tail data, 
this property specifies where the Processor should begin reading data. Once 
data has been ingested from a file, "
 + "the Processor will continue from the last point 
from which it has received data.")
 .allowableValues(START_BEGINNING_OF_TIME, START_CURRENT_FILE, 
START_CURRENT_TIME)
 .defaultValue(START_CURRENT_FILE.getValue())
 .required(true)
 .build();
 
+static final PropertyDescriptor RECURSIVE = new 
PropertyDescriptor.Builder()
+.name("tailfile-recursive-lookup")
+.displayName("Recursive lookup")
+.description("When using Multiple files mode, this property 
defines if files must be listed recursively or not"
++ " in the base directory.")
+.allowableValues("true", "false")
+.defaultValue("true")
+.required(true)
+.build();
+
+static final PropertyDescriptor ROLLING_STRATEGY = new 
PropertyDescriptor.Builder()
+.name("tailfile-rolling-strategy")
+.displayName("Rolling Strategy")
+.description("Specifies if the files to tail have a fixed name 
or not.")
+.required(true)
+.allowableValues(FIXED_NAME, CHANGING_NAME)
+.defaultValue(FIXED_NAME.getValue())
+.build();
+
+static final PropertyDescriptor LOOKUP_FREQUENCY = new 
PropertyDescriptor.Builder()
+.name("tailfile-lookup-frequency")
+.displayName("Lookup frequency")
+.description("Only used in Multiple files mode and Changing 
name rolling strategy, it specifies the minimum "
++ "duration the processor will wait before listing 
again the files to tail.")
+.required(false)
+.addValidator(StandardValidators.TIME_PERIOD_VALIDATOR)
+.defaultValue("10 minutes")
--- End diff --

Pierre, I am actually wondering if MAX Long is the appropriate default 
here. If I understand it correctly you do NOT want to resist them at all unless 
some time has passed and if so the best "some time" IMHO is infinity while 
letting the user override 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (NIFI-2768) Ensure WRITE permissions on parent process group when updating connection destination

[Bryan Bende (JIRA)]

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

Bryan Bende updated NIFI-2768:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Ensure WRITE permissions on parent process group when updating connection 
> destination
> -
>
> Key: NIFI-2768
> URL: https://issues.apache.org/jira/browse/NIFI-2768
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>Priority: Critical
> Fix For: 1.1.0
>
>
> When we create a connection, we ensure the user is authorized for the source, 
> destination, and current process group. When directing a connection to a new 
> destination, the check on the parent process group is not being enforced 
> correctly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2768) Ensure WRITE permissions on parent process group when updating connection destination

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2768:
--

Github user asfgit closed the pull request at:

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


> Ensure WRITE permissions on parent process group when updating connection 
> destination
> -
>
> Key: NIFI-2768
> URL: https://issues.apache.org/jira/browse/NIFI-2768
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>Priority: Critical
> Fix For: 1.1.0
>
>
> When we create a connection, we ensure the user is authorized for the source, 
> destination, and current process group. When directing a connection to a new 
> destination, the check on the parent process group is not being enforced 
> correctly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #1014: Correct authorization when destination changes

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2768) Ensure WRITE permissions on parent process group when updating connection destination

[ASF subversion and git services (JIRA)]

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

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

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

NIFI-2768: - Ensuring we correctly enforce authorization when the destination 
of a connection changes. This includes source, destination, and parent process 
group. - Ensuring the UI reseting accordingly when a request fails.

This closes #1014.

Signed-off-by: Bryan Bende 


> Ensure WRITE permissions on parent process group when updating connection 
> destination
> -
>
> Key: NIFI-2768
> URL: https://issues.apache.org/jira/browse/NIFI-2768
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>Priority: Critical
> Fix For: 1.1.0
>
>
> When we create a connection, we ensure the user is authorized for the source, 
> destination, and current process group. When directing a connection to a new 
> destination, the check on the parent process group is not being enforced 
> correctly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #1014: Correct authorization when destination changes

[bbende]

Github user bbende commented on the issue:

https://github.com/apache/nifi/pull/1014
  
+1 verified i can no longer change a connection when i don't have WRITE to 
the parent process group, will merge to master


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2767) Periodically reload properties from file-based variable registry properties files

[Joseph Witt (JIRA)]

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

Joseph Witt commented on NIFI-2767:
---

Absolutely we want to support live editing but definitely not without fully 
considering the lifecycle implications of doing so in terms of when these 
values are used by components in their lifecycle.  It was intentional for them 
not to auto reload because as of yet not work has been done to consider the 
lifecycle factors and it was also expected we'd continue the work by adding 
cluster-wide variable registry and that when allowing the user to edit it 
(which *rarely* should be through a property file) that we'd properly stop 
affected components, apply the change, then start affected components.

This is not safe as-is.

> Periodically reload properties from file-based variable registry properties 
> files
> -
>
> Key: NIFI-2767
> URL: https://issues.apache.org/jira/browse/NIFI-2767
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Joey Frazee
>Priority: Minor
>
> Currently FileBasedVariableRegistry only loads properties when it is injected 
> into the flow controller so making updates to the properties requires a 
> restart.
> Management of data flows would be much easier if these changes could be 
> picked up without doing a (rolling) restart. It'd be helpful from an 
> administrative standpoint if the FileBasedVariableRegistry reloaded 
> properties from the properties files periodically.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #1014: Correct authorization when destination changes

[bbende]

Github user bbende commented on the issue:

https://github.com/apache/nifi/pull/1014
  
Reviewing...


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2767) Periodically reload properties from file-based variable registry properties files

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2767:
--

GitHub user jfrazee opened a pull request:

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

NIFI-2767 Periodically reload properties from file-based variable registry 
properties files



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

$ git pull https://github.com/jfrazee/nifi NIFI-2767

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

https://github.com/apache/nifi/pull/1015.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 #1015


commit 62ca8d2b2eb3bf71b83597eac80481d1b5539043
Author: Joey Frazee 
Date:   2016-09-13T15:00:13Z

NIFI-2767 Periodically reload properties from file-based variable registry 
properties files




> Periodically reload properties from file-based variable registry properties 
> files
> -
>
> Key: NIFI-2767
> URL: https://issues.apache.org/jira/browse/NIFI-2767
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Joey Frazee
>Priority: Minor
>
> Currently FileBasedVariableRegistry only loads properties when it is injected 
> into the flow controller so making updates to the properties requires a 
> restart.
> Management of data flows would be much easier if these changes could be 
> picked up without doing a (rolling) restart. It'd be helpful from an 
> administrative standpoint if the FileBasedVariableRegistry reloaded 
> properties from the properties files periodically.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #1015: NIFI-2767 Periodically reload properties from file-...

[jfrazee]

GitHub user jfrazee opened a pull request:

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

NIFI-2767 Periodically reload properties from file-based variable registry 
properties files



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

$ git pull https://github.com/jfrazee/nifi NIFI-2767

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

https://github.com/apache/nifi/pull/1015.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 #1015


commit 62ca8d2b2eb3bf71b83597eac80481d1b5539043
Author: Joey Frazee 
Date:   2016-09-13T15:00:13Z

NIFI-2767 Periodically reload properties from file-based variable registry 
properties files




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (NIFI-2768) Ensure WRITE permissions on parent process group when updating connection destination

[Matt Gilman (JIRA)]

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

Matt Gilman updated NIFI-2768:
--
Status: Patch Available  (was: Open)

> Ensure WRITE permissions on parent process group when updating connection 
> destination
> -
>
> Key: NIFI-2768
> URL: https://issues.apache.org/jira/browse/NIFI-2768
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>Priority: Critical
> Fix For: 1.1.0
>
>
> When we create a connection, we ensure the user is authorized for the source, 
> destination, and current process group. When directing a connection to a new 
> destination, the check on the parent process group is not being enforced 
> correctly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2768) Ensure WRITE permissions on parent process group when updating connection destination

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2768:
--

GitHub user mcgilman opened a pull request:

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

Correct authorization when destination changes

NIFI-2768:
- Ensuring we correctly enforce authorization when the destination of a 
connection changes. This includes source, destination, and parent process group.
- Ensuring the UI resetting accordingly when a request fails.

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

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

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

https://github.com/apache/nifi/pull/1014.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 #1014


commit 0d82b9eb0a581963a9d3ca0fa1ef441db5100502
Author: Matt Gilman 
Date:   2016-09-13T15:22:03Z

NIFI-2768:
- Ensuring we correctly enforce authorization when the destination of a 
connection changes. This includes source, destination, and parent process group.
- Ensuring the UI reseting accordingly when a request fails.




> Ensure WRITE permissions on parent process group when updating connection 
> destination
> -
>
> Key: NIFI-2768
> URL: https://issues.apache.org/jira/browse/NIFI-2768
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>Priority: Critical
> Fix For: 1.1.0
>
>
> When we create a connection, we ensure the user is authorized for the source, 
> destination, and current process group. When directing a connection to a new 
> destination, the check on the parent process group is not being enforced 
> correctly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #1014: Correct authorization when destination changes

[mcgilman]

GitHub user mcgilman opened a pull request:

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

Correct authorization when destination changes

NIFI-2768:
- Ensuring we correctly enforce authorization when the destination of a 
connection changes. This includes source, destination, and parent process group.
- Ensuring the UI resetting accordingly when a request fails.

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

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

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

https://github.com/apache/nifi/pull/1014.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 #1014


commit 0d82b9eb0a581963a9d3ca0fa1ef441db5100502
Author: Matt Gilman 
Date:   2016-09-13T15:22:03Z

NIFI-2768:
- Ensuring we correctly enforce authorization when the destination of a 
connection changes. This includes source, destination, and parent process group.
- Ensuring the UI reseting accordingly when a request fails.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (NIFI-2765) PutHiveStreaming does not work with Kerberos

[Bryan Bende (JIRA)]

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

Bryan Bende updated NIFI-2765:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> PutHiveStreaming does not work with Kerberos
> 
>
> Key: NIFI-2765
> URL: https://issues.apache.org/jira/browse/NIFI-2765
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0
>Reporter: Matt Burgess
>Assignee: Matt Burgess
>
> The PutHiveStreaming processor will complain about a missing 
> nifi.kerberos.krb5.file setting if using Kerberos.
> It is the same symptom described in NIFI-2598, which fixed the issue for 
> HiveConnectionPool (and thus SelectHiveQL and PutHiveQL), but 
> PutHiveStreaming does not use the HiveConnectionPool, yet has similar code 
> which is statically adding Kerberos properties.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2765) PutHiveStreaming does not work with Kerberos

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2765:
--

Github user asfgit closed the pull request at:

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


> PutHiveStreaming does not work with Kerberos
> 
>
> Key: NIFI-2765
> URL: https://issues.apache.org/jira/browse/NIFI-2765
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0
>Reporter: Matt Burgess
>Assignee: Matt Burgess
>
> The PutHiveStreaming processor will complain about a missing 
> nifi.kerberos.krb5.file setting if using Kerberos.
> It is the same symptom described in NIFI-2598, which fixed the issue for 
> HiveConnectionPool (and thus SelectHiveQL and PutHiveQL), but 
> PutHiveStreaming does not use the HiveConnectionPool, yet has similar code 
> which is statically adding Kerberos properties.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2765) PutHiveStreaming does not work with Kerberos

[ASF subversion and git services (JIRA)]

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

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

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

NIFI-2765: Fixed Kerberos support for PutHiveStreaming

This closes #1012.

Signed-off-by: Bryan Bende 


> PutHiveStreaming does not work with Kerberos
> 
>
> Key: NIFI-2765
> URL: https://issues.apache.org/jira/browse/NIFI-2765
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0
>Reporter: Matt Burgess
>Assignee: Matt Burgess
>
> The PutHiveStreaming processor will complain about a missing 
> nifi.kerberos.krb5.file setting if using Kerberos.
> It is the same symptom described in NIFI-2598, which fixed the issue for 
> HiveConnectionPool (and thus SelectHiveQL and PutHiveQL), but 
> PutHiveStreaming does not use the HiveConnectionPool, yet has similar code 
> which is statically adding Kerberos properties.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #1012: NIFI-2765: Fixed Kerberos support for PutHiveStream...

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2765) PutHiveStreaming does not work with Kerberos

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2765:
--

Github user bbende commented on the issue:

https://github.com/apache/nifi/pull/1012
  
+1 verified the validation can now pass, will merge to master


> PutHiveStreaming does not work with Kerberos
> 
>
> Key: NIFI-2765
> URL: https://issues.apache.org/jira/browse/NIFI-2765
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0
>Reporter: Matt Burgess
>Assignee: Matt Burgess
>
> The PutHiveStreaming processor will complain about a missing 
> nifi.kerberos.krb5.file setting if using Kerberos.
> It is the same symptom described in NIFI-2598, which fixed the issue for 
> HiveConnectionPool (and thus SelectHiveQL and PutHiveQL), but 
> PutHiveStreaming does not use the HiveConnectionPool, yet has similar code 
> which is statically adding Kerberos properties.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #1012: NIFI-2765: Fixed Kerberos support for PutHiveStreaming

[bbende]

Github user bbende commented on the issue:

https://github.com/apache/nifi/pull/1012
  
+1 verified the validation can now pass, will merge to master


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (NIFI-2768) Ensure WRITE permissions on parent process group when updating connection destination

[Matt Gilman (JIRA)]

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

Matt Gilman updated NIFI-2768:
--
Description: When we create a connection, we ensure the user is authorized 
for the source, destination, and current process group. When directing a 
connection to a new destination, the check on the parent process group is not 
being enforced correctly.  (was: When we create conneciton, we ensure the user 
is authorized for the source, destination, and current process group. When 
directing a connection to a new destination, the check on the parent process 
group was not being enforced correctly.)

> Ensure WRITE permissions on parent process group when updating connection 
> destination
> -
>
> Key: NIFI-2768
> URL: https://issues.apache.org/jira/browse/NIFI-2768
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>Priority: Critical
> Fix For: 1.1.0
>
>
> When we create a connection, we ensure the user is authorized for the source, 
> destination, and current process group. When directing a connection to a new 
> destination, the check on the parent process group is not being enforced 
> correctly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2765) PutHiveStreaming does not work with Kerberos

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2765:
--

Github user bbende commented on the issue:

https://github.com/apache/nifi/pull/1012
  
Reviewing...


> PutHiveStreaming does not work with Kerberos
> 
>
> Key: NIFI-2765
> URL: https://issues.apache.org/jira/browse/NIFI-2765
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0
>Reporter: Matt Burgess
>Assignee: Matt Burgess
>
> The PutHiveStreaming processor will complain about a missing 
> nifi.kerberos.krb5.file setting if using Kerberos.
> It is the same symptom described in NIFI-2598, which fixed the issue for 
> HiveConnectionPool (and thus SelectHiveQL and PutHiveQL), but 
> PutHiveStreaming does not use the HiveConnectionPool, yet has similar code 
> which is statically adding Kerberos properties.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #1012: NIFI-2765: Fixed Kerberos support for PutHiveStreaming

[bbende]

Github user bbende commented on the issue:

https://github.com/apache/nifi/pull/1012
  
Reviewing...


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (NIFI-2768) Ensure WRITE permissions on parent process group when updating connection destination

[Matt Gilman (JIRA)]

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

Matt Gilman updated NIFI-2768:
--
Description: When we create conneciton, we ensure the user is authorized 
for the source, destination, and current process group. When directing a 
connection to a new destination, the check on the parent process group was not 
being enforced correctly.

> Ensure WRITE permissions on parent process group when updating connection 
> destination
> -
>
> Key: NIFI-2768
> URL: https://issues.apache.org/jira/browse/NIFI-2768
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>Priority: Critical
> Fix For: 1.1.0
>
>
> When we create conneciton, we ensure the user is authorized for the source, 
> destination, and current process group. When directing a connection to a new 
> destination, the check on the parent process group was not being enforced 
> correctly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (NIFI-2768) Ensure WRITE permissions on parent process group when updating connection destination

[Matt Gilman (JIRA)]

Matt Gilman created NIFI-2768:
-

 Summary: Ensure WRITE permissions on parent process group when 
updating connection destination
 Key: NIFI-2768
 URL: https://issues.apache.org/jira/browse/NIFI-2768
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework
Reporter: Matt Gilman
Assignee: Matt Gilman
Priority: Critical
 Fix For: 1.1.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (NIFI-2766) Ensure root group is included in /resources

[Bryan Bende (JIRA)]

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

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

> Ensure root group is included in /resources
> ---
>
> Key: NIFI-2766
> URL: https://issues.apache.org/jira/browse/NIFI-2766
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>Priority: Minor
> Fix For: 1.1.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2766) Ensure root group is included in /resources

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2766:
--

Github user asfgit closed the pull request at:

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


> Ensure root group is included in /resources
> ---
>
> Key: NIFI-2766
> URL: https://issues.apache.org/jira/browse/NIFI-2766
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>Priority: Minor
> Fix For: 1.1.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2766) Ensure root group is included in /resources

[ASF subversion and git services (JIRA)]

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

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

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

NIFI-2766: - Ensuring the root group is included in /resources.

This closes #1013.

Signed-off-by: Bryan Bende 


> Ensure root group is included in /resources
> ---
>
> Key: NIFI-2766
> URL: https://issues.apache.org/jira/browse/NIFI-2766
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>Priority: Minor
> Fix For: 1.1.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #1013: Ensuring the root group is included in /resources

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi issue #1013: Ensuring the root group is included in /resources

[bbende]

Github user bbende commented on the issue:

https://github.com/apache/nifi/pull/1013
  
+1 Will merge to master


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi issue #1013: Ensuring the root group is included in /resources

[bbende]

Github user bbende commented on the issue:

https://github.com/apache/nifi/pull/1013
  
Reviewing...


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request #1013: Ensuring the root group is included in /resources

[mcgilman]

GitHub user mcgilman opened a pull request:

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

Ensuring the root group is included in /resources

NIFI-2766:
- Ensuring the root group is included in /resources.

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

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

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

https://github.com/apache/nifi/pull/1013.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 #1013


commit 919b1433c2c7e7944f1b7bb5919a97381b2f4806
Author: Matt Gilman 
Date:   2016-09-13T14:46:21Z

NIFI-2766:
- Ensuring the root group is included in /resources.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2766) Ensure root group is included in /resources

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2766:
--

GitHub user mcgilman opened a pull request:

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

Ensuring the root group is included in /resources

NIFI-2766:
- Ensuring the root group is included in /resources.

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

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

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

https://github.com/apache/nifi/pull/1013.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 #1013


commit 919b1433c2c7e7944f1b7bb5919a97381b2f4806
Author: Matt Gilman 
Date:   2016-09-13T14:46:21Z

NIFI-2766:
- Ensuring the root group is included in /resources.




> Ensure root group is included in /resources
> ---
>
> Key: NIFI-2766
> URL: https://issues.apache.org/jira/browse/NIFI-2766
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>Priority: Minor
> Fix For: 1.1.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (NIFI-2767) Periodically reload properties from file-based variable registry properties files

[Joey Frazee (JIRA)]

Joey Frazee created NIFI-2767:
-

 Summary: Periodically reload properties from file-based variable 
registry properties files
 Key: NIFI-2767
 URL: https://issues.apache.org/jira/browse/NIFI-2767
 Project: Apache NiFi
  Issue Type: Improvement
Reporter: Joey Frazee
Priority: Minor


Currently FileBasedVariableRegistry only loads properties when it is injected 
into the flow controller so making updates to the properties requires a restart.

Management of data flows would be much easier if these changes could be picked 
up without doing a (rolling) restart. It'd be helpful from an administrative 
standpoint if the FileBasedVariableRegistry reloaded properties from the 
properties files periodically.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (NIFI-2766) Ensure root group is included in /resources

[Matt Gilman (JIRA)]

Matt Gilman created NIFI-2766:
-

 Summary: Ensure root group is included in /resources
 Key: NIFI-2766
 URL: https://issues.apache.org/jira/browse/NIFI-2766
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework
Reporter: Matt Gilman
Assignee: Matt Gilman
Priority: Minor
 Fix For: 1.1.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2765) PutHiveStreaming does not work with Kerberos

[Matt Burgess (JIRA)]

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

Matt Burgess updated NIFI-2765:
---
Status: Patch Available  (was: In Progress)

> PutHiveStreaming does not work with Kerberos
> 
>
> Key: NIFI-2765
> URL: https://issues.apache.org/jira/browse/NIFI-2765
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0
>Reporter: Matt Burgess
>Assignee: Matt Burgess
>
> The PutHiveStreaming processor will complain about a missing 
> nifi.kerberos.krb5.file setting if using Kerberos.
> It is the same symptom described in NIFI-2598, which fixed the issue for 
> HiveConnectionPool (and thus SelectHiveQL and PutHiveQL), but 
> PutHiveStreaming does not use the HiveConnectionPool, yet has similar code 
> which is statically adding Kerberos properties.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2765) PutHiveStreaming does not work with Kerberos

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2765:
--

GitHub user mattyb149 opened a pull request:

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

NIFI-2765: Fixed Kerberos support for PutHiveStreaming



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

$ git pull https://github.com/mattyb149/nifi NIFI-2765

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

https://github.com/apache/nifi/pull/1012.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 #1012


commit f7429559cee9140333ade162b244245d4f19b627
Author: Matt Burgess 
Date:   2016-09-13T14:20:27Z

NIFI-2765: Fixed Kerberos support for PutHiveStreaming




> PutHiveStreaming does not work with Kerberos
> 
>
> Key: NIFI-2765
> URL: https://issues.apache.org/jira/browse/NIFI-2765
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0
>Reporter: Matt Burgess
>Assignee: Matt Burgess
>
> The PutHiveStreaming processor will complain about a missing 
> nifi.kerberos.krb5.file setting if using Kerberos.
> It is the same symptom described in NIFI-2598, which fixed the issue for 
> HiveConnectionPool (and thus SelectHiveQL and PutHiveQL), but 
> PutHiveStreaming does not use the HiveConnectionPool, yet has similar code 
> which is statically adding Kerberos properties.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #1012: NIFI-2765: Fixed Kerberos support for PutHiveStream...

[mattyb149]

GitHub user mattyb149 opened a pull request:

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

NIFI-2765: Fixed Kerberos support for PutHiveStreaming



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

$ git pull https://github.com/mattyb149/nifi NIFI-2765

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

https://github.com/apache/nifi/pull/1012.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 #1012


commit f7429559cee9140333ade162b244245d4f19b627
Author: Matt Burgess 
Date:   2016-09-13T14:20:27Z

NIFI-2765: Fixed Kerberos support for PutHiveStreaming




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-1971) Create a batch capable pseudo-whois ("netcat") enrichment Processor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-1971:
--

Github user pvillard31 commented on the issue:

https://github.com/apache/nifi/pull/858
  
Yes @trixpan it was with regex capture, next time I'll be more accurate in 
the regex to remove the newline.


> Create a batch capable pseudo-whois ("netcat") enrichment Processor
> ---
>
> Key: NIFI-1971
> URL: https://issues.apache.org/jira/browse/NIFI-1971
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Andre
>Assignee: Andre
> Fix For: 1.1.0
>
>
> While the QueryDNS created can be used on low to medium volume enrichment and 
> to licensed DNS based lookups (e.g. commercial use of SpamHaus) many 
> enrichment providers prefer the use of bulk queries using pseudo whois API 
> (a.k.a. netcat interface).
> as documented 
> [here|https://www.shadowserver.org/wiki/pmwiki.php/Services/IP-BGP#toc6] the 
> bulk interfaces work by connecting to port 43/TCP and sending a payload like:
> {code}
> begin origin
> 4.5.4.3
> 17.112.152.32
> 208.77.188.166
> end
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #858: NIFI-1971 - Introduce QueryWhois processor

[pvillard31]

Github user pvillard31 commented on the issue:

https://github.com/apache/nifi/pull/858
  
Yes @trixpan it was with regex capture, next time I'll be more accurate in 
the regex to remove the newline.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Assigned] (NIFI-2765) PutHiveStreaming does not work with Kerberos

[Matt Burgess (JIRA)]

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

Matt Burgess reassigned NIFI-2765:
--

Assignee: Matt Burgess

> PutHiveStreaming does not work with Kerberos
> 
>
> Key: NIFI-2765
> URL: https://issues.apache.org/jira/browse/NIFI-2765
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0
>Reporter: Matt Burgess
>Assignee: Matt Burgess
>
> The PutHiveStreaming processor will complain about a missing 
> nifi.kerberos.krb5.file setting if using Kerberos.
> It is the same symptom described in NIFI-2598, which fixed the issue for 
> HiveConnectionPool (and thus SelectHiveQL and PutHiveQL), but 
> PutHiveStreaming does not use the HiveConnectionPool, yet has similar code 
> which is statically adding Kerberos properties.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (NIFI-2707) "Bring to Front" function in UI does not to work after exiting group

[Matt Gilman (JIRA)]

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

Matt Gilman reassigned NIFI-2707:
-

Assignee: Matt Gilman

> "Bring to Front" function in UI does not to work after exiting group
> 
>
> Key: NIFI-2707
> URL: https://issues.apache.org/jira/browse/NIFI-2707
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 1.0.0
>Reporter: Mark Payne
>Assignee: Matt Gilman
> Fix For: 1.1.0
>
>
> I have some connections that overlap one another. I right-clicked on one and 
> clicked Bring to Front. This worked as expected. However, after I left the 
> Process Group and came back, the connection that was brought to the front is 
> no longer in front.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2764) JdbcCommon Avro Can't Process Java Short Types

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2764:
--

Github user patricker commented on the issue:

https://github.com/apache/nifi/pull/1009
  
Updated to include mocked unit test.


> JdbcCommon Avro Can't Process Java Short Types
> --
>
> Key: NIFI-2764
> URL: https://issues.apache.org/jira/browse/NIFI-2764
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Peter Wicks
>
> Microsoft SQL Server returns TINYINT values as Java Short's.  Avro is unable 
> to write datum's of this type and throws an exception when trying to.
> This currently breaks QueryDatabaseTable at the very least when querying MS 
> SQL Server with TINYINT's in the ResultSet.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #1009: NIFI-2764 - MS SQL TINYINT Avro Issue

[patricker]

Github user patricker commented on the issue:

https://github.com/apache/nifi/pull/1009
  
Updated to include mocked unit test.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (NIFI-2262) SQL processors fail if column name contains characters illegal for Avro

[Pierre Villard (JIRA)]

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

Pierre Villard updated NIFI-2262:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> SQL processors fail if column name contains characters illegal for Avro
> ---
>
> Key: NIFI-2262
> URL: https://issues.apache.org/jira/browse/NIFI-2262
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Matt Burgess
>Assignee: Matt Burgess
> Fix For: 1.1.0
>
>
> For SQL processors that output Avro (ExecuteSQL, QueryDatabaseTable, etc.), 
> if the SQL result set contains columns whose names contain Avro-illegal 
> characters (such as a period), then an error occurs:
> org.apache.avro.SchemaParseException: Illegal character in: user.gender
> These processors should either normalize the names for Avro automatically or 
> have a property indicating whether names should be normalized.
> A workaround for ExecuteSQL in many cases is to alias the columns in the SQL. 
> This approach doesn't currently work in QueryDatabaseTable for incremental 
> fetch (i.e. maximum-value columns)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2262) SQL processors fail if column name contains characters illegal for Avro

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2262:
--

Github user pvillard31 commented on the issue:

https://github.com/apache/nifi/pull/994
  
Full build with contrib check OK, checked code and tested functionality. +1
Merged to master.


> SQL processors fail if column name contains characters illegal for Avro
> ---
>
> Key: NIFI-2262
> URL: https://issues.apache.org/jira/browse/NIFI-2262
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Matt Burgess
>Assignee: Matt Burgess
> Fix For: 1.1.0
>
>
> For SQL processors that output Avro (ExecuteSQL, QueryDatabaseTable, etc.), 
> if the SQL result set contains columns whose names contain Avro-illegal 
> characters (such as a period), then an error occurs:
> org.apache.avro.SchemaParseException: Illegal character in: user.gender
> These processors should either normalize the names for Avro automatically or 
> have a property indicating whether names should be normalized.
> A workaround for ExecuteSQL in many cases is to alias the columns in the SQL. 
> This approach doesn't currently work in QueryDatabaseTable for incremental 
> fetch (i.e. maximum-value columns)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2719) UI - Request race condition

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2719:
--

GitHub user mcgilman opened a pull request:

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

Handle UI race condition

NIFI-2719:
- Caching components recently added/removed in case ajax requests are 
received out of order. This is not an issue for modifications of existing 
components as we're able to leverage the revision.

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

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

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

https://github.com/apache/nifi/pull/1011.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 #1011


commit 7f559da7191d85181328e4c0c6e4dd2e124dca16
Author: Matt Gilman 
Date:   2016-09-13T13:19:29Z

NIFI-2719:
- Caching components recently added/removed in case ajax requests are 
received out of order. This is not an issue for modifications of existing 
components as we're able to leverage the revision.




> UI - Request race condition
> ---
>
> Key: NIFI-2719
> URL: https://issues.apache.org/jira/browse/NIFI-2719
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.1.0
>
>
> There exists a race condition where during a request to get the components in 
> the current group another request to create or delete a component may execute.
> This results in the component being incorrectly added/removed from the canvas 
> temporarily.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #1011: Handle UI race condition

[mcgilman]

GitHub user mcgilman opened a pull request:

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

Handle UI race condition

NIFI-2719:
- Caching components recently added/removed in case ajax requests are 
received out of order. This is not an issue for modifications of existing 
components as we're able to leverage the revision.

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

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

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

https://github.com/apache/nifi/pull/1011.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 #1011


commit 7f559da7191d85181328e4c0c6e4dd2e124dca16
Author: Matt Gilman 
Date:   2016-09-13T13:19:29Z

NIFI-2719:
- Caching components recently added/removed in case ajax requests are 
received out of order. This is not an issue for modifications of existing 
components as we're able to leverage the revision.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi issue #994: NIFI-2262: Added Avro-normalization of table/column names i...

[pvillard31]

Github user pvillard31 commented on the issue:

https://github.com/apache/nifi/pull/994
  
Full build with contrib check OK, checked code and tested functionality. +1
Merged to master.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2262) SQL processors fail if column name contains characters illegal for Avro

[ASF subversion and git services (JIRA)]

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

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

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

NIFI-2262: Added Avro-normalization of table/column names in SQL processors

This closes #994.


> SQL processors fail if column name contains characters illegal for Avro
> ---
>
> Key: NIFI-2262
> URL: https://issues.apache.org/jira/browse/NIFI-2262
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Matt Burgess
>Assignee: Matt Burgess
> Fix For: 1.1.0
>
>
> For SQL processors that output Avro (ExecuteSQL, QueryDatabaseTable, etc.), 
> if the SQL result set contains columns whose names contain Avro-illegal 
> characters (such as a period), then an error occurs:
> org.apache.avro.SchemaParseException: Illegal character in: user.gender
> These processors should either normalize the names for Avro automatically or 
> have a property indicating whether names should be normalized.
> A workaround for ExecuteSQL in many cases is to alias the columns in the SQL. 
> This approach doesn't currently work in QueryDatabaseTable for incremental 
> fetch (i.e. maximum-value columns)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2262) SQL processors fail if column name contains characters illegal for Avro

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2262:
--

Github user asfgit closed the pull request at:

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


> SQL processors fail if column name contains characters illegal for Avro
> ---
>
> Key: NIFI-2262
> URL: https://issues.apache.org/jira/browse/NIFI-2262
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Matt Burgess
>Assignee: Matt Burgess
> Fix For: 1.1.0
>
>
> For SQL processors that output Avro (ExecuteSQL, QueryDatabaseTable, etc.), 
> if the SQL result set contains columns whose names contain Avro-illegal 
> characters (such as a period), then an error occurs:
> org.apache.avro.SchemaParseException: Illegal character in: user.gender
> These processors should either normalize the names for Avro automatically or 
> have a property indicating whether names should be normalized.
> A workaround for ExecuteSQL in many cases is to alias the columns in the SQL. 
> This approach doesn't currently work in QueryDatabaseTable for incremental 
> fetch (i.e. maximum-value columns)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #994: NIFI-2262: Added Avro-normalization of table/column ...

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2764) JdbcCommon Avro Can't Process Java Short Types

[Peter Wicks (JIRA)]

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

Peter Wicks commented on NIFI-2764:
---

[~Toivo Adams] Thanks for pointing me to those test cases, I'll implement 
something along those lines and get it into the PR.

> JdbcCommon Avro Can't Process Java Short Types
> --
>
> Key: NIFI-2764
> URL: https://issues.apache.org/jira/browse/NIFI-2764
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Peter Wicks
>
> Microsoft SQL Server returns TINYINT values as Java Short's.  Avro is unable 
> to write datum's of this type and throws an exception when trying to.
> This currently breaks QueryDatabaseTable at the very least when querying MS 
> SQL Server with TINYINT's in the ResultSet.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2251) Restore lineage graph export

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2251:
--

Github user YolandaMDavis commented on the issue:

https://github.com/apache/nifi/pull/982
  
@mcgilman made the changes to support Edge and switched to font awesome icon


> Restore lineage graph export
> 
>
> Key: NIFI-2251
> URL: https://issues.apache.org/jira/browse/NIFI-2251
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Matt Gilman
>Assignee: Yolanda M. Davis
> Fix For: 1.1.0
>
>
> Restore the lineage graph download/export using client side 
> methods/technologies to prevent unnecessary trips to the server.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #982: NIFI-2251 - Initial commit for client side provenance linea...

[YolandaMDavis]

Github user YolandaMDavis commented on the issue:

https://github.com/apache/nifi/pull/982
  
@mcgilman made the changes to support Edge and switched to font awesome icon


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (NIFI-2764) JdbcCommon Avro Can't Process Java Short Types

[Toivo Adams (JIRA)]

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

Toivo Adams commented on NIFI-2764:
---

Hi,

Fix itself looks good to me.
Maybe you can add test method to TestJdbcCommon?
As testSignedIntShouldBeInt() is done? Using Mock you don’t have to use 
sqljdbc41.jar dependency.

Thanks
Toivo


> JdbcCommon Avro Can't Process Java Short Types
> --
>
> Key: NIFI-2764
> URL: https://issues.apache.org/jira/browse/NIFI-2764
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Peter Wicks
>
> Microsoft SQL Server returns TINYINT values as Java Short's.  Avro is unable 
> to write datum's of this type and throws an exception when trying to.
> This currently breaks QueryDatabaseTable at the very least when querying MS 
> SQL Server with TINYINT's in the ResultSet.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (NIFI-2765) PutHiveStreaming does not work with Kerberos

[Matt Burgess (JIRA)]

Matt Burgess created NIFI-2765:
--

 Summary: PutHiveStreaming does not work with Kerberos
 Key: NIFI-2765
 URL: https://issues.apache.org/jira/browse/NIFI-2765
 Project: Apache NiFi
  Issue Type: Bug
  Components: Extensions
Affects Versions: 1.0.0
Reporter: Matt Burgess


The PutHiveStreaming processor will complain about a missing 
nifi.kerberos.krb5.file setting if using Kerberos.

It is the same symptom described in NIFI-2598, which fixed the issue for 
HiveConnectionPool (and thus SelectHiveQL and PutHiveQL), but PutHiveStreaming 
does not use the HiveConnectionPool, yet has similar code which is statically 
adding Kerberos properties.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2763) S3 processors do not work with older S3-compatible object stores

[Franco (JIRA)]

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

Franco updated NIFI-2763:
-
Status: Patch Available  (was: Open)

> S3 processors do not work with older S3-compatible object stores
> 
>
> Key: NIFI-2763
> URL: https://issues.apache.org/jira/browse/NIFI-2763
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0
>Reporter: Franco
>  Labels: easyfix
> Fix For: 1.1.0
>
>
> In the 1.0.0 release of NiFi it is using the AWS library for connecting to S3 
> and S3-compatible object stores.
> This library by default expects V4 signer support which if you are using an 
> older object store will not be available and so NiFi will be unusable.
> The fix is simple:
> Allow the user to specify (if they wish) the signer type that AWS library 
> should use.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)