Re: Apache NiFi 0.6.1 RC2 Release Helper Guide

[Joe Witt]

Team,

It was noted that the signatures for the source and convenience
binaries uploaded used SHA1 digest.  I have uploaded additional
signatures for each of the three artifacts that use SHA512.  You can
validate against these signatures instead or as well using

gpg --verbose --verify nifi-0.6.1-source-release.zip.asc-SHA512
nifi-0.6.1-source-release.zip
gpg --verbose --verify nifi-0.6.1-bin.tar.gz.asc-SHA512 nifi-0.6.1-bin.tar.gz
gpg --verbose --verify nifi-0.6.1-bin.zip.asc-SHA512 nifi-0.6.1-bin.zip

Will also update the release guide to ensure this is validated next time.

Thanks
Joe

On Tue, Apr 12, 2016 at 10:48 PM, Joe Witt  wrote:
> Hello Apache NiFi community,
>
> Please find the associated guidance to help those interested in
> validating/verifying the release so they can vote.
>
> # Download latest KEYS file:
>   https://dist.apache.org/repos/dist/dev/nifi/KEYS
>
> # Import keys file:
>   gpg --import KEYS
>
> # [optional] Clear out local maven artifact repository
>
> # Pull down nifi-0.6.1 source release artifacts for review:
>
>   wget 
> https://dist.apache.org/repos/dist/dev/nifi/nifi-0.6.1/nifi-0.6.1-source-release.zip
>   wget 
> https://dist.apache.org/repos/dist/dev/nifi/nifi-0.6.1/nifi-0.6.1-source-release.zip.asc
>   wget 
> https://dist.apache.org/repos/dist/dev/nifi/nifi-0.6.1/nifi-0.6.1-source-release.zip.md5
>   wget 
> https://dist.apache.org/repos/dist/dev/nifi/nifi-0.6.1/nifi-0.6.1-source-release.zip.sha1
>
> # Verify the signature
>   gpg --verify nifi-0.6.1-source-release.zip.asc
>
> # Verify the hashes (md5, sha1) match the source and what was provided
> in the vote email thread
>   md5sum nifi-0.6.1-source-release.zip
>   sha1sum nifi-0.6.1-source-release.zip
>
> # Unzip nifi-0.6.1-source-release.zip
>
> # Verify the build works including release audit tool (RAT) checks
>   cd nifi-0.6.1
>   mvn clean install -Pcontrib-check
>
> # Verify the contents contain a good README, NOTICE, and LICENSE.
>
> # Verify the git commit ID is correct
>
> # Verify the RC was branched off the correct git commit ID
>
> # Look at the resulting convenience binary as found in nifi-assembly/target
>
> # Make sure the README, NOTICE, and LICENSE are present and correct
>
> # Run the resulting convenience binary and make sure it works as expected
>
> # Send a response to the vote thread indicating a +1, 0, -1 based on
> your findings.
>
> Thank you for your time and effort to validate the release!

Re: [VOTE] Incorporate SHA256 part of release process

[Andy LoPresto]

Fair enough. OpenSSL is pretty universal, but there are also OS-specific 
commands to perform the same task. 

Andy LoPresto
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Apr 13, 2016, at 20:13, Aldrin Piri  wrote:
> 
> As far as the wrapper script, I'm in favor of the manual process for the
> SHA256.  The arbitrary shell commands/processes in the Maven build feel too
> brittle across operating systems and this is multiplied in conjunction with
> a maintained follow on script(s).  Overall would prefer just incurring the
> "expense" on the RM to do so manually once these artifacts have been
> generated through the process currently in place.
> 
>> On Wed, Apr 13, 2016 at 9:58 PM, Andy LoPresto  wrote:
>> 
>> Tony,
>> 
>> That’s definitely a valid concern that I’m sure benefits all release
>> managers to review. The conversation below is regarding the checksums for
>> data integrity only; not the underlying hash used in the GPG signature
>> process.
>> 
>> Andy LoPresto
>> alopre...@apache.org
>> *alopresto.apa...@gmail.com *
>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>> 
>> On Apr 13, 2016, at 6:50 PM, Tony Kurc  wrote:
>> 
>> I was under the impression not using SHA-1 WAS part of our release, when we
>> were gpg signing (based off of [1]), which I assumed was the preferred form
>> of assuring an artifact was not "bad". However, it looks like it isn't in
>> our checklist to confirm that SHA-1 wasn't used to make the digital
>> signature, and it looks like 0.6.1 is using SHA1.
>> 
>> 
>> 1. http://www.apache.org/dev/openpgp.html#key-gen-avoid-sha1
>> 
>> 
>> 
>> 
>> On Wed, Apr 13, 2016 at 9:13 PM, Aldrin Piri  wrote:
>> 
>> This was mentioned in the vote thread for the RC2 release and wanted to
>> separate it out to keep the release messaging streamlined. As mentioned by
>> Andy, the MD5 and SHA1 are subject to collisions. From another viewpoint, I
>> like having this as part of the official release process as I typically
>> generate this myself when updating the associated Homebrew formula with no
>> real connection to the artifacts created other than me saying so.
>> 
>> The drawback is that the Maven plugins that drives the release
>> unfortunately does not support SHA-256.[1] As a result this would fall on
>> the RM to do so but could easily be added to the documentation we have
>> until the linked ticket is resolved.
>> 
>> This vote will be a lazy consensus and remain open for 72 hours.
>> 
>> 
>> [1] https://issues.apache.org/jira/browse/MINSTALL-82
>> 
>> 
>> 

Re: [VOTE] Incorporate SHA256 part of release process

[Aldrin Piri]

