[GitHub] nifi issue #2030: NIFI-4212 - RethinkDB Delete Processor

[mans2singh]

Github user mans2singh commented on the issue:

https://github.com/apache/nifi/pull/2030
  
Thanks @jvwing 


---
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-4212) Create RethinkDB Delete Processor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4212:
--

Github user mans2singh commented on the issue:

https://github.com/apache/nifi/pull/2030
  
Thanks @jvwing 


> Create RethinkDB Delete Processor
> -
>
> Key: NIFI-4212
> URL: https://issues.apache.org/jira/browse/NIFI-4212
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: 1.3.0
>Reporter: Mans Singh
>Assignee: Mans Singh
>Priority: Minor
>  Labels: delete, rethinkdb
> Fix For: 1.4.0
>
>
> Create processor to delete RethinkDB documents by id.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (NIFI-4212) Create RethinkDB Delete Processor

[James Wing (JIRA)]

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

James Wing resolved NIFI-4212.
--
Resolution: Fixed

> Create RethinkDB Delete Processor
> -
>
> Key: NIFI-4212
> URL: https://issues.apache.org/jira/browse/NIFI-4212
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: 1.3.0
>Reporter: Mans Singh
>Assignee: Mans Singh
>Priority: Minor
>  Labels: delete, rethinkdb
> Fix For: 1.4.0
>
>
> Create processor to delete RethinkDB documents by id.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-4212) Create RethinkDB Delete Processor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4212:
--

Github user asfgit closed the pull request at:

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


> Create RethinkDB Delete Processor
> -
>
> Key: NIFI-4212
> URL: https://issues.apache.org/jira/browse/NIFI-4212
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: 1.3.0
>Reporter: Mans Singh
>Assignee: Mans Singh
>Priority: Minor
>  Labels: delete, rethinkdb
> Fix For: 1.4.0
>
>
> Create processor to delete RethinkDB documents by id.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-4212) Create RethinkDB Delete Processor

[ASF subversion and git services (JIRA)]

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

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

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

NIFI-4212 - RethinkDB Delete Processor

Signed-off-by: James Wing 

This closes #2030.


> Create RethinkDB Delete Processor
> -
>
> Key: NIFI-4212
> URL: https://issues.apache.org/jira/browse/NIFI-4212
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: 1.3.0
>Reporter: Mans Singh
>Assignee: Mans Singh
>Priority: Minor
>  Labels: delete, rethinkdb
> Fix For: 1.4.0
>
>
> Create processor to delete RethinkDB documents by id.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi pull request #2030: NIFI-4212 - RethinkDB Delete Processor

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 #2030: NIFI-4212 - RethinkDB Delete Processor

[jvwing]

Github user jvwing commented on the issue:

https://github.com/apache/nifi/pull/2030
  
Thanks for fixing those items, @mans2singh, I'll get this merged. 


---
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-4212) Create RethinkDB Delete Processor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4212:
--

Github user jvwing commented on the issue:

https://github.com/apache/nifi/pull/2030
  
Thanks for fixing those items, @mans2singh, I'll get this merged. 


> Create RethinkDB Delete Processor
> -
>
> Key: NIFI-4212
> URL: https://issues.apache.org/jira/browse/NIFI-4212
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: 1.3.0
>Reporter: Mans Singh
>Assignee: Mans Singh
>Priority: Minor
>  Labels: delete, rethinkdb
> Fix For: 1.4.0
>
>
> Create processor to delete RethinkDB documents by id.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (NIFI-4239) Implement a CaptureChangePostgreSQL processor

[Gerdan Santos (JIRA)]

Gerdan Santos created NIFI-4239:
---

 Summary: Implement a CaptureChangePostgreSQL processor
 Key: NIFI-4239
 URL: https://issues.apache.org/jira/browse/NIFI-4239
 Project: Apache NiFi
  Issue Type: New Feature
  Components: Extensions