As far as the wrapper script, I'm in favor of the manual process for the
SHA256.  The arbitrary shell commands/processes in the Maven build feel too
brittle across operating systems and this is multiplied in conjunction with
a maintained follow on script(s).  Overall would prefer just incurring the
"expense" on the RM to do so manually once these artifacts have been
generated through the process currently in place.

On Wed, Apr 13, 2016 at 9:58 PM, Andy LoPresto  wrote:

> Tony,
>
> That’s definitely a valid concern that I’m sure benefits all release
> managers to review. The conversation below is regarding the checksums for
> data integrity only; not the underlying hash used in the GPG signature
> process.
>
> Andy LoPresto
> alopre...@apache.org
> *alopresto.apa...@gmail.com *
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Apr 13, 2016, at 6:50 PM, Tony Kurc  wrote:
>
> I was under the impression not using SHA-1 WAS part of our release, when we
> were gpg signing (based off of [1]), which I assumed was the preferred form
> of assuring an artifact was not "bad". However, it looks like it isn't in
> our checklist to confirm that SHA-1 wasn't used to make the digital
> signature, and it looks like 0.6.1 is using SHA1.
>
>
> 1. http://www.apache.org/dev/openpgp.html#key-gen-avoid-sha1
>
>
>
>
> On Wed, Apr 13, 2016 at 9:13 PM, Aldrin Piri  wrote:
>
> This was mentioned in the vote thread for the RC2 release and wanted to
> separate it out to keep the release messaging streamlined. As mentioned by
> Andy, the MD5 and SHA1 are subject to collisions. From another viewpoint, I
> like having this as part of the official release process as I typically
> generate this myself when updating the associated Homebrew formula with no
> real connection to the artifacts created other than me saying so.
>
> The drawback is that the Maven plugins that drives the release
> unfortunately does not support SHA-256.[1] As a result this would fall on
> the RM to do so but could easily be added to the documentation we have
> until the linked ticket is resolved.
>
> This vote will be a lazy consensus and remain open for 72 hours.
>
>
> [1] https://issues.apache.org/jira/browse/MINSTALL-82
>
>
>

Re: [VOTE] Incorporate SHA256 part of release process

[Andy LoPresto]

Tony,

That’s definitely a valid concern that I’m sure benefits all release managers 
to review. The conversation below is regarding the checksums for data integrity 
only; not the underlying hash used in the GPG signature process.

Andy LoPresto
alopre...@apache.org
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Apr 13, 2016, at 6:50 PM, Tony Kurc  wrote:
> 
> I was under the impression not using SHA-1 WAS part of our release, when we
> were gpg signing (based off of [1]), which I assumed was the preferred form
> of assuring an artifact was not "bad". However, it looks like it isn't in
> our checklist to confirm that SHA-1 wasn't used to make the digital
> signature, and it looks like 0.6.1 is using SHA1.
> 
> 
> 1. http://www.apache.org/dev/openpgp.html#key-gen-avoid-sha1
> 
> 
> 
> 
> On Wed, Apr 13, 2016 at 9:13 PM, Aldrin Piri  wrote:
> 
>> This was mentioned in the vote thread for the RC2 release and wanted to
>> separate it out to keep the release messaging streamlined. As mentioned by
>> Andy, the MD5 and SHA1 are subject to collisions. From another viewpoint, I
>> like having this as part of the official release process as I typically
>> generate this myself when updating the associated Homebrew formula with no
>> real connection to the artifacts created other than me saying so.
>> 
>> The drawback is that the Maven plugins that drives the release
>> unfortunately does not support SHA-256.[1] As a result this would fall on
>> the RM to do so but could easily be added to the documentation we have
>> until the linked ticket is resolved.
>> 
>> This vote will be a lazy consensus and remain open for 72 hours.
>> 
>> 
>> [1] https://issues.apache.org/jira/browse/MINSTALL-82
>> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [VOTE] Incorporate SHA256 part of release process

[Tony Kurc]

I was under the impression not using SHA-1 WAS part of our release, when we
were gpg signing (based off of [1]), which I assumed was the preferred form
of assuring an artifact was not "bad". However, it looks like it isn't in
our checklist to confirm that SHA-1 wasn't used to make the digital
signature, and it looks like 0.6.1 is using SHA1.


1. http://www.apache.org/dev/openpgp.html#key-gen-avoid-sha1




On Wed, Apr 13, 2016 at 9:13 PM, Aldrin Piri  wrote:

> This was mentioned in the vote thread for the RC2 release and wanted to
> separate it out to keep the release messaging streamlined. As mentioned by
> Andy, the MD5 and SHA1 are subject to collisions. From another viewpoint, I
> like having this as part of the official release process as I typically
> generate this myself when updating the associated Homebrew formula with no
> real connection to the artifacts created other than me saying so.
>
> The drawback is that the Maven plugins that drives the release
> unfortunately does not support SHA-256.[1] As a result this would fall on
> the RM to do so but could easily be added to the documentation we have
> until the linked ticket is resolved.
>
> This vote will be a lazy consensus and remain open for 72 hours.
>
>
> [1] https://issues.apache.org/jira/browse/MINSTALL-82
>

Re: [VOTE] Incorporate SHA256 part of release process

[Andy LoPresto]

Obviously a +1 for me. With regard to the plugin not supporting it, can’t Maven 
execute arbitrary Java/shell commands during build [1]? The issue on MINSTALL 
has been open since December 2012. I understand we might need a script wrapper 
to handle cross-platform functionality, but this might be easier/faster than 
waiting for MINSTALL team to fix it.

[1] http://stackoverflow.com/a/3493919/70465