Reporter: Gerdan Santos


Inspired on CaptureChangeMySQL, this processor can use one Streaming 
Replication PostgreSQL Connection to allow access to their transactional logs 
and such, in order for external clients to have a "change data capture" (CDC) 
capability.

The processor would include properties needed for PostgreSQL connectivity 
PostgreSQL Streaming Replication. It would also need to keep a "sequence ID" 
such that an EnforceOrder processor (NIFI-3414) for example could guarantee the 
order of CDC events for use cases such as replication. 
It will likely need State Management for that, and may need other facilities 
such as a DistributedMapCache in order to keep information (column names and 
types, e.g.) that enrich the raw CDC events.

The processor would accept no incoming connections (it is a "get" or source 
processor), would be intended to run on the primary node only as a single 
threaded processor, and would generate a flow file for each operation (INSERT, 
UPDATE, DELETE, e.g.) in one or some number of formats (JSON, e.g.).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi issue #2034: NIFI-4215 Fixed stackoverflow error when NiFi tries to par...

[jvwing]

Github user jvwing commented on the issue:

https://github.com/apache/nifi/pull/2034
  
@Wesley-Lawrence  I think this is a good fix, your approach to the solution 
seems solid.  Thanks for adding the unit tests for the recursive and 
mutually-referential cases.  Would you please:

1. Fix the checkstyle issue and remove the change to the checkstyle 
definitions
1. Optionally change the foundSchemas/knownRecordTypes exception message
1. Squash and rebase on 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-4215) Avro schemas with records that have a field of themselves fail to parse, causing stackoverflow exception

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4215:
--

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

https://github.com/apache/nifi/pull/2034#discussion_r130225722
  
--- Diff: 
nifi-nar-bundles/nifi-extension-utils/nifi-record-utils/nifi-avro-record-utils/src/main/java/org/apache/nifi/avro/AvroTypeUtil.java
 ---