Andy LoPresto
alopre...@apache.org
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Apr 13, 2016, at 6:33 PM, Matt Burgess  wrote:
> 
> +1
> 
> 
>> On Apr 13, 2016, at 6:13 PM, Aldrin Piri  wrote:
>> 
>> This was mentioned in the vote thread for the RC2 release and wanted to
>> separate it out to keep the release messaging streamlined. As mentioned by
>> Andy, the MD5 and SHA1 are subject to collisions. From another viewpoint, I
>> like having this as part of the official release process as I typically
>> generate this myself when updating the associated Homebrew formula with no
>> real connection to the artifacts created other than me saying so.
>> 
>> The drawback is that the Maven plugins that drives the release
>> unfortunately does not support SHA-256.[1] As a result this would fall on
>> the RM to do so but could easily be added to the documentation we have
>> until the linked ticket is resolved.
>> 
>> This vote will be a lazy consensus and remain open for 72 hours.
>> 
>> 
>> [1] https://issues.apache.org/jira/browse/MINSTALL-82



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [VOTE] Incorporate SHA256 part of release process

[Matt Burgess]

+1


> On Apr 13, 2016, at 6:13 PM, Aldrin Piri  wrote:
> 
> This was mentioned in the vote thread for the RC2 release and wanted to
> separate it out to keep the release messaging streamlined. As mentioned by
> Andy, the MD5 and SHA1 are subject to collisions. From another viewpoint, I
> like having this as part of the official release process as I typically
> generate this myself when updating the associated Homebrew formula with no
> real connection to the artifacts created other than me saying so.
> 
> The drawback is that the Maven plugins that drives the release
> unfortunately does not support SHA-256.[1] As a result this would fall on
> the RM to do so but could easily be added to the documentation we have
> until the linked ticket is resolved.
> 
> This vote will be a lazy consensus and remain open for 72 hours.
> 
> 
> [1] https://issues.apache.org/jira/browse/MINSTALL-82

[GitHub] nifi pull request: Nifi 1753 Removed legacy X.509 certificate impl...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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: Nifi 1753 Removed legacy X.509 certificate impl...

[alopresto]

GitHub user alopresto reopened a pull request:

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

Nifi 1753 Removed legacy X.509 certificate implementation references

Various logic throughout the application referenced 
`javax.security.cert.X509Certificate` which is a deprecated class and exists 
only for legacy compatibility with older JSSE implementations. As of Java SE 6, 
new development should use `java.security.cert.X509Certificate`. Most 
references to the legacy classes were in similar logic blocks to retrieve the 
distinguished name (DN) from the client certificate chain presented during TLS 
mutual authentication. 

I refactored this logic into a common utility method to deduplicate and 
provided utility methods for converting legacy `X509Certificate`s and the 
abstract `java.security.cert.Certificate` returned by the replacement method 
(`javax.net.ssl.SSLSession#getPeerCertificateChain()` is succeeded by 
`javax.net.ssl.SSLSession#getPeerCertificates()`) to the correct version of 
`X509Certificate`. 

The module `nifi-security-utils` was added as a dependency to `nifi-utils` 
but contains only two utility classes with static helper methods and four 
enums. This change may be reverted/expanded as part of the larger-scale work on 
NIFI-1478, NIFI-1480, etc., but that is 1.0.0 refactor work, while this was a 
surgical fix for both 0.7.0 and 1.0.0. 

This will be rebased & squashed before merging. 

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

$ git pull https://github.com/alopresto/nifi NIFI-1753

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

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


commit 2161d1e8123020e0846f6290f4f500bba84f6ef7
Author: Andy LoPresto 
Date:   2016-04-12T03:11:45Z

NIFI-1753 Replaced usage of javax.security.cert.X509Certificate with 
java.security.cert.X509Certificate and resolved user-reported 
ClassCastException when handling client certificates during TLS mutual 
authentication.

Fixed nifi-utils pom.xml comment about additional dependencies. (+5 
squashed commits)
Squashed commits:
[965b766] NIFI-1753 Removed temporary work-around of duplicate certificate 
conversion util method and added nifi-security-utils as dependency of 
nifi-utils.
[cd35f9b] NIFI-1753 Replaced legacy X.509 certificate declarations with new 
declarations in SSLSocketChannel and EndpointConnectionPool.
Temporary work-around of duplicate certificate conversion util method 
because nifi-utils cannot depend on nifi-security-utils.
[6420897] NIFI-1753 Replaced legacy X.509 certificate declarations with new 
declarations in PostHTTP.
[b9868ef] NIFI-1753 Added convenience method for extracting DN from peer 
certificate chain in SSL socket (canonical implementation to reduce code 
duplication and references to legacy certificate implementations).
Refactored logic retrieving legacy X.509 certificates with reference to 
convenience method in NodeProtocolSenderImpl.
Replaced logic retrieving legacy X.509 certificates with reference to 
convenience method in SocketProtocolListener.
Cleaned up exception handling in SocketProtocolListener.
Replaced legacy X.509 certificate declarations with new declarations in 
HandleHttpRequest (needs manual test).
[e2d1c35] NIFI-1753 Added convenience methods for converting legacy X.509 
certificates and abstract certificates to correct X.509 format.
Added unit tests for certificate manipulation.
Replaced logic retrieving legacy X.509 certificates with new logic in 
NodeProtocolSenderImpl.
Added bcpkix (Bouncy Castle PKI implementation) dependency to 
nifi-standard-processors pom.




---
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: Nifi 1753 Removed legacy X.509 certificate impl...

[alopresto]

Github user alopresto closed the pull request at:

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


---
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.
---

Re: [VOTE] Incorporate SHA256 part of release process

[Joe Witt]

+1.  I should have done it this time.

On Wed, Apr 13, 2016 at 9:13 PM, Aldrin Piri  wrote:
> This was mentioned in the vote thread for the RC2 release and wanted to
> separate it out to keep the release messaging streamlined. As mentioned by
> Andy, the MD5 and SHA1 are subject to collisions. From another viewpoint, I
> like having this as part of the official release process as I typically
> generate this myself when updating the associated Homebrew formula with no
> real connection to the artifacts created other than me saying so.
>
> The drawback is that the Maven plugins that drives the release
> unfortunately does not support SHA-256.[1] As a result this would fall on
> the RM to do so but could easily be added to the documentation we have
> until the linked ticket is resolved.
>
> This vote will be a lazy consensus and remain open for 72 hours.
>
>
> [1] https://issues.apache.org/jira/browse/MINSTALL-82

[VOTE] Incorporate SHA256 part of release process

[Aldrin Piri]

This was mentioned in the vote thread for the RC2 release and wanted to
separate it out to keep the release messaging streamlined. As mentioned by
Andy, the MD5 and SHA1 are subject to collisions. From another viewpoint, I
like having this as part of the official release process as I typically
generate this myself when updating the associated Homebrew formula with no
real connection to the artifacts created other than me saying so.

The drawback is that the Maven plugins that drives the release
unfortunately does not support SHA-256.[1] As a result this would fall on
the RM to do so but could easily be added to the documentation we have
until the linked ticket is resolved.

This vote will be a lazy consensus and remain open for 72 hours.


[1] https://issues.apache.org/jira/browse/MINSTALL-82

Re: Observation regarding PutKafka while implementing NIFI-1672

[Oleg Zhurakousky]

Pierre

You're absolutely correct. The explanation was valid, but there were problems 
with the original implementation of how it was described, so that changed, but 
we didn't update the docs


> On Apr 13, 2016, at 16:24, Pierre Villard  wrote:
> 
> Hi,
> 
> I was working on NIFI-1672 [1], and while performing some tests with a
> local running Kafka instance, I noticed there is a possible error regarding
> how the behavior of the processor is documented.
> 
> The "Message delimiter" property is documented with:
> 
> "Specifies the delimiter (interpreted in its UTF-8 byte representation) to
> use for splitting apart multiple messages within a single FlowFile. If not
> specified, the entire content of the FlowFile will be used as a single
> message. If specified, the contents of the FlowFile will be split on this
> delimiter and each section sent as a separate Kafka message. Note that if
> messages are delimited and some messages for a given FlowFile are
> transferred successfully while others are not, the messages will be split
> into individual FlowFiles, such that those messages that were successfully
> sent are routed to the 'success' relationship while other messages are sent
> to the 'failure' relationship."
> 
> I believe that the part "Note that if messages are delimited and some
> messages for a given FlowFile are transferred successfully while others are
> not, the messages will be split into individual FlowFiles, such that those
> messages that were successfully sent are routed to the 'success'
> relationship while other messages are sent to the 'failure' relationship."
> is incorrect.
> 
> Instead I would say that the behavior (at least, it is what I observed) is:
> if one or multiple messages inside the FlowFile are not transferred
> successfully to Kafka, those messages are "tagged" thanks to some custom
> attributes of the FlowFile and the whole FlowFile is sent to 'failure'
> relationship. In case the 'failure' relationship is plugged back on the
> PutKafka processor, only the messages previously in error will be sent to
> Kafka.
> 
> I believe the documentation should be updated to reflect the current
> behavior. Should I do it as part of NIFI-1672? Or create a specific JIRA
> for that? In addition, should I create a JIRA to implement the behavior
> where FlowFile are splitted as currently documented?
> 
> Since Kafka processors have been source of discussions lately, advice and
> comments are welcomed!
> 
> Thanks !
> Pierre
> 
> [1] https://issues.apache.org/jira/browse/NIFI-1672

Observation regarding PutKafka while implementing NIFI-1672

[Pierre Villard]

Hi,

I was working on NIFI-1672 [1], and while performing some tests with a
local running Kafka instance, I noticed there is a possible error regarding
how the behavior of the processor is documented.

The "Message delimiter" property is documented with:

"Specifies the delimiter (interpreted in its UTF-8 byte representation) to
use for splitting apart multiple messages within a single FlowFile. If not
specified, the entire content of the FlowFile will be used as a single
message. If specified, the contents of the FlowFile will be split on this
delimiter and each section sent as a separate Kafka message. Note that if
messages are delimited and some messages for a given FlowFile are
transferred successfully while others are not, the messages will be split
into individual FlowFiles, such that those messages that were successfully
sent are routed to the 'success' relationship while other messages are sent
to the 'failure' relationship."

I believe that the part "Note that if messages are delimited and some
messages for a given FlowFile are transferred successfully while others are
not, the messages will be split into individual FlowFiles, such that those
messages that were successfully sent are routed to the 'success'
relationship while other messages are sent to the 'failure' relationship."
is incorrect.

Instead I would say that the behavior (at least, it is what I observed) is:
if one or multiple messages inside the FlowFile are not transferred
successfully to Kafka, those messages are "tagged" thanks to some custom
attributes of the FlowFile and the whole FlowFile is sent to 'failure'
relationship. In case the 'failure' relationship is plugged back on the
PutKafka processor, only the messages previously in error will be sent to
Kafka.

I believe the documentation should be updated to reflect the current
behavior. Should I do it as part of NIFI-1672? Or create a specific JIRA
for that? In addition, should I create a JIRA to implement the behavior
where FlowFile are splitted as currently documented?

Since Kafka processors have been source of discussions lately, advice and
comments are welcomed!

Thanks !
Pierre