@@ -218,6 +218,15 @@ private static Schema nullable(final Schema schema) {
  * @return a Data Type that corresponds to the given Avro Schema
  */
 public static DataType determineDataType(final Schema avroSchema) {
+return determineDataType(avroSchema, new HashMap<>());
+}
+
+public static DataType determineDataType(final Schema avroSchema, 
Map knownRecordTypes) {
+
+if (knownRecordTypes == null) {
+throw new IllegalArgumentException("'foundSchemas' cannot be 
null.");
--- End diff --

Did you mean this to say "knownRecordTypes" rather than "foundSchemas"?


> Avro schemas with records that have a field of themselves fail to parse, 
> causing stackoverflow exception
> 
>
> Key: NIFI-4215
> URL: https://issues.apache.org/jira/browse/NIFI-4215
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.4.0
>Reporter: Wesley L Lawrence
>Priority: Minor
> Fix For: 1.4.0
>
> Attachments: nifi-4215.patch
>
>
> Noticed this while attempting to use the AvroSchemaRegsitry with some complex 
> schema. Boiled down, Avro lets you define a schema such as;
> {code}
> { 
>   "namespace": "org.apache.nifi.testing", 
>   "name": "CompositRecord", 
>   "type": "record", 
>   "fields": [ 
> { 
>   "name": "id", 
>   "type": "int" 
> }, 
> { 
>   "name": "value", 
>   "type": "string" 
> }, 
> { 
>   "name": "parent", 
>   "type": [
> "null",
> "CompositRecord"
>   ]
> } 
>   ] 
> }
> {code}
> The AvroSchemaRegistry (AvroTypeUtil specifically) will fail to parse, and 
> generate a stackoverflow exception.
> I've whipped up a fix, tested it out in 1.4.0, and am just running through 
> the contrib build before I submit a patch.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi pull request #2034: NIFI-4215 Fixed stackoverflow error when NiFi tries...

[jvwing]

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

https://github.com/apache/nifi/pull/2034#discussion_r130225722
  
--- Diff: 
nifi-nar-bundles/nifi-extension-utils/nifi-record-utils/nifi-avro-record-utils/src/main/java/org/apache/nifi/avro/AvroTypeUtil.java
 ---
@@ -218,6 +218,15 @@ private static Schema nullable(final Schema schema) {
  * @return a Data Type that corresponds to the given Avro Schema
  */
 public static DataType determineDataType(final Schema avroSchema) {
+return determineDataType(avroSchema, new HashMap<>());
+}
+
+public static DataType determineDataType(final Schema avroSchema, 
Map knownRecordTypes) {
+
+if (knownRecordTypes == null) {
+throw new IllegalArgumentException("'foundSchemas' cannot be 
null.");
--- End diff --

Did you mean this to say "knownRecordTypes" rather than "foundSchemas"?


---
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-4222) TLS Toolkit should provide SAN by default

[Pierre Villard (JIRA)]

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

Pierre Villard updated NIFI-4222:
-
Status: Patch Available  (was: Open)

> TLS Toolkit should provide SAN by default
> -
>
> Key: NIFI-4222
> URL: https://issues.apache.org/jira/browse/NIFI-4222
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Tools and Build
>Affects Versions: 1.3.0
>Reporter: Andy LoPresto
>Assignee: Pierre Villard
>  Labels: security, tls, tls-toolkit
>
> As of Chrome 58, the browser will only use the *SubjectAlternativeName* 
> entries to determine hostname verification, rather than the *CN*. This is 
> specified in RFC 6215 [1], TLS hostname verification must attempt to use the 
> SAN entries first and may only use the CN entry if no SAN entries are 
> available. 
> Chrome takes this a step further [2]: 
> {quote}
> During Transport Layer Security (TLS) connections, Chrome browser checks to 
> make sure the connection to the site is using a valid, trusted server 
> certificate.
> For Chrome 58 and later, only the subjectAlternativeName extension, not 
> commonName, is used to match the domain name and site certificate. The 
> certificate subject alternative name can be a domain name or IP address. If 
> the certificate doesn’t have the correct subjectAlternativeName extension, 
> users get a NET::ERR_CERT_COMMON_NAME_INVALID error letting them know that 
> the connection isn’t private. If the certificate is missing a 
> subjectAlternativeName extension, users see a warning in the Security panel 
> in Chrome DevTools that lets them know the subject alternative name is 
> missing.
> {quote}
> As this will cause issues for users who do not manually provide a SAN when 
> generating their certificates using the TLS Toolkit, the toolkit should be 
> modified to automatically include the provided CN as a SAN entry, in addition 
> to any manually-provided SAN entries. 
> [1] https://tools.ietf.org/html/rfc6125#section-6.4.4
> [2] https://support.google.com/chrome/a/answer/7391219?hl=en



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-4222) TLS Toolkit should provide SAN by default

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4222:
--

GitHub user pvillard31 opened a pull request:

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

NIFI-4222 - Adding CN by default in SANs for generated certificates w…

…ith tls-toolkit

Thank you for submitting a contribution to Apache NiFi.

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

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

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

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

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

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

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

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


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

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

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

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


commit fa447d3f641214bbe05e936fd9259640b48af4b9
Author: Pierre Villard 
Date:   2017-07-29T10:38:14Z

NIFI-4222 - Adding CN by default in SANs for generated certificates with 
tls-toolkit




> TLS Toolkit should provide SAN by default
> -
>
> Key: NIFI-4222
> URL: https://issues.apache.org/jira/browse/NIFI-4222
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Tools and Build
>Affects Versions: 1.3.0
>Reporter: Andy LoPresto
>Assignee: Pierre Villard
>  Labels: security, tls, tls-toolkit
>
> As of Chrome 58, the browser will only use the *SubjectAlternativeName* 
> entries to determine hostname verification, rather than the *CN*. This is 
> specified in RFC 6215 [1], TLS hostname verification must attempt to use the 
> SAN entries first and may only use the CN entry if no SAN entries are 
> available. 
> Chrome takes this a step further [2]: 
> {quote}
> During Transport Layer Security (TLS) connections, Chrome browser checks to 
> make sure the connection to the site is using a valid, trusted server 
> certificate.
> For Chrome 58 and later, only the subjectAlternativeName extension, not 
> commonName, is used to match the domain name and site certificate. The 
> certificate subject alternative name can be a domain name or IP address. If 
> the certificate doesn’t have the correct subjectAlternativeName extension, 
> users get a NET::ERR_CERT_COMMON_NAME_INVALID error letting them know that 
> the connection isn’t private. If the certificate is missing a 
> subjectAlternativeName extension, users see a warning in the Security panel 
> in Chrome DevTools that lets them know the subject alternative name is 
> missing.
> {quote}
> As this will cause issues for users who do not manually provide a SAN when 
> generating their certificates using the TLS Toolkit, the toolkit should be 
> modified to automatically include the provided CN as a SAN entry, in addition 
> to any manually-provided SAN entries. 
> [1] https://tools.ietf.org/html/rfc6125#section-6.4.4
> [2] https://support.google.com/chrome/a/answer/7391219?hl=en



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi pull request #2042: NIFI-4222 - Adding CN by default in SANs for genera...

[pvillard31]

GitHub user pvillard31 opened a pull request:

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

NIFI-4222 - Adding CN by default in SANs for generated certificates w…

…ith tls-toolkit

Thank you for submitting a contribution to Apache NiFi.

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

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

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

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

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

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

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

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


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

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

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

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


commit fa447d3f641214bbe05e936fd9259640b48af4b9
Author: Pierre Villard 
Date:   2017-07-29T10:38:14Z

NIFI-4222 - Adding CN by default in SANs for generated certificates with 
tls-toolkit




---
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-4222) TLS Toolkit should provide SAN by default

[Pierre Villard (JIRA)]

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

Pierre Villard reassigned NIFI-4222:


Assignee: Pierre Villard

> TLS Toolkit should provide SAN by default
> -
>
> Key: NIFI-4222
> URL: https://issues.apache.org/jira/browse/NIFI-4222
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Tools and Build
>Affects Versions: 1.3.0
>Reporter: Andy LoPresto
>Assignee: Pierre Villard
>  Labels: security, tls, tls-toolkit
>
> As of Chrome 58, the browser will only use the *SubjectAlternativeName* 
> entries to determine hostname verification, rather than the *CN*. This is 
> specified in RFC 6215 [1], TLS hostname verification must attempt to use the 
> SAN entries first and may only use the CN entry if no SAN entries are 
> available. 
> Chrome takes this a step further [2]: 
> {quote}
> During Transport Layer Security (TLS) connections, Chrome browser checks to 
> make sure the connection to the site is using a valid, trusted server 
> certificate.
> For Chrome 58 and later, only the subjectAlternativeName extension, not 
> commonName, is used to match the domain name and site certificate. The 
> certificate subject alternative name can be a domain name or IP address. If 
> the certificate doesn’t have the correct subjectAlternativeName extension, 
> users get a NET::ERR_CERT_COMMON_NAME_INVALID error letting them know that 
> the connection isn’t private. If the certificate is missing a 
> subjectAlternativeName extension, users see a warning in the Security panel 
> in Chrome DevTools that lets them know the subject alternative name is 
> missing.
> {quote}
> As this will cause issues for users who do not manually provide a SAN when 
> generating their certificates using the TLS Toolkit, the toolkit should be 
> modified to automatically include the provided CN as a SAN entry, in addition 
> to any manually-provided SAN entries. 
> [1] https://tools.ietf.org/html/rfc6125#section-6.4.4
> [2] https://support.google.com/chrome/a/answer/7391219?hl=en



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)