[1] https://issues.apache.org/jira/browse/NIFI-1672

Re: NPE in PutKafka processors

[McDermott, Chris Kevin (MSDU - STaTS/StorefrontRemote)]

Here is a probable patch. I’ve tested it and it seems to do the trick.

diff --git 
a/nifi-nar-bundles/nifi-kafka-bundle/nifi-kafka-processors/src/main/java/org/apache/nifi/processors/kafka/PutKafka.java
 
b/nifi-nar-bundles/nifi-kafka-bundle/nifi-kafka-processors/src/main/java/org/apache/nifi/processors/kafka/PutKafka.java
index 3b5eb4f..19e06ea 100644
--- 
a/nifi-nar-bundles/nifi-kafka-bundle/nifi-kafka-processors/src/main/java/org/apache/nifi/processors/kafka/PutKafka.java
+++ 
b/nifi-nar-bundles/nifi-kafka-bundle/nifi-kafka-processors/src/main/java/org/apache/nifi/processors/kafka/PutKafka.java
@@ -1,4 +1,5 @@
 /*
+
  * Licensed to the Apache Software Foundation (ASF) under one or more
  * contributor license agreements.  See the NOTICE file distributed with
  * this work for additional information regarding copyright ownership.
@@ -393,7 +394,7 @@ public class PutKafka extends AbstractProcessor {
 attributes.put(ATTR_FAILED_SEGMENTS, new 
String(failedSegments.toByteArray(), StandardCharsets.UTF_8));
 attributes.put(ATTR_TOPIC, messageContext.getTopicName());
 attributes.put(ATTR_KEY, messageContext.getKeyBytesAsString());
-attributes.put(ATTR_DELIMITER, new 
String(messageContext.getDelimiterBytes(), StandardCharsets.UTF_8));
+attributes.put(ATTR_DELIMITER, 
messageContext.getDelimeterBytesAsString());
 return attributes;
 }

diff --git 
a/nifi-nar-bundles/nifi-kafka-bundle/nifi-kafka-processors/src/main/java/org/apache/nifi/processors/kafka/SplittableMessageContext.java
 
b/nifi-nar-bundles/nifi-kafka-bundle/nifi-kafka-processors/src/main/java/org/apache/nifi/processors/kafka/SplittableMessageContext.java
index d5f1c0b..4d63b7b 100644
--- 
a/nifi-nar-bundles/nifi-kafka-bundle/nifi-kafka-processors/src/main/java/org/apache/nifi/processors/kafka/SplittableMessageContext.java
+++ 
b/nifi-nar-bundles/nifi-kafka-bundle/nifi-kafka-processors/src/main/java/org/apache/nifi/processors/kafka/SplittableMessageContext.java
@@ -16,6 +16,7 @@
  */
 package org.apache.nifi.processors.kafka;

+import java.nio.charset.Charset;
 import java.nio.charset.StandardCharsets;
 import java.util.BitSet;

@@ -108,6 +109,13 @@ final class SplittableMessageContext {
 }

 /**
+ * Returns the delimiter bytes as String
+ */
+String getDelimeterBytesAsString() {
+return this.delimiterBytes != null ? new String(this.delimiterBytes, 
StandardCharsets.UTF_8) : null;
+}
+
+/**
  * Returns the key bytes as String
  */
 String getKeyBytesAsString() {







On 4/13/16, 2:54 PM, "McDermott, Chris Kevin (MSDU - STaTS/StorefrontRemote)" 
 wrote:

>Hi!
>
>I’m running a 0.7.0 snapshot version and am running into an NPE with the 
>PutKafka processor.
>
>I’m thinking Oleg would be interested in this.
>
>java.lang.NullPointerException: null
>at java.lang.String.(String.java:503) ~[na:1.8.0_45]
>at 
>org.apache.nifi.processors.kafka.PutKafka.buildFailedFlowFileAttributes(PutKafka.java:396)
> ~[na:na]
>at org.apache.nifi.processors.kafka.PutKafka.onTrigger(PutKafka.java:308) 
>~[na:na]
>at 
>org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
> ~[nifi-api-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT]
>at 
>org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1059)
> ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT]
>at 
>org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136)
> [nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT]
>at 
>org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47)
> [nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT]
>at 
>org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:123)
> [nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT]
>at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
>[na:1.8.0_45]
>at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
>[na:1.8.0_45]
>at 
>java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [na:1.8.0_45]
>at 
>java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [na:1.8.0_45]
>
>Thanks,
>
>Chris

[GitHub] nifi-minifi pull request: MINIFI-15 Created a config file format w...

[JPercivall]

GitHub user JPercivall opened a pull request:

https://github.com/apache/nifi-minifi/pull/8

MINIFI-15 Created a config file format with documentation, and a Util…

… class to transform prospective config.yml into flow.xml and 
nifi.properties

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

$ git pull https://github.com/JPercivall/nifi-minifi MINIFI-15

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

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


commit 345576f8d52f970cf9d74d0824879c3a90ffb0aa
Author: Joseph Percivall 
Date:   2016-03-30T18:14:15Z

MINIFI-15 Created a config file format with documentation, and a Util class 
to transform prospective config.yml into flow.xml and nifi.properties




---
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-minifi pull request: MINIFI-2 Created a Util class to transfo...

[JPercivall]

Github user JPercivall closed the pull request at:

https://github.com/apache/nifi-minifi/pull/1


---
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.
---

Re: NPE in PutKafka processors

[Joe Witt]

Chris,

That line is 'attributes.put(ATTR_DELIMITER, new
String(messageContext.getDelimiterBytes(), StandardCharsets.UTF_8));'

Therefore it appears to assume there is a delimiter which is not
correct and should be guarded.  Here is the JIRA for it.  In your use
case you might be able to get away with using a bogus delimiter of say
\n to work around this.  Here is a JIRA for it
https://issues.apache.org/jira/browse/NIFI-1764

Thanks
JOe

On Wed, Apr 13, 2016 at 2:54 PM, McDermott, Chris Kevin (MSDU -
STaTS/StorefrontRemote)  wrote:
> Hi!
>
> I’m running a 0.7.0 snapshot version and am running into an NPE with the 
> PutKafka processor.
>
> I’m thinking Oleg would be interested in this.
>
> java.lang.NullPointerException: null
> at java.lang.String.(String.java:503) ~[na:1.8.0_45]
> at 
> org.apache.nifi.processors.kafka.PutKafka.buildFailedFlowFileAttributes(PutKafka.java:396)
>  ~[na:na]
> at org.apache.nifi.processors.kafka.PutKafka.onTrigger(PutKafka.java:308) 
> ~[na:na]
> at 
> org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
>  ~[nifi-api-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT]
> at 
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1059)
>  ~[nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT]
> at 
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136)
>  [nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT]
> at 
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47)
>  [nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT]
> at 
> org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:123)
>  [nifi-framework-core-0.7.0-SNAPSHOT.jar:0.7.0-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_45]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [na:1.8.0_45]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_45]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>  [na:1.8.0_45]
>
> Thanks,
>
> Chris

Re: [DISCUSS] From Contributor to Committer

[Joe Witt]

Tony,

I agree with the points you raise and the completeness of the
perspective you share. I do think we should add to that a focus on
licensing and legal aspects.

- The individual has shown an effort to aid the community in producing
release which are consistent with ASF licensing requirements and the
guidance followed in the Apache NiFi community to adhere to those
policies.  This understanding could be shown when introducing new
dependencies (including transitive) by ensuring that all licensing and
notice updates have occurred.  Another good example is flagging
potentially copyrighted or insufficiently cited items like Skora found
recently in the Kafka tests.  One of our most important jobs as a
community is to put out legal releases and that is certainly a team
effort!

Thanks
Joe

On Sun, Apr 10, 2016 at 10:56 PM, Sean Busbey  wrote:
> Thanks for starting this Tony!
>
> As a PMC member, I really try to focus on things that help the
> community where we tend to have limited bandwidth: reviews weigh
> heavily, as does helping out new folks on users@, and doing public
> talking/workshops.
>
> I also am inclined to vote in favor of folks who show the kind of
> project dedication that we expect from PMC members. While we still
> need to do a better job of describing those things, at the moment I'm
> thinking of things like voting on release candidates, watching out for
> our trademarks, and investing the time needed to handle our licensing
> responsibilities.
>
> On Sun, Apr 10, 2016 at 9:38 AM, Tony Kurc  wrote:
>> First off, I recommend this reading this page to understand what the Apache
>> NiFi PMC draws from when making a decision
>>
>> http://community.apache.org/contributors/index.html
>>
>> I thought it would be helpful for me to walk through how I interpret that
>> guidance, and what that means for NiFi. For those that didn't read, there
>> are four aspects of contribution that are worth considering someone for
>> committership: community, project, documentation and code. Really, the
>> committer decision comes down to: has this person built up enough merit in
>> the community that I have a high degree of confidence that I trust him/her
>> with write access to the code and website.
>>
>> Given that merit and trust are subjective measures, how does the PMC make
>> those decisions? We, the PMC, have attempted to make this as evidence-based
>> as possible. When discussing a contributor for being considered for
>> committer access, we attempt to put together a corpus of interaction in the
>> community, both negative and positive, and use this as a basis for
>> discussion. The interaction with the community can include:
>>
>> - Interaction on the mailing lists - is this person helping others? Is this
>> person using the community to enhance his/her understanding of the project
>> or the apache foundation?
>> - Code contributions - is this person contributing code that advances the
>> project? How important is the code? Is this a niche capability, a core
>> capability? How challenging was the code? Was the code improving the
>> quality of the project (bug fix, adding  tests, or code that comes along
>> with comprehensive unit and/or integration tests). How does this person
>> react to criticism of his/her contribution? Is this person reacting
>> positively to patch or pull request feedback? Is the code high quality?
>> - Assisting others with their contributions - is this person providing
>> useful comments on pull requests or patches? Is this person testing new
>> features/functionality and providing feedback on the mailing list?
>> - Participating in project votes and discussions: is this person helping to
>> verify releases? Providing input to the roadmap? Is this person using the
>> lists to get feedback on features he/she plan to implement?
>> - Documentation contributions - is this person helping the community by
>> blogging? providing patches to the web page or in-app docs? contributing to
>> the project wiki?
>> - Other community/project activities - has this person organized or talked
>> at a meetup? has this person briefed at a conference or workshop?
>> - "Going over and beyond" factor - Has this person done something
>> exceptional to demonstrate dedication to the project? e.g. did this person
>> go to great lengths to fix or diagnose a critical issue?
>>
>> An underlying theme of the above: the ASF code of conduct [1] is taken
>> seriously by the PMC - while interacting with the community, was this
>> person adhering to the guidelines? Are we seeing a pattern of openness,
>> empathy, inquisitiveness, and willingness to cooperate? Has this person
>> shown remorse for interaction that may have violated the code of conduct
>> and a positive trend since?
>>
>> It helps for a committer to have evidence supporting all four aspects of
>> contribution. It also helps to have demonstrated this over an extended
>> period of time. I personally like to see at 

Re: NiFi Web UI development in Dreamweaver

[Rob Moran]

Colin,

Just wanted to echo some of the comments from other responses so far and
say welcome. I've been putting together the mockups you see in NIFI-1323
. The initial goal is to
modernize a bit for a nice foundation as we plan more key functionality and
end-user experience improvements. Again, if you're interested we'd
appreciate your opinions on that effort.

Also - I'd be interested in your results using Dreamweaver. As a designer I
primarily use Adobe Illustrator, but I have access to Dreamweaver and if I
could leverage it to help on the implementation/development side that'd be
great.

Rob

On Wed, Apr 13, 2016 at 1:58 PM, Matt Gilman 
wrote:

> Colin,
>
> Thanks for checking out Apache NiFi. The UI is a packaged as a Java web
> application that is built as part of NiFi's build process. NiFi uses Maven
> to build and package the application. You should be able to edit the
> sources that comprise that WAR with any IDE that can import Maven projects.
> At that point, you should be able to edit all the JSP files, Javascript
> files, and CSS files.
>
> As Joe mentioned, there is currently an effort underway to fresh the look
> and feel as described in NIFI-1323. Let me know if you have any other
> questions.
>
> Matt
>
> On Wed, Apr 13, 2016 at 12:49 PM, Joe Witt  wrote:
>
> > Colin,
> >
> > I'll defer to others to comment on the specifics around dreamweaver or
> > other tools but I do want to reach out and suggest you could also
> > contribute to https://issues.apache.org/jira/browse/NIFI-1323 which is
> > part of the NiFi 1.0.0 efforts and is under active design/discussion
> > and implementation.  By no means should that deter from whatever else
> > you might want to do but if you're interested happy to hear your
> > opinions there.
> >
> > Thanks
> > Joe
> >
> > On Wed, Apr 13, 2016 at 11:46 AM, Colin Bowdery
> >  wrote:
> > > Hi All,
> > >
> > > Can anyone provide any pointers as to how I might be able to develop
> the
> > NiFi Web UI using a tool such as Dreamweaver? I have been modifying
> > nifi-web-ui-0.6.0-SNAPSHOT.war manually but would really like to use a
> more
> > professional approach. I also note there are no HTML files in this .war.
> > >
> > > Objective is to test out some alternative layouts, styling, test
> various
> > browser support and benchmark performance. I am happy to share the
> results
> > back to the dev team.
> > >
> > > Many thanks,
> > >
> > >
> > > Colin.
> > >
> >
>

Re: NiFi Web UI development in Dreamweaver

[Matt Gilman]

Colin,

Thanks for checking out Apache NiFi. The UI is a packaged as a Java web
application that is built as part of NiFi's build process. NiFi uses Maven
to build and package the application. You should be able to edit the
sources that comprise that WAR with any IDE that can import Maven projects.
At that point, you should be able to edit all the JSP files, Javascript
files, and CSS files.

As Joe mentioned, there is currently an effort underway to fresh the look
and feel as described in NIFI-1323. Let me know if you have any other
questions.

Matt

On Wed, Apr 13, 2016 at 12:49 PM, Joe Witt  wrote:

> Colin,
>
> I'll defer to others to comment on the specifics around dreamweaver or
> other tools but I do want to reach out and suggest you could also
> contribute to https://issues.apache.org/jira/browse/NIFI-1323 which is
> part of the NiFi 1.0.0 efforts and is under active design/discussion
> and implementation.  By no means should that deter from whatever else
> you might want to do but if you're interested happy to hear your
> opinions there.
>
> Thanks
> Joe
>
> On Wed, Apr 13, 2016 at 11:46 AM, Colin Bowdery
>  wrote:
> > Hi All,
> >
> > Can anyone provide any pointers as to how I might be able to develop the
> NiFi Web UI using a tool such as Dreamweaver? I have been modifying
> nifi-web-ui-0.6.0-SNAPSHOT.war manually but would really like to use a more
> professional approach. I also note there are no HTML files in this .war.
> >
> > Objective is to test out some alternative layouts, styling, test various
> browser support and benchmark performance. I am happy to share the results
> back to the dev team.
> >
> > Many thanks,
> >
> >
> > Colin.
> >
>

Re: NiFi Web UI development in Dreamweaver

[Joe Witt]

Colin,

I'll defer to others to comment on the specifics around dreamweaver or
other tools but I do want to reach out and suggest you could also
contribute to https://issues.apache.org/jira/browse/NIFI-1323 which is
part of the NiFi 1.0.0 efforts and is under active design/discussion
and implementation.  By no means should that deter from whatever else
you might want to do but if you're interested happy to hear your
opinions there.

Thanks
Joe

On Wed, Apr 13, 2016 at 11:46 AM, Colin Bowdery
 wrote:
> Hi All,
>
> Can anyone provide any pointers as to how I might be able to develop the NiFi 
> Web UI using a tool such as Dreamweaver? I have been modifying 
> nifi-web-ui-0.6.0-SNAPSHOT.war manually but would really like to use a more 
> professional approach. I also note there are no HTML files in this .war.
>
> Objective is to test out some alternative layouts, styling, test various 
> browser support and benchmark performance. I am happy to share the results 
> back to the dev team.
>
> Many thanks,
>
>
> Colin.
>

NiFi Web UI development in Dreamweaver

[Colin Bowdery]

Hi All,

Can anyone provide any pointers as to how I might be able to develop the NiFi 
Web UI using a tool such as Dreamweaver? I have been modifying 
nifi-web-ui-0.6.0-SNAPSHOT.war manually but would really like to use a more 
professional approach. I also note there are no HTML files in this .war.

Objective is to test out some alternative layouts, styling, test various 
browser support and benchmark performance. I am happy to share the results back 
to the dev team.

Many thanks,


Colin.
  

Re: catch commit error in OnTrigger to diversify session behaviour

[Matt Burgess]

Upon a TitanException in your load() method, you could wrap it in an 
IOException and re-throw, and rather than print the stack trace, you can catch 
the IOException in onTrigger() and send to failure. You likely won't want to 
rollback the session if you're transferring to failure; the user can choose to 
route the failure relationship however they want (perhaps back to the 
processor). However you probably want to penalize the flow file since it causes 
the error.

If the TitanException can be caused by network issues or something not related 
to the flow file content itself, you may want to throw various types of 
Exceptions and route the those flow files who are impacted by non-flowfile 
related errors) to a "retry" relationship, indicating that the same operation 
may work at a later time.

Regards,
Matt


> On Apr 13, 2016, at 6:14 AM, idioma  wrote:
> 
> Hi,
> I have a custom Apache NiFi processor whose aim is to load a sample graph
> into Titan Db. I have a load method that creates the graph with a few
> vertices/edges and commits the transaction (transaction.commit() is wrapped
> around a try/catch block to catch any TitanException). Inside my On Trigger
> I have the following:
> 
> @Override
>public void onTrigger(final ProcessContext context, final ProcessSession
> session) throws ProcessException {
> 
>FlowFile flowFile = session.get();
>if (flowFile == null) return;
> 
>session.read(flowFile, new InputStreamCallback() {
> 
>@Override
>public void process(InputStream in) throws IOException {
> 
>StringWriter strWriter = new StringWriter();
>IOUtils.copy(in, strWriter, "UTF-8");
>String contents = strWriter.toString();
> 
>try {
>load(contents);
>} catch (IOException e) {
>e.printStackTrace();
>}
>}
>});
> }
> 
> The load method takes a string, which is the conversion from the InpuStream.
> I am trying to find a way to, according to the commit being successfully or
> not, jump into a session.rollback(true); session.transfer(flowFile, FAILURE)
> or session.transfer(flowFile, SUCCESS)
> 
> Can you help please?
> 
> 
> 
> --
> View this message in context: 
> http://apache-nifi-developer-list.39713.n7.nabble.com/catch-commit-error-in-OnTrigger-to-diversify-session-behaviour-tp9027.html
> Sent from the Apache NiFi Developer List mailing list archive at Nabble.com.

[GitHub] nifi pull request: Adding requirejs, angularjs and its dependencie...

[mcgilman]

Github user mcgilman commented on the pull request:

https://github.com/apache/nifi/pull/331#issuecomment-209420782
  
@scottyaslan Looks like you need to update the `apache-rat-plugin` 
configuration to exclude [1] the angular stuff that's been introduced. Let me 
know if you have any questions.

[1] 
https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui/pom.xml#L674


---
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: NIFI-1724 Added properties to configure log lev...

[pvillard31]

GitHub user pvillard31 opened a pull request:

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

NIFI-1724 Added properties to configure log level when file not found and 
permission denied on FetchFile processor



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

$ git pull https://github.com/pvillard31/nifi NIFI-1724

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

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


commit f8ac10e40a9632b601b6d9f4011a3380b7e82899
Author: Pierre Villard 
Date:   2016-04-13T12:21:43Z

NIFI-1724 Added properties to configure log level when file not found and 
permission denied on FetchFile 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.
---

Re: [VOTE] Release Apache NiFi 0.6.1 (RC2)

[Pierre Villard]

+1 (non-binding)

Ran through the helper release guide.
Maven build with tests and contrib-check OK on Windows 10.
Tested some flow, everything looks OK.

Pierre


2016-04-13 4:47 GMT+02:00 Joe Witt :

> Hello Apache NiFi Community,
>
> I am pleased to be calling this vote for the source release of Apache
> NiFi 0.6.1.
>
> The source zip, including signatures, digests, etc. can be found at:
>  https://dist.apache.org/repos/dist/dev/nifi/nifi-0.6.1/
>
> The Git tag is nifi-0.6.1-RC2
> The Git commit hash is 1a67b4de2e504bbe1a0cdbd6cccd949f997a5ad5
> *
> https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=1a67b4de2e504bbe1a0cdbd6cccd949f997a5ad5
> *
> https://github.com/apache/nifi/commit/1a67b4de2e504bbe1a0cdbd6cccd949f997a5ad5
>
> Checksums of nifi-0.6.1-source-release.zip:
> MD5: 5bb2b80e0384f89e6055ad4b0dd45294
> SHA1: b262664ed077f28623866d2a1090a4034dc3c04a
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/joewitt.asc
>
> KEYS file available here:
> https://dist.apache.org/repos/dist/release/nifi/KEYS
>
> 13 issues were closed/resolved for this release:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12335496
> Release note highlights can be found here:
>
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version0.6.1
>
> The vote will be open for 72 hours.
> Please download the release candidate and evaluate the necessary items
> including checking hashes, signatures, build from source, and test. Then
> please vote:
>
> [ ] +1 Release this package as nifi-0.6.1
> [ ] +0 no opinion
> [ ] -1 Do not release this package because...
>
> Thanks!
>

[GitHub] nifi pull request: NIFI-1755 Fixed remote process group status cou...

[pvillard31]

GitHub user pvillard31 opened a pull request:

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

NIFI-1755 Fixed remote process group status counts by only considering 
connected remote ports



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

$ git pull https://github.com/pvillard31/nifi NIFI-1755

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

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


commit 147f528eb8e5e7a4da5f6e49c5f16657227d5e58
Author: Pierre Villard 
Date:   2016-04-13T09:31:23Z

NIFI-1755 Fixed remote process group status counts by only considering 
connected remote ports




---
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.
---