[jira] [Commented] (NIFIREG-128) Swagger spec missing body param for create/update bucket
[ https://issues.apache.org/jira/browse/NIFIREG-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16338877#comment-16338877 ] Daniel Chaffelson commented on NIFIREG-128: --- I have tested the proposed changes and it looks good in Python. Client generated from the new spec is available [NiPyAPI on Github|https://github.com/Chaffelson/nipyapi/tree/master/nipyapi/registry] > Swagger spec missing body param for create/update bucket > > > Key: NIFIREG-128 > URL: https://issues.apache.org/jira/browse/NIFIREG-128 > Project: NiFi Registry > Issue Type: Bug >Affects Versions: 0.1.0 >Reporter: Daniel Chaffelson >Assignee: Kevin Doran >Priority: Major > Fix For: 0.2.0 > > > The swagger definition doesn't allow the create_bucket call to specify a > name, which is required to create a bucket > > {code:java} > "/buckets" : { > "post" : { > "tags" : [ "buckets" ], > "summary" : "Creates a bucket", > "description" : "", > "operationId" : "createBucket", > "consumes" : [ "application/json" ], > "produces" : [ "application/json" ], > "responses" : { > "200" : { > "description" : "successful operation", > "schema" : { > "$ref" : "#/definitions/bucket" > } > }, > "400" : { > "description" : "NiFi Registry was unable to complete the request because it > was invalid. The request should not be retried without modification." > }, > "401" : { > "description" : "Client could not be authenticated." > }, > "403" : { > "description" : "Client is not authorized to make this request." > } > } > } > {code} > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFIREG-120) Basic Docker Image
[ https://issues.apache.org/jira/browse/NIFIREG-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16338866#comment-16338866 ] ASF GitHub Bot commented on NIFIREG-120: Github user Chaffelson commented on a diff in the pull request: https://github.com/apache/nifi-registry/pull/89#discussion_r163768777 --- Diff: nifi-registry-docker/dockerhub/Dockerfile --- @@ -0,0 +1,56 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. +# + +FROM openjdk:8-jdk-slim --- End diff -- My first attempt was blindly lifting the Dockerfile from the main NiFi build, but that threw runtime errors so I looked into which Java might be preferable. I picked 8-jdk-slim because it's the smallest that ran with no errors. I have attached the log from the attempt to run with 'openjdk:8-jre' [nifi-registry-JRE_Error.txt](https://github.com/apache/nifi-registry/files/1662938/nifi-registry-JRE_Error.txt) > Basic Docker Image > -- > > Key: NIFIREG-120 > URL: https://issues.apache.org/jira/browse/NIFIREG-120 > Project: NiFi Registry > Issue Type: Improvement >Affects Versions: 0.1.0 >Reporter: Daniel Chaffelson >Priority: Minor > Fix For: 0.2.0 > > > It would be convenient if NiFi Registry had an integrated Docker image ready > for uploading to Dockerhub, similar to the main NiFi Project, for ease of > integration testing. > This could probably be ported, with some changes, from the same approach used > in the main NiFi project for continuity. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi-registry pull request #89: NIFIREG-120 Basic Docker Image Support
Github user Chaffelson commented on a diff in the pull request: https://github.com/apache/nifi-registry/pull/89#discussion_r163768777 --- Diff: nifi-registry-docker/dockerhub/Dockerfile --- @@ -0,0 +1,56 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. +# + +FROM openjdk:8-jdk-slim --- End diff -- My first attempt was blindly lifting the Dockerfile from the main NiFi build, but that threw runtime errors so I looked into which Java might be preferable. I picked 8-jdk-slim because it's the smallest that ran with no errors. I have attached the log from the attempt to run with 'openjdk:8-jre' [nifi-registry-JRE_Error.txt](https://github.com/apache/nifi-registry/files/1662938/nifi-registry-JRE_Error.txt) ---
[jira] [Commented] (NIFI-4395) GenerateTableFetch can't fetch column type by state after instance reboot
[ https://issues.apache.org/jira/browse/NIFI-4395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16338704#comment-16338704 ] Deon Huang commented on NIFI-4395: -- Hi Sanjay and Sarthak, Really appreciate for the elaboration. Indeed, current fix version only handle single table scenario (unit test same only test single state recover). Original condition logic didn't handle well at multi-table state recover after instance reboot problem. Seems it's a single-line fixed bug. I'll consider submit a pull request here to reopen the issue rather than open another issue. > GenerateTableFetch can't fetch column type by state after instance reboot > - > > Key: NIFI-4395 > URL: https://issues.apache.org/jira/browse/NIFI-4395 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.3.0 >Reporter: Deon Huang >Assignee: Deon Huang >Priority: Major > Fix For: 1.4.0 > > Attachments: GenerateTableFetch_Exception.png > > > The problem can easily be reproduce. > Once GenerateTableFetch store state and encounter NiFi instance reboot. > (Dynamic naming table by expression language) > The exception will occur. > The error in source code is list below. > ``` > if (type == null) { > // This shouldn't happen as we are populating columnTypeMap when the > processor is scheduled or when the first maximum is observed > throw new IllegalArgumentException("No column type found for: " + > colName); > } > ``` > When this situation happened. The FlowFile will also be grab and can't > release or observed. > Processor can't grab existing column type from *columnTypeMap* through > instance reboot. > Hence will inevidible get this exception, rollback FlowFile and never success. > QueryDatabaseTable processor will not encounter this exception due to it > setup(context) every time, > While GenerateTableFetch will not pass the condition and thus try to fetch > column type from 0 length columnTypeMap. > --- > if (!isDynamicTableName && !isDynamicMaxValues) { > super.setup(context); > } > --- > I can take the issue if it is recognize as bug. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFIREG-120) Basic Docker Image
[ https://issues.apache.org/jira/browse/NIFIREG-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16338235#comment-16338235 ] ASF GitHub Bot commented on NIFIREG-120: Github user apiri commented on a diff in the pull request: https://github.com/apache/nifi-registry/pull/89#discussion_r163679675 --- Diff: nifi-registry-docker/dockerhub/Dockerfile --- @@ -0,0 +1,56 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. +# + +FROM openjdk:8-jdk-slim --- End diff -- Is there a reason the JDK variant is needed over the JRE? > Basic Docker Image > -- > > Key: NIFIREG-120 > URL: https://issues.apache.org/jira/browse/NIFIREG-120 > Project: NiFi Registry > Issue Type: Improvement >Affects Versions: 0.1.0 >Reporter: Daniel Chaffelson >Priority: Minor > Fix For: 0.2.0 > > > It would be convenient if NiFi Registry had an integrated Docker image ready > for uploading to Dockerhub, similar to the main NiFi Project, for ease of > integration testing. > This could probably be ported, with some changes, from the same approach used > in the main NiFi project for continuity. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi-registry pull request #89: NIFIREG-120 Basic Docker Image Support
Github user apiri commented on a diff in the pull request: https://github.com/apache/nifi-registry/pull/89#discussion_r163679675 --- Diff: nifi-registry-docker/dockerhub/Dockerfile --- @@ -0,0 +1,56 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. +# + +FROM openjdk:8-jdk-slim --- End diff -- Is there a reason the JDK variant is needed over the JRE? ---
[jira] [Resolved] (MINIFICPP-380) Add missing toLower EL function
[ https://issues.apache.org/jira/browse/MINIFICPP-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] marco polo resolved MINIFICPP-380. -- Resolution: Fixed > Add missing toLower EL function > --- > > Key: MINIFICPP-380 > URL: https://issues.apache.org/jira/browse/MINIFICPP-380 > Project: NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Andrew Christianson >Assignee: Andrew Christianson >Priority: Minor > Fix For: 0.4.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MINIFICPP-380) Add missing toLower EL function
[ https://issues.apache.org/jira/browse/MINIFICPP-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] marco polo updated MINIFICPP-380: - Fix Version/s: 0.4.0 > Add missing toLower EL function > --- > > Key: MINIFICPP-380 > URL: https://issues.apache.org/jira/browse/MINIFICPP-380 > Project: NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Andrew Christianson >Assignee: Andrew Christianson >Priority: Minor > Fix For: 0.4.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFIREG-128) Swagger spec missing body param for create/update bucket
[ https://issues.apache.org/jira/browse/NIFIREG-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Doran updated NIFIREG-128: Affects Version/s: (was: 0.2.0) > Swagger spec missing body param for create/update bucket > > > Key: NIFIREG-128 > URL: https://issues.apache.org/jira/browse/NIFIREG-128 > Project: NiFi Registry > Issue Type: Bug >Affects Versions: 0.1.0 >Reporter: Daniel Chaffelson >Assignee: Kevin Doran >Priority: Major > Fix For: 0.2.0 > > > The swagger definition doesn't allow the create_bucket call to specify a > name, which is required to create a bucket > > {code:java} > "/buckets" : { > "post" : { > "tags" : [ "buckets" ], > "summary" : "Creates a bucket", > "description" : "", > "operationId" : "createBucket", > "consumes" : [ "application/json" ], > "produces" : [ "application/json" ], > "responses" : { > "200" : { > "description" : "successful operation", > "schema" : { > "$ref" : "#/definitions/bucket" > } > }, > "400" : { > "description" : "NiFi Registry was unable to complete the request because it > was invalid. The request should not be retried without modification." > }, > "401" : { > "description" : "Client could not be authenticated." > }, > "403" : { > "description" : "Client is not authorized to make this request." > } > } > } > {code} > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFIREG-128) Swagger spec missing body param for create/update bucket
[ https://issues.apache.org/jira/browse/NIFIREG-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16338054#comment-16338054 ] ASF GitHub Bot commented on NIFIREG-128: GitHub user kevdoran opened a pull request: https://github.com/apache/nifi-registry/pull/95 NIFIREG-128 Fixes Swagger spec build output Adds missing body parameter annotations for createBucket, updateBucket You can merge this pull request into a Git repository by running: $ git pull https://github.com/kevdoran/nifi-registry NIFIREG-128 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi-registry/pull/95.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 #95 commit 0e62f008df68dbfc9c4c4af218533f35305e84c8 Author: Kevin DoranDate: 2018-01-24T18:41:19Z NIFIREG-128 Fixes Swagger spec build output Adds missing body parameter annotations for createBucket, updateBucket > Swagger spec missing body param for create/update bucket > > > Key: NIFIREG-128 > URL: https://issues.apache.org/jira/browse/NIFIREG-128 > Project: NiFi Registry > Issue Type: Bug >Affects Versions: 0.1.0 >Reporter: Daniel Chaffelson >Assignee: Kevin Doran >Priority: Major > Fix For: 0.2.0 > > > The swagger definition doesn't allow the create_bucket call to specify a > name, which is required to create a bucket > > {code:java} > "/buckets" : { > "post" : { > "tags" : [ "buckets" ], > "summary" : "Creates a bucket", > "description" : "", > "operationId" : "createBucket", > "consumes" : [ "application/json" ], > "produces" : [ "application/json" ], > "responses" : { > "200" : { > "description" : "successful operation", > "schema" : { > "$ref" : "#/definitions/bucket" > } > }, > "400" : { > "description" : "NiFi Registry was unable to complete the request because it > was invalid. The request should not be retried without modification." > }, > "401" : { > "description" : "Client could not be authenticated." > }, > "403" : { > "description" : "Client is not authorized to make this request." > } > } > } > {code} > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFIREG-128) Swagger spec missing body param for create/update bucket
[ https://issues.apache.org/jira/browse/NIFIREG-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Doran updated NIFIREG-128: Fix Version/s: 0.2.0 > Swagger spec missing body param for create/update bucket > > > Key: NIFIREG-128 > URL: https://issues.apache.org/jira/browse/NIFIREG-128 > Project: NiFi Registry > Issue Type: Bug >Affects Versions: 0.1.0 >Reporter: Daniel Chaffelson >Assignee: Kevin Doran >Priority: Major > Fix For: 0.2.0 > > > The swagger definition doesn't allow the create_bucket call to specify a > name, which is required to create a bucket > > {code:java} > "/buckets" : { > "post" : { > "tags" : [ "buckets" ], > "summary" : "Creates a bucket", > "description" : "", > "operationId" : "createBucket", > "consumes" : [ "application/json" ], > "produces" : [ "application/json" ], > "responses" : { > "200" : { > "description" : "successful operation", > "schema" : { > "$ref" : "#/definitions/bucket" > } > }, > "400" : { > "description" : "NiFi Registry was unable to complete the request because it > was invalid. The request should not be retried without modification." > }, > "401" : { > "description" : "Client could not be authenticated." > }, > "403" : { > "description" : "Client is not authorized to make this request." > } > } > } > {code} > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi-registry pull request #95: NIFIREG-128 Fixes Swagger spec build output
GitHub user kevdoran opened a pull request: https://github.com/apache/nifi-registry/pull/95 NIFIREG-128 Fixes Swagger spec build output Adds missing body parameter annotations for createBucket, updateBucket You can merge this pull request into a Git repository by running: $ git pull https://github.com/kevdoran/nifi-registry NIFIREG-128 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi-registry/pull/95.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 #95 commit 0e62f008df68dbfc9c4c4af218533f35305e84c8 Author: Kevin DoranDate: 2018-01-24T18:41:19Z NIFIREG-128 Fixes Swagger spec build output Adds missing body parameter annotations for createBucket, updateBucket ---
[jira] [Updated] (NIFIREG-128) Swagger spec missing body param for create/update bucket
[ https://issues.apache.org/jira/browse/NIFIREG-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Doran updated NIFIREG-128: Summary: Swagger spec missing body param for create/update bucket (was: swagger_client generated create_bucket requires but does not accept a 'name' parameter) > Swagger spec missing body param for create/update bucket > > > Key: NIFIREG-128 > URL: https://issues.apache.org/jira/browse/NIFIREG-128 > Project: NiFi Registry > Issue Type: Bug >Affects Versions: 0.1.0, 0.2.0 >Reporter: Daniel Chaffelson >Assignee: Kevin Doran >Priority: Major > > The swagger definition doesn't allow the create_bucket call to specify a > name, which is required to create a bucket > > {code:java} > "/buckets" : { > "post" : { > "tags" : [ "buckets" ], > "summary" : "Creates a bucket", > "description" : "", > "operationId" : "createBucket", > "consumes" : [ "application/json" ], > "produces" : [ "application/json" ], > "responses" : { > "200" : { > "description" : "successful operation", > "schema" : { > "$ref" : "#/definitions/bucket" > } > }, > "400" : { > "description" : "NiFi Registry was unable to complete the request because it > was invalid. The request should not be retried without modification." > }, > "401" : { > "description" : "Client could not be authenticated." > }, > "403" : { > "description" : "Client is not authorized to make this request." > } > } > } > {code} > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (NIFIREG-128) swagger_client generated create_bucket requires but does not accept a 'name' parameter
[ https://issues.apache.org/jira/browse/NIFIREG-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Doran reassigned NIFIREG-128: --- Assignee: Kevin Doran > swagger_client generated create_bucket requires but does not accept a 'name' > parameter > -- > > Key: NIFIREG-128 > URL: https://issues.apache.org/jira/browse/NIFIREG-128 > Project: NiFi Registry > Issue Type: Bug >Affects Versions: 0.1.0, 0.2.0 >Reporter: Daniel Chaffelson >Assignee: Kevin Doran >Priority: Major > > The swagger definition doesn't allow the create_bucket call to specify a > name, which is required to create a bucket > > {code:java} > "/buckets" : { > "post" : { > "tags" : [ "buckets" ], > "summary" : "Creates a bucket", > "description" : "", > "operationId" : "createBucket", > "consumes" : [ "application/json" ], > "produces" : [ "application/json" ], > "responses" : { > "200" : { > "description" : "successful operation", > "schema" : { > "$ref" : "#/definitions/bucket" > } > }, > "400" : { > "description" : "NiFi Registry was unable to complete the request because it > was invalid. The request should not be retried without modification." > }, > "401" : { > "description" : "Client could not be authenticated." > }, > "403" : { > "description" : "Client is not authorized to make this request." > } > } > } > {code} > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (NIFIREG-128) swagger_client generated create_bucket requires but does not accept a 'name' parameter
Daniel Chaffelson created NIFIREG-128: - Summary: swagger_client generated create_bucket requires but does not accept a 'name' parameter Key: NIFIREG-128 URL: https://issues.apache.org/jira/browse/NIFIREG-128 Project: NiFi Registry Issue Type: Bug Affects Versions: 0.1.0, 0.2.0 Reporter: Daniel Chaffelson The swagger definition doesn't allow the create_bucket call to specify a name, which is required to create a bucket {code:java} "/buckets" : { "post" : { "tags" : [ "buckets" ], "summary" : "Creates a bucket", "description" : "", "operationId" : "createBucket", "consumes" : [ "application/json" ], "produces" : [ "application/json" ], "responses" : { "200" : { "description" : "successful operation", "schema" : { "$ref" : "#/definitions/bucket" } }, "400" : { "description" : "NiFi Registry was unable to complete the request because it was invalid. The request should not be retried without modification." }, "401" : { "description" : "Client could not be authenticated." }, "403" : { "description" : "Client is not authorized to make this request." } } } {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (NIFI-4790) Support HTTPS proxy in InvokeHTTP
[ https://issues.apache.org/jira/browse/NIFI-4790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard resolved NIFI-4790. -- Resolution: Fixed Fix Version/s: 1.6.0 > Support HTTPS proxy in InvokeHTTP > - > > Key: NIFI-4790 > URL: https://issues.apache.org/jira/browse/NIFI-4790 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Marco Gaido >Assignee: Marco Gaido >Priority: Major > Fix For: 1.6.0 > > > InvokeHTTP currently assumes that the proxy (if set) uses HTTP. We should > introduce a new property to indicate the protocol used by the proxy (either > http or https) in order to support also HTTPS proxies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-4790) Support HTTPS proxy in InvokeHTTP
[ https://issues.apache.org/jira/browse/NIFI-4790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-4790: - Component/s: Extensions > Support HTTPS proxy in InvokeHTTP > - > > Key: NIFI-4790 > URL: https://issues.apache.org/jira/browse/NIFI-4790 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Marco Gaido >Assignee: Marco Gaido >Priority: Major > Fix For: 1.6.0 > > > InvokeHTTP currently assumes that the proxy (if set) uses HTTP. We should > introduce a new property to indicate the protocol used by the proxy (either > http or https) in order to support also HTTPS proxies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi pull request #2426: NIFI-4790: support HTTPS Proxy in InvokeHTTP
Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/2426 ---
[jira] [Commented] (NIFI-4790) Support HTTPS proxy in InvokeHTTP
[ https://issues.apache.org/jira/browse/NIFI-4790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337883#comment-16337883 ] ASF GitHub Bot commented on NIFI-4790: -- Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/2426 > Support HTTPS proxy in InvokeHTTP > - > > Key: NIFI-4790 > URL: https://issues.apache.org/jira/browse/NIFI-4790 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Marco Gaido >Assignee: Marco Gaido >Priority: Major > > InvokeHTTP currently assumes that the proxy (if set) uses HTTP. We should > introduce a new property to indicate the protocol used by the proxy (either > http or https) in order to support also HTTPS proxies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-4790) Support HTTPS proxy in InvokeHTTP
[ https://issues.apache.org/jira/browse/NIFI-4790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337882#comment-16337882 ] ASF subversion and git services commented on NIFI-4790: --- Commit 37271e82414b9386bb735b61ef54e891300117bf in nifi's branch refs/heads/master from [~mgaido] [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=37271e8 ] NIFI-4790 - support HTTPS Proxy in InvokeHTTP Signed-off-by: Pierre VillardThis closes #2426. > Support HTTPS proxy in InvokeHTTP > - > > Key: NIFI-4790 > URL: https://issues.apache.org/jira/browse/NIFI-4790 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Marco Gaido >Assignee: Marco Gaido >Priority: Major > > InvokeHTTP currently assumes that the proxy (if set) uses HTTP. We should > introduce a new property to indicate the protocol used by the proxy (either > http or https) in order to support also HTTPS proxies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi issue #2426: NIFI-4790: support HTTPS Proxy in InvokeHTTP
Github user pvillard31 commented on the issue: https://github.com/apache/nifi/pull/2426 +1, merging to master, thanks @mgaido91 @ijokarumawak ---
[jira] [Commented] (NIFI-4790) Support HTTPS proxy in InvokeHTTP
[ https://issues.apache.org/jira/browse/NIFI-4790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337881#comment-16337881 ] ASF GitHub Bot commented on NIFI-4790: -- Github user pvillard31 commented on the issue: https://github.com/apache/nifi/pull/2426 +1, merging to master, thanks @mgaido91 @ijokarumawak > Support HTTPS proxy in InvokeHTTP > - > > Key: NIFI-4790 > URL: https://issues.apache.org/jira/browse/NIFI-4790 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Marco Gaido >Assignee: Marco Gaido >Priority: Major > > InvokeHTTP currently assumes that the proxy (if set) uses HTTP. We should > introduce a new property to indicate the protocol used by the proxy (either > http or https) in order to support also HTTPS proxies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-4367) InvokedScriptedProcessor does not support scripted processor that extends AbstractProcessor
[ https://issues.apache.org/jira/browse/NIFI-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Burgess updated NIFI-4367: --- Component/s: (was: Core Framework) Extensions > InvokedScriptedProcessor does not support scripted processor that extends > AbstractProcessor > --- > > Key: NIFI-4367 > URL: https://issues.apache.org/jira/browse/NIFI-4367 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions > Environment: Linux / Windows >Reporter: Patrice Freydiere >Priority: Major > Labels: InvokeScriptedProcessor, validation > > InvokeScriptedProcessor pass his ValidationContext to the inner script, > validate call > InvokeScriptedProcessor Line 465 :final > Collection instanceResults = instance.validate(context); > > The problem is that the invokedscript pass the ScriptFile PropertyDescriptor > that is validated, if the script derived from the > AbstractConfigurableComponent, (because the AbstractConfigurableComponent > validate all the context properties). > The context should be refined to remove the InvokeScriptedProcessor > Properties. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-4367) InvokedScriptedProcessor does not support scripted processor that extends AbstractProcessor
[ https://issues.apache.org/jira/browse/NIFI-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Burgess updated NIFI-4367: --- Affects Version/s: (was: 1.5.0) (was: 1.4.0) (was: 1.3.0) > InvokedScriptedProcessor does not support scripted processor that extends > AbstractProcessor > --- > > Key: NIFI-4367 > URL: https://issues.apache.org/jira/browse/NIFI-4367 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions > Environment: Linux / Windows >Reporter: Patrice Freydiere >Priority: Major > Labels: InvokeScriptedProcessor, validation > > InvokeScriptedProcessor pass his ValidationContext to the inner script, > validate call > InvokeScriptedProcessor Line 465 :final > Collection instanceResults = instance.validate(context); > > The problem is that the invokedscript pass the ScriptFile PropertyDescriptor > that is validated, if the script derived from the > AbstractConfigurableComponent, (because the AbstractConfigurableComponent > validate all the context properties). > The context should be refined to remove the InvokeScriptedProcessor > Properties. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-4367) InvokedScriptedProcessor does not support scripted processor that extends AbstractProcessor
[ https://issues.apache.org/jira/browse/NIFI-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Burgess updated NIFI-4367: --- Environment: (was: Linux / Windows) > InvokedScriptedProcessor does not support scripted processor that extends > AbstractProcessor > --- > > Key: NIFI-4367 > URL: https://issues.apache.org/jira/browse/NIFI-4367 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Patrice Freydiere >Priority: Major > Labels: InvokeScriptedProcessor, validation > > InvokeScriptedProcessor pass his ValidationContext to the inner script, > validate call > InvokeScriptedProcessor Line 465 :final > Collection instanceResults = instance.validate(context); > > The problem is that the invokedscript pass the ScriptFile PropertyDescriptor > that is validated, if the script derived from the > AbstractConfigurableComponent, (because the AbstractConfigurableComponent > validate all the context properties). > The context should be refined to remove the InvokeScriptedProcessor > Properties. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-4367) InvokedScriptedProcessor does not support scripted processor that extends AbstractProcessor
[ https://issues.apache.org/jira/browse/NIFI-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337873#comment-16337873 ] Matt Burgess commented on NIFI-4367: Changing the type from Bug to Improvement, as this works as originally designed. It is unlikely that a scripted processor will be able to function like a full-fledged native processor, due to differences in the lifecycles, when methods are called, and which methods can be called externally (such as getSupportedDynamicProperty()), not to mention annotations (which are not supported in all programming languages, but see NIFI-2215 which is also an Improvement). This is why the original design is meant to support scripted processors that implement Processor and do not extend other base/abstract classes. > InvokedScriptedProcessor does not support scripted processor that extends > AbstractProcessor > --- > > Key: NIFI-4367 > URL: https://issues.apache.org/jira/browse/NIFI-4367 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Affects Versions: 1.3.0, 1.4.0, 1.5.0 > Environment: Linux / Windows >Reporter: Patrice Freydiere >Priority: Major > Labels: InvokeScriptedProcessor, validation > > InvokeScriptedProcessor pass his ValidationContext to the inner script, > validate call > InvokeScriptedProcessor Line 465 :final > Collection instanceResults = instance.validate(context); > > The problem is that the invokedscript pass the ScriptFile PropertyDescriptor > that is validated, if the script derived from the > AbstractConfigurableComponent, (because the AbstractConfigurableComponent > validate all the context properties). > The context should be refined to remove the InvokeScriptedProcessor > Properties. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-4367) InvokedScriptedProcessor does not support scripted processor that extends AbstractProcessor
[ https://issues.apache.org/jira/browse/NIFI-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Burgess updated NIFI-4367: --- Summary: InvokedScriptedProcessor does not support scripted processor that extends AbstractProcessor (was: InvokedScriptedProcessor) > InvokedScriptedProcessor does not support scripted processor that extends > AbstractProcessor > --- > > Key: NIFI-4367 > URL: https://issues.apache.org/jira/browse/NIFI-4367 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.3.0, 1.4.0, 1.5.0 > Environment: Linux / Windows >Reporter: Patrice Freydiere >Priority: Major > Labels: InvokeScriptedProcessor, validation > > InvokeScriptedProcessor pass his ValidationContext to the inner script, > validate call > InvokeScriptedProcessor Line 465 :final > Collection instanceResults = instance.validate(context); > > The problem is that the invokedscript pass the ScriptFile PropertyDescriptor > that is validated, if the script derived from the > AbstractConfigurableComponent, (because the AbstractConfigurableComponent > validate all the context properties). > The context should be refined to remove the InvokeScriptedProcessor > Properties. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-4367) InvokedScriptedProcessor does not support scripted processor that extends AbstractProcessor
[ https://issues.apache.org/jira/browse/NIFI-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Burgess updated NIFI-4367: --- Issue Type: Improvement (was: Bug) > InvokedScriptedProcessor does not support scripted processor that extends > AbstractProcessor > --- > > Key: NIFI-4367 > URL: https://issues.apache.org/jira/browse/NIFI-4367 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Affects Versions: 1.3.0, 1.4.0, 1.5.0 > Environment: Linux / Windows >Reporter: Patrice Freydiere >Priority: Major > Labels: InvokeScriptedProcessor, validation > > InvokeScriptedProcessor pass his ValidationContext to the inner script, > validate call > InvokeScriptedProcessor Line 465 :final > Collection instanceResults = instance.validate(context); > > The problem is that the invokedscript pass the ScriptFile PropertyDescriptor > that is validated, if the script derived from the > AbstractConfigurableComponent, (because the AbstractConfigurableComponent > validate all the context properties). > The context should be refined to remove the InvokeScriptedProcessor > Properties. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-4367) InvokedScriptedProcessor
[ https://issues.apache.org/jira/browse/NIFI-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337863#comment-16337863 ] ASF GitHub Bot commented on NIFI-4367: -- Github user mattyb149 commented on a diff in the pull request: https://github.com/apache/nifi/pull/2201#discussion_r163573373 --- Diff: nifi-nar-bundles/nifi-scripting-bundle/nifi-scripting-processors/src/test/resources/groovy/test_implementingabstractProcessor.groovy --- @@ -0,0 +1,40 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +import org.apache.nifi.components.PropertyDescriptor +import org.apache.nifi.components.ValidationContext +import org.apache.nifi.components.ValidationResult +import org.apache.nifi.logging.ComponentLog +import org.apache.nifi.processor.AbstractProcessor +import org.apache.nifi.processor.ProcessContext +import org.apache.nifi.processor.ProcessSession +import org.apache.nifi.processor.ProcessSessionFactory +import org.apache.nifi.processor.ProcessorInitializationContext +import org.apache.nifi.processor.Relationship +import org.apache.nifi.processor.exception.ProcessException + +class testImplementingAbstractProcessor extends AbstractProcessor { --- End diff -- This should probably exercise more of the updated logic, such as having its own properties with validators, etc. > InvokedScriptedProcessor > > > Key: NIFI-4367 > URL: https://issues.apache.org/jira/browse/NIFI-4367 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.3.0, 1.4.0, 1.5.0 > Environment: Linux / Windows >Reporter: Patrice Freydiere >Priority: Major > Labels: InvokeScriptedProcessor, validation > > InvokeScriptedProcessor pass his ValidationContext to the inner script, > validate call > InvokeScriptedProcessor Line 465 :final > Collection instanceResults = instance.validate(context); > > The problem is that the invokedscript pass the ScriptFile PropertyDescriptor > that is validated, if the script derived from the > AbstractConfigurableComponent, (because the AbstractConfigurableComponent > validate all the context properties). > The context should be refined to remove the InvokeScriptedProcessor > Properties. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-4367) InvokedScriptedProcessor
[ https://issues.apache.org/jira/browse/NIFI-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337864#comment-16337864 ] ASF GitHub Bot commented on NIFI-4367: -- Github user mattyb149 commented on a diff in the pull request: https://github.com/apache/nifi/pull/2201#discussion_r163567699 --- Diff: nifi-nar-bundles/nifi-scripting-bundle/nifi-scripting-processors/src/main/java/org/apache/nifi/script/impl/ValidationContextAdapter.java --- @@ -0,0 +1,97 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.nifi.script.impl; + +import java.util.Map; + +import org.apache.nifi.components.PropertyDescriptor; +import org.apache.nifi.components.PropertyValue; +import org.apache.nifi.components.ValidationContext; +import org.apache.nifi.controller.ControllerService; +import org.apache.nifi.controller.ControllerServiceLookup; +import org.apache.nifi.expression.ExpressionLanguageCompiler; + +public abstract class ValidationContextAdapter implements ValidationContext { --- End diff -- I wonder if we should add a method here to retrieve the innerValidationContext. It's not part of the ValidationContext interface of course, but currently scripts that are expecting a StandardValidationContext (and use methods on that class that are not on the interface) would break. If we expose the underlying context, then the scripts could be updated by checking to see if the context is a ValidationContextAdapter, then getting the underlying context adapter if they want it. Thoughts? > InvokedScriptedProcessor > > > Key: NIFI-4367 > URL: https://issues.apache.org/jira/browse/NIFI-4367 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.3.0, 1.4.0, 1.5.0 > Environment: Linux / Windows >Reporter: Patrice Freydiere >Priority: Major > Labels: InvokeScriptedProcessor, validation > > InvokeScriptedProcessor pass his ValidationContext to the inner script, > validate call > InvokeScriptedProcessor Line 465 :final > Collection instanceResults = instance.validate(context); > > The problem is that the invokedscript pass the ScriptFile PropertyDescriptor > that is validated, if the script derived from the > AbstractConfigurableComponent, (because the AbstractConfigurableComponent > validate all the context properties). > The context should be refined to remove the InvokeScriptedProcessor > Properties. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi pull request #2201: NIFI-4367 Fix on processor for permit deriving scri...
Github user mattyb149 commented on a diff in the pull request: https://github.com/apache/nifi/pull/2201#discussion_r163573373 --- Diff: nifi-nar-bundles/nifi-scripting-bundle/nifi-scripting-processors/src/test/resources/groovy/test_implementingabstractProcessor.groovy --- @@ -0,0 +1,40 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +import org.apache.nifi.components.PropertyDescriptor +import org.apache.nifi.components.ValidationContext +import org.apache.nifi.components.ValidationResult +import org.apache.nifi.logging.ComponentLog +import org.apache.nifi.processor.AbstractProcessor +import org.apache.nifi.processor.ProcessContext +import org.apache.nifi.processor.ProcessSession +import org.apache.nifi.processor.ProcessSessionFactory +import org.apache.nifi.processor.ProcessorInitializationContext +import org.apache.nifi.processor.Relationship +import org.apache.nifi.processor.exception.ProcessException + +class testImplementingAbstractProcessor extends AbstractProcessor { --- End diff -- This should probably exercise more of the updated logic, such as having its own properties with validators, etc. ---
[GitHub] nifi pull request #2201: NIFI-4367 Fix on processor for permit deriving scri...
Github user mattyb149 commented on a diff in the pull request: https://github.com/apache/nifi/pull/2201#discussion_r163567699 --- Diff: nifi-nar-bundles/nifi-scripting-bundle/nifi-scripting-processors/src/main/java/org/apache/nifi/script/impl/ValidationContextAdapter.java --- @@ -0,0 +1,97 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.nifi.script.impl; + +import java.util.Map; + +import org.apache.nifi.components.PropertyDescriptor; +import org.apache.nifi.components.PropertyValue; +import org.apache.nifi.components.ValidationContext; +import org.apache.nifi.controller.ControllerService; +import org.apache.nifi.controller.ControllerServiceLookup; +import org.apache.nifi.expression.ExpressionLanguageCompiler; + +public abstract class ValidationContextAdapter implements ValidationContext { --- End diff -- I wonder if we should add a method here to retrieve the innerValidationContext. It's not part of the ValidationContext interface of course, but currently scripts that are expecting a StandardValidationContext (and use methods on that class that are not on the interface) would break. If we expose the underlying context, then the scripts could be updated by checking to see if the context is a ValidationContextAdapter, then getting the underlying context adapter if they want it. Thoughts? ---
[jira] [Commented] (NIFI-4814) Add distinctive attribute to S2S reporting tasks
[ https://issues.apache.org/jira/browse/NIFI-4814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337750#comment-16337750 ] ASF GitHub Bot commented on NIFI-4814: -- Github user pvillard31 commented on the issue: https://github.com/apache/nifi/pull/2431 I'll need to update this PR if #2430 is merged first. > Add distinctive attribute to S2S reporting tasks > > > Key: NIFI-4814 > URL: https://issues.apache.org/jira/browse/NIFI-4814 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > > I'm currently using multiple S2S reporting tasks to send various monitoring > data about my workflows. However this forces me to use multiple input ports > (one per type of reporting task) as I'm not able to easily distinct what data > comes from what reporting task. > I'd like to add an attribute "reporting.task.name" set to the name of the > reporting task when sending flow files via S2S. This way I can use a single > input port and then use a RouteOnAttribute processor to split my data based > on the reporting task source. The objective to use a single input port is to > reduce the number of threads used for S2S operations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-4809) Implement a SiteToSiteMetricsReportingTask
[ https://issues.apache.org/jira/browse/NIFI-4809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337751#comment-16337751 ] ASF GitHub Bot commented on NIFI-4809: -- Github user pvillard31 commented on the issue: https://github.com/apache/nifi/pull/2430 I'll need to update this PR if #2431 is merged first. > Implement a SiteToSiteMetricsReportingTask > -- > > Key: NIFI-4809 > URL: https://issues.apache.org/jira/browse/NIFI-4809 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > > At the moment there is an AmbariReportingTask to send the NiFi-related > metrics of the host to the Ambari Metrics Service. In a multi-cluster > configuration, or when working with MiNiFi (Java) agents, it might not be > possible for all the NiFi instances (NiFi and/or MiNiFi) to access the AMS > REST API. > To solve this problem, a solution would be to implement a > SiteToSiteMetricsReportingTask to send the data via S2S to the "main" NiFi > instance/cluster that will be able to publish the metrics into AMS (using > InvokeHTTP). This way, it is possible to have the metrics of all the > instances exposed in one AMS instance. > I propose to send the data formatted as we are doing right now in the Ambari > reporting task. If needed, it can be easily converted into another schema > using the record processors once received via S2S. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi issue #2430: NIFI-4809 - Implement a SiteToSiteMetricsReportingTask
Github user pvillard31 commented on the issue: https://github.com/apache/nifi/pull/2430 I'll need to update this PR if #2431 is merged first. ---
[jira] [Updated] (NIFI-4814) Add distinctive attribute to S2S reporting tasks
[ https://issues.apache.org/jira/browse/NIFI-4814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-4814: - Status: Patch Available (was: Open) > Add distinctive attribute to S2S reporting tasks > > > Key: NIFI-4814 > URL: https://issues.apache.org/jira/browse/NIFI-4814 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > > I'm currently using multiple S2S reporting tasks to send various monitoring > data about my workflows. However this forces me to use multiple input ports > (one per type of reporting task) as I'm not able to easily distinct what data > comes from what reporting task. > I'd like to add an attribute "reporting.task.name" set to the name of the > reporting task when sending flow files via S2S. This way I can use a single > input port and then use a RouteOnAttribute processor to split my data based > on the reporting task source. The objective to use a single input port is to > reduce the number of threads used for S2S operations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi issue #2431: NIFI-4814 - Add distinctive attribute to S2S reporting tas...
Github user pvillard31 commented on the issue: https://github.com/apache/nifi/pull/2431 I'll need to update this PR if #2430 is merged first. ---
[jira] [Commented] (NIFI-4814) Add distinctive attribute to S2S reporting tasks
[ https://issues.apache.org/jira/browse/NIFI-4814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337748#comment-16337748 ] ASF GitHub Bot commented on NIFI-4814: -- GitHub user pvillard31 opened a pull request: https://github.com/apache/nifi/pull/2431 NIFI-4814 - Add distinctive attribute to S2S reporting tasks 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-4814 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/2431.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 #2431 commit 00d52220f34213a2b127a48a6a57cb4db5895959 Author: Pierre VillardDate: 2018-01-24T15:15:22Z NIFI-4814 - Add distinctive attribute to S2S reporting tasks > Add distinctive attribute to S2S reporting tasks > > > Key: NIFI-4814 > URL: https://issues.apache.org/jira/browse/NIFI-4814 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > > I'm currently using multiple S2S reporting tasks to send various monitoring > data about my workflows. However this forces me to use multiple input ports > (one per type of reporting task) as I'm not able to easily distinct what data > comes from what reporting task. > I'd like to add an attribute "reporting.task.name" set to the name of the > reporting task when sending flow files via S2S. This way I can use a single > input port and then use a RouteOnAttribute processor to split my data based > on the reporting task source. The objective to use a single input port is to > reduce the number of threads used for S2S operations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi pull request #2431: NIFI-4814 - Add distinctive attribute to S2S report...
GitHub user pvillard31 opened a pull request: https://github.com/apache/nifi/pull/2431 NIFI-4814 - Add distinctive attribute to S2S reporting tasks 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-4814 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/2431.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 #2431 commit 00d52220f34213a2b127a48a6a57cb4db5895959 Author: Pierre VillardDate: 2018-01-24T15:15:22Z NIFI-4814 - Add distinctive attribute to S2S reporting tasks ---
[jira] [Created] (NIFI-4814) Add distinctive attribute to S2S reporting tasks
Pierre Villard created NIFI-4814: Summary: Add distinctive attribute to S2S reporting tasks Key: NIFI-4814 URL: https://issues.apache.org/jira/browse/NIFI-4814 Project: Apache NiFi Issue Type: Improvement Components: Extensions Reporter: Pierre Villard Assignee: Pierre Villard I'm currently using multiple S2S reporting tasks to send various monitoring data about my workflows. However this forces me to use multiple input ports (one per type of reporting task) as I'm not able to easily distinct what data comes from what reporting task. I'd like to add an attribute "reporting.task.name" set to the name of the reporting task when sending flow files via S2S. This way I can use a single input port and then use a RouteOnAttribute processor to split my data based on the reporting task source. The objective to use a single input port is to reduce the number of threads used for S2S operations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-4790) Support HTTPS proxy in InvokeHTTP
[ https://issues.apache.org/jira/browse/NIFI-4790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337717#comment-16337717 ] ASF GitHub Bot commented on NIFI-4790: -- Github user pvillard31 commented on a diff in the pull request: https://github.com/apache/nifi/pull/2426#discussion_r163572837 --- Diff: nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/InvokeHTTP.java --- @@ -213,11 +216,21 @@ public static final PropertyDescriptor PROP_SSL_CONTEXT_SERVICE = new PropertyDescriptor.Builder() .name("SSL Context Service") -.description("The SSL Context Service used to provide client certificate information for TLS/SSL (https) connections.") +.description("The SSL Context Service used to provide client certificate information for TLS/SSL (https) connections." ++ " It is also used to connect to HTTPS Proxy.") .required(false) .identifiesControllerService(SSLContextService.class) .build(); +public static final PropertyDescriptor PROP_PROXY_TYPE = new PropertyDescriptor.Builder() +.name("Proxy Type") +.displayName("Proxy Type") +.description("The type of the proxy we are connecting to.") --- End diff -- Probably good to add in the description: ``Must be either " + HTTP + " or " + HTTPS`` > Support HTTPS proxy in InvokeHTTP > - > > Key: NIFI-4790 > URL: https://issues.apache.org/jira/browse/NIFI-4790 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Marco Gaido >Assignee: Marco Gaido >Priority: Major > > InvokeHTTP currently assumes that the proxy (if set) uses HTTP. We should > introduce a new property to indicate the protocol used by the proxy (either > http or https) in order to support also HTTPS proxies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi pull request #2426: NIFI-4790: support HTTPS Proxy in InvokeHTTP
Github user pvillard31 commented on a diff in the pull request: https://github.com/apache/nifi/pull/2426#discussion_r163572837 --- Diff: nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/InvokeHTTP.java --- @@ -213,11 +216,21 @@ public static final PropertyDescriptor PROP_SSL_CONTEXT_SERVICE = new PropertyDescriptor.Builder() .name("SSL Context Service") -.description("The SSL Context Service used to provide client certificate information for TLS/SSL (https) connections.") +.description("The SSL Context Service used to provide client certificate information for TLS/SSL (https) connections." ++ " It is also used to connect to HTTPS Proxy.") .required(false) .identifiesControllerService(SSLContextService.class) .build(); +public static final PropertyDescriptor PROP_PROXY_TYPE = new PropertyDescriptor.Builder() +.name("Proxy Type") +.displayName("Proxy Type") +.description("The type of the proxy we are connecting to.") --- End diff -- Probably good to add in the description: ``Must be either " + HTTP + " or " + HTTPS`` ---
[jira] [Commented] (NIFI-4367) InvokedScriptedProcessor
[ https://issues.apache.org/jira/browse/NIFI-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337709#comment-16337709 ] ASF GitHub Bot commented on NIFI-4367: -- Github user mgaido91 commented on a diff in the pull request: https://github.com/apache/nifi/pull/2201#discussion_r163571877 --- Diff: nifi-nar-bundles/nifi-scripting-bundle/nifi-scripting-processors/src/test/resources/groovy/test_implementingabstractProcessor.groovy --- @@ -0,0 +1,40 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +import org.apache.nifi.components.PropertyDescriptor +import org.apache.nifi.components.ValidationContext +import org.apache.nifi.components.ValidationResult +import org.apache.nifi.logging.ComponentLog +import org.apache.nifi.processor.AbstractProcessor +import org.apache.nifi.processor.ProcessContext +import org.apache.nifi.processor.ProcessSession +import org.apache.nifi.processor.ProcessSessionFactory +import org.apache.nifi.processor.ProcessorInitializationContext +import org.apache.nifi.processor.Relationship +import org.apache.nifi.processor.exception.ProcessException + +class testImplementingAbstractProcessor extends AbstractProcessor { + + def ComponentLog log --- End diff -- I think indentation is a bit strange in this file... > InvokedScriptedProcessor > > > Key: NIFI-4367 > URL: https://issues.apache.org/jira/browse/NIFI-4367 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.3.0, 1.4.0, 1.5.0 > Environment: Linux / Windows >Reporter: Patrice Freydiere >Priority: Major > Labels: InvokeScriptedProcessor, validation > > InvokeScriptedProcessor pass his ValidationContext to the inner script, > validate call > InvokeScriptedProcessor Line 465 :final > Collection instanceResults = instance.validate(context); > > The problem is that the invokedscript pass the ScriptFile PropertyDescriptor > that is validated, if the script derived from the > AbstractConfigurableComponent, (because the AbstractConfigurableComponent > validate all the context properties). > The context should be refined to remove the InvokeScriptedProcessor > Properties. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi pull request #2201: NIFI-4367 Fix on processor for permit deriving scri...
Github user mgaido91 commented on a diff in the pull request: https://github.com/apache/nifi/pull/2201#discussion_r163571877 --- Diff: nifi-nar-bundles/nifi-scripting-bundle/nifi-scripting-processors/src/test/resources/groovy/test_implementingabstractProcessor.groovy --- @@ -0,0 +1,40 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +import org.apache.nifi.components.PropertyDescriptor +import org.apache.nifi.components.ValidationContext +import org.apache.nifi.components.ValidationResult +import org.apache.nifi.logging.ComponentLog +import org.apache.nifi.processor.AbstractProcessor +import org.apache.nifi.processor.ProcessContext +import org.apache.nifi.processor.ProcessSession +import org.apache.nifi.processor.ProcessSessionFactory +import org.apache.nifi.processor.ProcessorInitializationContext +import org.apache.nifi.processor.Relationship +import org.apache.nifi.processor.exception.ProcessException + +class testImplementingAbstractProcessor extends AbstractProcessor { + + def ComponentLog log --- End diff -- I think indentation is a bit strange in this file... ---
[jira] [Commented] (NIFI-4367) InvokedScriptedProcessor
[ https://issues.apache.org/jira/browse/NIFI-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337691#comment-16337691 ] ASF GitHub Bot commented on NIFI-4367: -- Github user mgaido91 commented on a diff in the pull request: https://github.com/apache/nifi/pull/2201#discussion_r163569718 --- Diff: nifi-nar-bundles/nifi-scripting-bundle/nifi-scripting-processors/src/main/java/org/apache/nifi/processors/script/InvokeScriptedProcessor.java --- @@ -461,8 +463,13 @@ public File getKerberosConfigurationFile() { // if there was existing validation errors and the processor loaded successfully if (currentValidationResults.isEmpty() && instance != null) { try { -// defer to the underlying processor for validation -final Collection instanceResults = instance.validate(context); +// defer to the underlying processor for validation, without the +// invokescriptedprocessor properties +final Set innerPropertyDescriptor = new HashSet(scriptingComponentHelper.getDescriptors()); + +ValidationContext innerValidationContext = new FilteredPropertiesValidationContextAdapter(context, innerPropertyDescriptor); +final Collection instanceResults = instance.validate(innerValidationContext); --- End diff -- I think we should do the same in the `onTrigger` method too > InvokedScriptedProcessor > > > Key: NIFI-4367 > URL: https://issues.apache.org/jira/browse/NIFI-4367 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.3.0, 1.4.0, 1.5.0 > Environment: Linux / Windows >Reporter: Patrice Freydiere >Priority: Major > Labels: InvokeScriptedProcessor, validation > > InvokeScriptedProcessor pass his ValidationContext to the inner script, > validate call > InvokeScriptedProcessor Line 465 :final > Collection instanceResults = instance.validate(context); > > The problem is that the invokedscript pass the ScriptFile PropertyDescriptor > that is validated, if the script derived from the > AbstractConfigurableComponent, (because the AbstractConfigurableComponent > validate all the context properties). > The context should be refined to remove the InvokeScriptedProcessor > Properties. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi pull request #2201: NIFI-4367 Fix on processor for permit deriving scri...
Github user mgaido91 commented on a diff in the pull request: https://github.com/apache/nifi/pull/2201#discussion_r163569718 --- Diff: nifi-nar-bundles/nifi-scripting-bundle/nifi-scripting-processors/src/main/java/org/apache/nifi/processors/script/InvokeScriptedProcessor.java --- @@ -461,8 +463,13 @@ public File getKerberosConfigurationFile() { // if there was existing validation errors and the processor loaded successfully if (currentValidationResults.isEmpty() && instance != null) { try { -// defer to the underlying processor for validation -final Collection instanceResults = instance.validate(context); +// defer to the underlying processor for validation, without the +// invokescriptedprocessor properties +final Set innerPropertyDescriptor = new HashSet(scriptingComponentHelper.getDescriptors()); + +ValidationContext innerValidationContext = new FilteredPropertiesValidationContextAdapter(context, innerPropertyDescriptor); +final Collection instanceResults = instance.validate(innerValidationContext); --- End diff -- I think we should do the same in the `onTrigger` method too ---
[jira] [Commented] (NIFI-4367) InvokedScriptedProcessor
[ https://issues.apache.org/jira/browse/NIFI-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337683#comment-16337683 ] ASF GitHub Bot commented on NIFI-4367: -- Github user mgaido91 commented on a diff in the pull request: https://github.com/apache/nifi/pull/2201#discussion_r163568827 --- Diff: nifi-nar-bundles/nifi-scripting-bundle/nifi-scripting-processors/src/main/java/org/apache/nifi/script/impl/FilteredPropertiesValidationContextAdapter.java --- @@ -0,0 +1,92 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.nifi.script.impl; + +import java.util.ArrayList; +import java.util.HashMap; +import java.util.HashSet; +import java.util.Map; +import java.util.Set; + +import org.apache.nifi.components.PropertyDescriptor; +import org.apache.nifi.components.PropertyValue; +import org.apache.nifi.components.ValidationContext; + +/** + * filter properties in the ValidationContext, proxy approach, for removing unwanted properties + * + * @author pfreydiere + * + */ +public class FilteredPropertiesValidationContextAdapter extends ValidationContextAdapter { + +private Set removedProperties; +private Set removedPropertyNames; + +public FilteredPropertiesValidationContextAdapter(ValidationContext validationContext, Set removedProperties) { +super(validationContext); +this.removedProperties = removedProperties; +Set keys = new HashSet<>(); +for (PropertyDescriptor p : removedProperties) { +keys.add(p.getName()); +} +this.removedPropertyNames = keys; +} + +@Override +public MapgetAllProperties() { +HashMap returnedProperties = new HashMap<>(super.getAllProperties()); --- End diff -- I think that the `returnedProperties` can be computed once in the constructor and reused, instead of being recreated anytime > InvokedScriptedProcessor > > > Key: NIFI-4367 > URL: https://issues.apache.org/jira/browse/NIFI-4367 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.3.0, 1.4.0, 1.5.0 > Environment: Linux / Windows >Reporter: Patrice Freydiere >Priority: Major > Labels: InvokeScriptedProcessor, validation > > InvokeScriptedProcessor pass his ValidationContext to the inner script, > validate call > InvokeScriptedProcessor Line 465 :final > Collection instanceResults = instance.validate(context); > > The problem is that the invokedscript pass the ScriptFile PropertyDescriptor > that is validated, if the script derived from the > AbstractConfigurableComponent, (because the AbstractConfigurableComponent > validate all the context properties). > The context should be refined to remove the InvokeScriptedProcessor > Properties. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi pull request #2201: NIFI-4367 Fix on processor for permit deriving scri...
Github user mgaido91 commented on a diff in the pull request: https://github.com/apache/nifi/pull/2201#discussion_r163568827 --- Diff: nifi-nar-bundles/nifi-scripting-bundle/nifi-scripting-processors/src/main/java/org/apache/nifi/script/impl/FilteredPropertiesValidationContextAdapter.java --- @@ -0,0 +1,92 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.nifi.script.impl; + +import java.util.ArrayList; +import java.util.HashMap; +import java.util.HashSet; +import java.util.Map; +import java.util.Set; + +import org.apache.nifi.components.PropertyDescriptor; +import org.apache.nifi.components.PropertyValue; +import org.apache.nifi.components.ValidationContext; + +/** + * filter properties in the ValidationContext, proxy approach, for removing unwanted properties + * + * @author pfreydiere + * + */ +public class FilteredPropertiesValidationContextAdapter extends ValidationContextAdapter { + +private Set removedProperties; +private Set removedPropertyNames; + +public FilteredPropertiesValidationContextAdapter(ValidationContext validationContext, Set removedProperties) { +super(validationContext); +this.removedProperties = removedProperties; +Set keys = new HashSet<>(); +for (PropertyDescriptor p : removedProperties) { +keys.add(p.getName()); +} +this.removedPropertyNames = keys; +} + +@Override +public MapgetAllProperties() { +HashMap returnedProperties = new HashMap<>(super.getAllProperties()); --- End diff -- I think that the `returnedProperties` can be computed once in the constructor and reused, instead of being recreated anytime ---
[GitHub] nifi pull request #2426: NIFI-4790: support HTTPS Proxy in InvokeHTTP
Github user mgaido91 commented on a diff in the pull request: https://github.com/apache/nifi/pull/2426#discussion_r163554821 --- Diff: nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/InvokeHTTP.java --- @@ -213,11 +219,22 @@ public static final PropertyDescriptor PROP_SSL_CONTEXT_SERVICE = new PropertyDescriptor.Builder() .name("SSL Context Service") -.description("The SSL Context Service used to provide client certificate information for TLS/SSL (https) connections.") +.description("The SSL Context Service used to provide client certificate information for TLS/SSL (https) connections." ++ " It is also used to connect to HTTPS Proxy.") .required(false) .identifiesControllerService(SSLContextService.class) .build(); +public static final PropertyDescriptor PROP_PROXY_TYPE = new PropertyDescriptor.Builder() +.name("Proxy Type") +.displayName("Proxy Type") +.description("The type of the proxy we are connecting to.") +.required(true) +.allowableValues(HTTP, HTTPS) +.defaultValue(HTTP.getValue()) +.expressionLanguageSupported(true) --- End diff -- thanks, I'll make it like this ---
[jira] [Commented] (NIFI-4790) Support HTTPS proxy in InvokeHTTP
[ https://issues.apache.org/jira/browse/NIFI-4790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337620#comment-16337620 ] ASF GitHub Bot commented on NIFI-4790: -- Github user mgaido91 commented on a diff in the pull request: https://github.com/apache/nifi/pull/2426#discussion_r163554821 --- Diff: nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/InvokeHTTP.java --- @@ -213,11 +219,22 @@ public static final PropertyDescriptor PROP_SSL_CONTEXT_SERVICE = new PropertyDescriptor.Builder() .name("SSL Context Service") -.description("The SSL Context Service used to provide client certificate information for TLS/SSL (https) connections.") +.description("The SSL Context Service used to provide client certificate information for TLS/SSL (https) connections." ++ " It is also used to connect to HTTPS Proxy.") .required(false) .identifiesControllerService(SSLContextService.class) .build(); +public static final PropertyDescriptor PROP_PROXY_TYPE = new PropertyDescriptor.Builder() +.name("Proxy Type") +.displayName("Proxy Type") +.description("The type of the proxy we are connecting to.") +.required(true) +.allowableValues(HTTP, HTTPS) +.defaultValue(HTTP.getValue()) +.expressionLanguageSupported(true) --- End diff -- thanks, I'll make it like this > Support HTTPS proxy in InvokeHTTP > - > > Key: NIFI-4790 > URL: https://issues.apache.org/jira/browse/NIFI-4790 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Marco Gaido >Assignee: Marco Gaido >Priority: Major > > InvokeHTTP currently assumes that the proxy (if set) uses HTTP. We should > introduce a new property to indicate the protocol used by the proxy (either > http or https) in order to support also HTTPS proxies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-4790) Support HTTPS proxy in InvokeHTTP
[ https://issues.apache.org/jira/browse/NIFI-4790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337613#comment-16337613 ] ASF GitHub Bot commented on NIFI-4790: -- Github user pvillard31 commented on a diff in the pull request: https://github.com/apache/nifi/pull/2426#discussion_r163554236 --- Diff: nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/InvokeHTTP.java --- @@ -213,11 +219,22 @@ public static final PropertyDescriptor PROP_SSL_CONTEXT_SERVICE = new PropertyDescriptor.Builder() .name("SSL Context Service") -.description("The SSL Context Service used to provide client certificate information for TLS/SSL (https) connections.") +.description("The SSL Context Service used to provide client certificate information for TLS/SSL (https) connections." ++ " It is also used to connect to HTTPS Proxy.") .required(false) .identifiesControllerService(SSLContextService.class) .build(); +public static final PropertyDescriptor PROP_PROXY_TYPE = new PropertyDescriptor.Builder() +.name("Proxy Type") +.displayName("Proxy Type") +.description("The type of the proxy we are connecting to.") +.required(true) +.allowableValues(HTTP, HTTPS) +.defaultValue(HTTP.getValue()) +.expressionLanguageSupported(true) --- End diff -- Unfortunately, I believe it's not possible to use EL on properties with allowable values (see https://issues.apache.org/jira/browse/NIFI-1832). If we want to use EL on this property, I think it needs to be a classic text property with a custom validator a bit like in InvokeHTTP with the request method property (https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/InvokeHTTP.java#L152). > Support HTTPS proxy in InvokeHTTP > - > > Key: NIFI-4790 > URL: https://issues.apache.org/jira/browse/NIFI-4790 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Marco Gaido >Assignee: Marco Gaido >Priority: Major > > InvokeHTTP currently assumes that the proxy (if set) uses HTTP. We should > introduce a new property to indicate the protocol used by the proxy (either > http or https) in order to support also HTTPS proxies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi pull request #2426: NIFI-4790: support HTTPS Proxy in InvokeHTTP
Github user pvillard31 commented on a diff in the pull request: https://github.com/apache/nifi/pull/2426#discussion_r163554236 --- Diff: nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/InvokeHTTP.java --- @@ -213,11 +219,22 @@ public static final PropertyDescriptor PROP_SSL_CONTEXT_SERVICE = new PropertyDescriptor.Builder() .name("SSL Context Service") -.description("The SSL Context Service used to provide client certificate information for TLS/SSL (https) connections.") +.description("The SSL Context Service used to provide client certificate information for TLS/SSL (https) connections." ++ " It is also used to connect to HTTPS Proxy.") .required(false) .identifiesControllerService(SSLContextService.class) .build(); +public static final PropertyDescriptor PROP_PROXY_TYPE = new PropertyDescriptor.Builder() +.name("Proxy Type") +.displayName("Proxy Type") +.description("The type of the proxy we are connecting to.") +.required(true) +.allowableValues(HTTP, HTTPS) +.defaultValue(HTTP.getValue()) +.expressionLanguageSupported(true) --- End diff -- Unfortunately, I believe it's not possible to use EL on properties with allowable values (see https://issues.apache.org/jira/browse/NIFI-1832). If we want to use EL on this property, I think it needs to be a classic text property with a custom validator a bit like in InvokeHTTP with the request method property (https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/InvokeHTTP.java#L152). ---
[jira] [Commented] (NIFI-3538) Add DeleteHBase processor(s)
[ https://issues.apache.org/jira/browse/NIFI-3538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337575#comment-16337575 ] ASF GitHub Bot commented on NIFI-3538: -- Github user mgaido91 commented on the issue: https://github.com/apache/nifi/pull/2294 LGTM > Add DeleteHBase processor(s) > > > Key: NIFI-3538 > URL: https://issues.apache.org/jira/browse/NIFI-3538 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Reporter: Matt Burgess >Assignee: Mike Thomsen >Priority: Major > > NiFi currently has processors for storing and retrieving cells/rows in HBase, > but there is no mechanism for deleting records and/or tables. > I'm not sure if a single DeleteHBase processor could accomplish both, that > can be discussed under this Jira (and can be split out if necessary). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi issue #2294: NIFI-3538 Added DeleteHBaseRow
Github user mgaido91 commented on the issue: https://github.com/apache/nifi/pull/2294 LGTM ---
[jira] [Commented] (NIFI-3538) Add DeleteHBase processor(s)
[ https://issues.apache.org/jira/browse/NIFI-3538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337570#comment-16337570 ] ASF GitHub Bot commented on NIFI-3538: -- Github user MikeThomsen commented on the issue: https://github.com/apache/nifi/pull/2294 That restart.index change is in place. I put a unit test in there that tests it out and it works just fine. > Add DeleteHBase processor(s) > > > Key: NIFI-3538 > URL: https://issues.apache.org/jira/browse/NIFI-3538 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Reporter: Matt Burgess >Assignee: Mike Thomsen >Priority: Major > > NiFi currently has processors for storing and retrieving cells/rows in HBase, > but there is no mechanism for deleting records and/or tables. > I'm not sure if a single DeleteHBase processor could accomplish both, that > can be discussed under this Jira (and can be split out if necessary). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi issue #2294: NIFI-3538 Added DeleteHBaseRow
Github user MikeThomsen commented on the issue: https://github.com/apache/nifi/pull/2294 That restart.index change is in place. I put a unit test in there that tests it out and it works just fine. ---
[jira] [Commented] (NIFI-4786) Allow Expression Evaluation to Kinesis/Firehose Stream Name
[ https://issues.apache.org/jira/browse/NIFI-4786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337547#comment-16337547 ] ASF GitHub Bot commented on NIFI-4786: -- GitHub user SunSatION reopened a pull request: https://github.com/apache/nifi/pull/2409 NIFI-4786 - Allow Expression Evaluation to Kinesis/Firehose Stream Name Thank you for submitting a contribution to Apache NiFi. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [x] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [x] Does your PR title start with NIFI- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [x] Has your PR been rebased against the latest commit within the target branch (typically master)? - [x] Is your initial contribution a single, squashed commit? ### For code changes: - [x] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder? - [ ] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly? - [ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly? - [ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties? ### For documentation related changes: - [ ] Have you ensured that format looks appropriate for the output in which it is rendered? ### Note: Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible. You can merge this pull request into a Git repository by running: $ git pull https://github.com/SunSatION/nifi master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/2409.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 #2409 commit a4e7e677d6f9b85fb872f5217532fb6cb082c2c2 Author: dorian.bugejaDate: 2018-01-17T10:22:39Z NIFI-4786 - Allow Expression Evaluation to Kinesis/Firehose Stream Name commit 7a4e1a71c5ee89191f2b5204b2edfa0f614624b9 Author: dorian.bugeja Date: 2018-01-17T10:36:12Z NIFI-4786 - Allow Expression Evaluation to Kinesis/Firehose Stream Name commit 467f37581ec6f4240eee49674e53563cd31c6dee Author: Dorian Bugeja Date: 2018-01-24T06:34:31Z NIFI-4786 - Fix if condition convention > Allow Expression Evaluation to Kinesis/Firehose Stream Name > --- > > Key: NIFI-4786 > URL: https://issues.apache.org/jira/browse/NIFI-4786 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.5.0 >Reporter: Dorian Bugeja >Priority: Minor > Labels: features, performance, pull-request-available > Attachments: > NIFI_4786___Allow_Expression_Evaluation_to_Kinesis_Firehose_Stream_Name_NIFI_4786___Allow_1.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > Currenctly, the Stream name propoerty for both Firehose and Kinesis does not > support the expression language. Routing can be performed based on an > attribute of the flowfile and having a single component rather than multiple > for each one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-4786) Allow Expression Evaluation to Kinesis/Firehose Stream Name
[ https://issues.apache.org/jira/browse/NIFI-4786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337546#comment-16337546 ] ASF GitHub Bot commented on NIFI-4786: -- Github user SunSatION closed the pull request at: https://github.com/apache/nifi/pull/2409 > Allow Expression Evaluation to Kinesis/Firehose Stream Name > --- > > Key: NIFI-4786 > URL: https://issues.apache.org/jira/browse/NIFI-4786 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.5.0 >Reporter: Dorian Bugeja >Priority: Minor > Labels: features, performance, pull-request-available > Attachments: > NIFI_4786___Allow_Expression_Evaluation_to_Kinesis_Firehose_Stream_Name_NIFI_4786___Allow_1.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > Currenctly, the Stream name propoerty for both Firehose and Kinesis does not > support the expression language. Routing can be performed based on an > attribute of the flowfile and having a single component rather than multiple > for each one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi pull request #2409: NIFI-4786 - Allow Expression Evaluation to Kinesis/...
GitHub user SunSatION reopened a pull request: https://github.com/apache/nifi/pull/2409 NIFI-4786 - Allow Expression Evaluation to Kinesis/Firehose Stream Name Thank you for submitting a contribution to Apache NiFi. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [x] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [x] Does your PR title start with NIFI- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [x] Has your PR been rebased against the latest commit within the target branch (typically master)? - [x] Is your initial contribution a single, squashed commit? ### For code changes: - [x] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder? - [ ] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly? - [ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly? - [ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties? ### For documentation related changes: - [ ] Have you ensured that format looks appropriate for the output in which it is rendered? ### Note: Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible. You can merge this pull request into a Git repository by running: $ git pull https://github.com/SunSatION/nifi master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/2409.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 #2409 commit a4e7e677d6f9b85fb872f5217532fb6cb082c2c2 Author: dorian.bugejaDate: 2018-01-17T10:22:39Z NIFI-4786 - Allow Expression Evaluation to Kinesis/Firehose Stream Name commit 7a4e1a71c5ee89191f2b5204b2edfa0f614624b9 Author: dorian.bugeja Date: 2018-01-17T10:36:12Z NIFI-4786 - Allow Expression Evaluation to Kinesis/Firehose Stream Name commit 467f37581ec6f4240eee49674e53563cd31c6dee Author: Dorian Bugeja Date: 2018-01-24T06:34:31Z NIFI-4786 - Fix if condition convention ---
[GitHub] nifi pull request #2409: NIFI-4786 - Allow Expression Evaluation to Kinesis/...
Github user SunSatION closed the pull request at: https://github.com/apache/nifi/pull/2409 ---
[jira] [Commented] (NIFI-3538) Add DeleteHBase processor(s)
[ https://issues.apache.org/jira/browse/NIFI-3538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337504#comment-16337504 ] ASF GitHub Bot commented on NIFI-3538: -- Github user MikeThomsen commented on the issue: https://github.com/apache/nifi/pull/2294 @mgaido91 That loop, incidentally, is being eliminated now because I decided to follow the same practice that was used in PutHBaseRecord where on failure it adds "restart.index" which is roughly where in the loop it failed. > Add DeleteHBase processor(s) > > > Key: NIFI-3538 > URL: https://issues.apache.org/jira/browse/NIFI-3538 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Reporter: Matt Burgess >Assignee: Mike Thomsen >Priority: Major > > NiFi currently has processors for storing and retrieving cells/rows in HBase, > but there is no mechanism for deleting records and/or tables. > I'm not sure if a single DeleteHBase processor could accomplish both, that > can be discussed under this Jira (and can be split out if necessary). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi issue #2294: NIFI-3538 Added DeleteHBaseRow
Github user MikeThomsen commented on the issue: https://github.com/apache/nifi/pull/2294 @mgaido91 That loop, incidentally, is being eliminated now because I decided to follow the same practice that was used in PutHBaseRecord where on failure it adds "restart.index" which is roughly where in the loop it failed. ---
[jira] [Updated] (NIFI-4812) delete_registry_client call only accepts ID, but endpoint also expects Revision
[ https://issues.apache.org/jira/browse/NIFI-4812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Chaffelson updated NIFI-4812: Description: Using the Swagger Generated Python Client. When the delete_registry_client command is called from the ControllerApi(), the arguments expected by NiFi (id, version) and the arguments allowed by swagger (id only) do not match, resulting in a failure. {code:java} ControllerApi().delete_registry_client(test_client.id) HTTP response body: The revision must be specified. ControllerApi().delete_registry_client(test_client.id, test_client.revision) TypeError: delete_registry_client() takes exactly 2 arguments (3 given) {code} was: Using the Swagger Generated Python Client. When the delete_registry_client command is called from the ControllerApi(), the arguments expected by NiFi (id, revision) and the arguments allowed by swagger (id only) do not match, resulting in a failure. {code:java} ControllerApi().delete_registry_client(test_client.id) HTTP response body: The revision must be specified. ControllerApi().delete_registry_client(test_client.id, test_client.revision) TypeError: delete_registry_client() takes exactly 2 arguments (3 given) {code} > delete_registry_client call only accepts ID, but endpoint also expects > Revision > --- > > Key: NIFI-4812 > URL: https://issues.apache.org/jira/browse/NIFI-4812 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework, Flow Versioning >Affects Versions: 1.5.0, 1.6.0 >Reporter: Daniel Chaffelson >Priority: Minor > > Using the Swagger Generated Python Client. > When the delete_registry_client command is called from the ControllerApi(), > the arguments expected by NiFi (id, version) and the arguments allowed by > swagger (id only) do not match, resulting in a failure. > {code:java} > ControllerApi().delete_registry_client(test_client.id) > HTTP response body: The revision must be specified. > ControllerApi().delete_registry_client(test_client.id, test_client.revision) > TypeError: delete_registry_client() takes exactly 2 arguments (3 given) > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-4813) ControllerServiceLookup: Add method signature
[ https://issues.apache.org/jira/browse/NIFI-4813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Kessler updated NIFI-4813: -- Description: The ControllerServiceLookup interface contains the following method signature: {code:java} Set getControllerServiceIdentifiers(Class serviceType) throws IllegalArgumentException;{code} Its implementation in the StandardControllerServiceProvider has more or less been deprecated as it now just throws an UnsupportedOperationException. It has been replaced in that class by the following method but that signature has not yet been added to the interface: {code:java} public Set getControllerServiceIdentifiers(final Class serviceType, final String groupId){code} This causes a problem for processors that used the former method via getControllerServiceLookup() as that method only returns the interface. Therefore it should be added to the interface. [1][https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=blob;f=nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/service/StandardControllerServiceProvider.java;hb=HEAD#l662] [2][https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=blob;f=nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/service/StandardControllerServiceProvider.java;hb=HEAD#l798] [3][https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=blob;f=nifi-api/src/main/java/org/apache/nifi/controller/ControllerServiceLookup.java;hb=HEAD#l64] was: The ControllerServiceLookup interface contains the following method signature: {code:java} Set getControllerServiceIdentifiers(Class serviceType) throws IllegalArgumentException;{code} Its implementation in the StandardControllerServiceProvider has more or less been deprecated as it now just throws an UnsupportedOperationException. It has been replaced in that class by the following method but that signature has not yet been added to the interface: {code:java} public Set getControllerServiceIdentifiers(final Class serviceType, final String groupId){code} This causes a problem for processors that used the former method via getControllerServiceLookup() as that class only returns the interface. Therefore it should be added to the interface. [1][https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=blob;f=nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/service/StandardControllerServiceProvider.java;hb=HEAD#l662] [2][https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=blob;f=nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/service/StandardControllerServiceProvider.java;hb=HEAD#l798] [3][https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=blob;f=nifi-api/src/main/java/org/apache/nifi/controller/ControllerServiceLookup.java;hb=HEAD#l64] > ControllerServiceLookup: Add method signature > - > > Key: NIFI-4813 > URL: https://issues.apache.org/jira/browse/NIFI-4813 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Affects Versions: 1.4.0 >Reporter: Jon Kessler >Priority: Minor > > The ControllerServiceLookup interface contains the following method signature: > {code:java} > Set getControllerServiceIdentifiers(Class ControllerService> serviceType) throws IllegalArgumentException;{code} > Its implementation in the StandardControllerServiceProvider has more or less > been deprecated as it now just throws an UnsupportedOperationException. It > has been replaced in that class by the following method but that signature > has not yet been added to the interface: > {code:java} > public Set getControllerServiceIdentifiers(final Class ControllerService> serviceType, final String groupId){code} > This causes a problem for processors that used the former method via > getControllerServiceLookup() as that method only returns the interface. > Therefore it should be added to the interface. > [1][https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=blob;f=nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/service/StandardControllerServiceProvider.java;hb=HEAD#l662] > > [2][https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=blob;f=nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/service/StandardControllerServiceProvider.java;hb=HEAD#l798] > > [3][https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=blob;f=nifi-api/src/main/java/org/apache/nifi/controller/ControllerServiceLookup.java;hb=HEAD#l64] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (NIFI-4813) ControllerServiceLookup: Add method signature
Jon Kessler created NIFI-4813: - Summary: ControllerServiceLookup: Add method signature Key: NIFI-4813 URL: https://issues.apache.org/jira/browse/NIFI-4813 Project: Apache NiFi Issue Type: Improvement Components: Core Framework Affects Versions: 1.4.0 Reporter: Jon Kessler The ControllerServiceLookup interface contains the following method signature: {code:java} Set getControllerServiceIdentifiers(Class serviceType) throws IllegalArgumentException;{code} Its implementation in the StandardControllerServiceProvider has more or less been deprecated as it now just throws an UnsupportedOperationException. It has been replaced in that class by the following method but that signature has not yet been added to the interface: {code:java} public Set getControllerServiceIdentifiers(final Class serviceType, final String groupId){code} This causes a problem for processors that used the former method via getControllerServiceLookup() as that class only returns the interface. Therefore it should be added to the interface. [1][https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=blob;f=nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/service/StandardControllerServiceProvider.java;hb=HEAD#l662] [2][https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=blob;f=nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/service/StandardControllerServiceProvider.java;hb=HEAD#l798] [3][https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=blob;f=nifi-api/src/main/java/org/apache/nifi/controller/ControllerServiceLookup.java;hb=HEAD#l64] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi issue #2294: NIFI-3538 Added DeleteHBaseRow
Github user mgaido91 commented on the issue: https://github.com/apache/nifi/pull/2294 thanks @MikeThomsen. Actually I was referring at [this comment](https://github.com/apache/nifi/pull/2294#discussion_r160140592). I think that is my last comment. Overall it LGTM. On the batch size, I think that the committers who will have to review this before merging can express their opinion. Your opinion makes sense, but it involves a consistency issue: we need a tradeoff and I think only committers can decide what to do. ---
[jira] [Commented] (NIFI-3538) Add DeleteHBase processor(s)
[ https://issues.apache.org/jira/browse/NIFI-3538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337464#comment-16337464 ] ASF GitHub Bot commented on NIFI-3538: -- Github user mgaido91 commented on the issue: https://github.com/apache/nifi/pull/2294 thanks @MikeThomsen. Actually I was referring at [this comment](https://github.com/apache/nifi/pull/2294#discussion_r160140592). I think that is my last comment. Overall it LGTM. On the batch size, I think that the committers who will have to review this before merging can express their opinion. Your opinion makes sense, but it involves a consistency issue: we need a tradeoff and I think only committers can decide what to do. > Add DeleteHBase processor(s) > > > Key: NIFI-3538 > URL: https://issues.apache.org/jira/browse/NIFI-3538 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Reporter: Matt Burgess >Assignee: Mike Thomsen >Priority: Major > > NiFi currently has processors for storing and retrieving cells/rows in HBase, > but there is no mechanism for deleting records and/or tables. > I'm not sure if a single DeleteHBase processor could accomplish both, that > can be discussed under this Jira (and can be split out if necessary). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-4812) delete_registry_client call only accepts ID, but endpoint also expects Revision
[ https://issues.apache.org/jira/browse/NIFI-4812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337449#comment-16337449 ] Daniel Chaffelson commented on NIFI-4812: - It works despite this if you deconstruct the json message via browser developer tools and present the exact format expected: {code:java} ControllerApi().delete_registry_client( id=client.id, version=client.revision.version ) {code} However this is completely counter to the message provided by the errors. > delete_registry_client call only accepts ID, but endpoint also expects > Revision > --- > > Key: NIFI-4812 > URL: https://issues.apache.org/jira/browse/NIFI-4812 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework, Flow Versioning >Affects Versions: 1.5.0, 1.6.0 >Reporter: Daniel Chaffelson >Priority: Minor > > Using the Swagger Generated Python Client. > When the delete_registry_client command is called from the ControllerApi(), > the arguments expected by NiFi (id, revision) and the arguments allowed by > swagger (id only) do not match, resulting in a failure. > {code:java} > ControllerApi().delete_registry_client(test_client.id) > HTTP response body: The revision must be specified. > ControllerApi().delete_registry_client(test_client.id, test_client.revision) > TypeError: delete_registry_client() takes exactly 2 arguments (3 given) > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-3538) Add DeleteHBase processor(s)
[ https://issues.apache.org/jira/browse/NIFI-3538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337448#comment-16337448 ] ASF GitHub Bot commented on NIFI-3538: -- Github user MikeThomsen commented on the issue: https://github.com/apache/nifi/pull/2294 @mgaido91 I added the charset. I can't believe I missed that... WRT the batching, I stand by my opinion that we need to have a sane default there because there needs to be a way to ensure someone doesn't accidentally (or on purpose) send an operation that is too big to HBase at once. To me this is not a theoretical issue because I ran into something like this with PutHBaseRecord doing genomic data ingestion w/ NiFi. The data set would generate easily 10B, if not 20-25B tiny (like few dozen byte) writes. I had to really scale back the size of each record set I was sending to PutHBaseRecord because it was easily to generate so many Puts that it would hammer a region offline unexpectedly. I'm not a HBase expert by any means, but it seems like a recipe for trouble based on my experience with putting a lot of small writes (and Delete objects are tiny writes). > Add DeleteHBase processor(s) > > > Key: NIFI-3538 > URL: https://issues.apache.org/jira/browse/NIFI-3538 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Reporter: Matt Burgess >Assignee: Mike Thomsen >Priority: Major > > NiFi currently has processors for storing and retrieving cells/rows in HBase, > but there is no mechanism for deleting records and/or tables. > I'm not sure if a single DeleteHBase processor could accomplish both, that > can be discussed under this Jira (and can be split out if necessary). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-4812) delete_registry_client call only accepts ID, but endpoint also expects Revision
[ https://issues.apache.org/jira/browse/NIFI-4812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Chaffelson updated NIFI-4812: Priority: Minor (was: Major) > delete_registry_client call only accepts ID, but endpoint also expects > Revision > --- > > Key: NIFI-4812 > URL: https://issues.apache.org/jira/browse/NIFI-4812 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework, Flow Versioning >Affects Versions: 1.5.0, 1.6.0 >Reporter: Daniel Chaffelson >Priority: Minor > > Using the Swagger Generated Python Client. > When the delete_registry_client command is called from the ControllerApi(), > the arguments expected by NiFi (id, revision) and the arguments allowed by > swagger (id only) do not match, resulting in a failure. > {code:java} > ControllerApi().delete_registry_client(test_client.id) > HTTP response body: The revision must be specified. > ControllerApi().delete_registry_client(test_client.id, test_client.revision) > TypeError: delete_registry_client() takes exactly 2 arguments (3 given) > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi issue #2294: NIFI-3538 Added DeleteHBaseRow
Github user MikeThomsen commented on the issue: https://github.com/apache/nifi/pull/2294 @mgaido91 I added the charset. I can't believe I missed that... WRT the batching, I stand by my opinion that we need to have a sane default there because there needs to be a way to ensure someone doesn't accidentally (or on purpose) send an operation that is too big to HBase at once. To me this is not a theoretical issue because I ran into something like this with PutHBaseRecord doing genomic data ingestion w/ NiFi. The data set would generate easily 10B, if not 20-25B tiny (like few dozen byte) writes. I had to really scale back the size of each record set I was sending to PutHBaseRecord because it was easily to generate so many Puts that it would hammer a region offline unexpectedly. I'm not a HBase expert by any means, but it seems like a recipe for trouble based on my experience with putting a lot of small writes (and Delete objects are tiny writes). ---
[jira] [Commented] (NIFI-4790) Support HTTPS proxy in InvokeHTTP
[ https://issues.apache.org/jira/browse/NIFI-4790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337447#comment-16337447 ] ASF GitHub Bot commented on NIFI-4790: -- Github user mgaido91 commented on the issue: https://github.com/apache/nifi/pull/2426 @ijokarumawak thanks, added the EL support. I am not sure why Appveyor is failing. The failure seems not related to the PR. > Support HTTPS proxy in InvokeHTTP > - > > Key: NIFI-4790 > URL: https://issues.apache.org/jira/browse/NIFI-4790 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Marco Gaido >Assignee: Marco Gaido >Priority: Major > > InvokeHTTP currently assumes that the proxy (if set) uses HTTP. We should > introduce a new property to indicate the protocol used by the proxy (either > http or https) in order to support also HTTPS proxies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi issue #2426: NIFI-4790: support HTTPS Proxy in InvokeHTTP
Github user mgaido91 commented on the issue: https://github.com/apache/nifi/pull/2426 @ijokarumawak thanks, added the EL support. I am not sure why Appveyor is failing. The failure seems not related to the PR. ---
[jira] [Commented] (NIFI-4393) AbstractDatabaseFetchProcessor handles SQL Server brackets incorrectly
[ https://issues.apache.org/jira/browse/NIFI-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337431#comment-16337431 ] ASF GitHub Bot commented on NIFI-4393: -- Github user ijokarumawak commented on the issue: https://github.com/apache/nifi/pull/2424 @mattyb149 Thanks for your suggestion. I considered that path, too. But I did it this way as it seems simpler to the objective to address the issue. However, I think your comment is a good point. And I prefer having wrap method in DatabaseAdapters instead of unwrap. Let's discuss a bit more. I noticed that table and column names are spilled into few places. I think we should define how we want those to be set. - Processor properties: - Columns to Return - Maximum Value Columns - Additional WHERE clause - Custom SQL (to be added by #2162) - Additional WHERE clause and Custom SQL might be challenging to wrap problematic identifies by Processor automatically. - Processor State: Stored with a key in `{tableName}!@!{columnName}` format. Do we want to keep database specific characters here? - Output FlowFile Attributes: - max.{columnName} = {maxValue} - tableName = {tableName] - Do we want to keep database specific characters here? Even if we change DatabaseAdapter method from unwrap to wrap, it's still possible to use wrap character to unwrap. But we need to make a consensus on how above listed variables are written. > AbstractDatabaseFetchProcessor handles SQL Server brackets incorrectly > -- > > Key: NIFI-4393 > URL: https://issues.apache.org/jira/browse/NIFI-4393 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.4.0 >Reporter: Mikołaj Siedlarek >Assignee: Koji Kawamura >Priority: Major > Attachments: > 0001-Handle-SQL-Server-square-brackets-in-AbstractDatabas.patch > > > SQL Server allows column names to contain whitespace, in which case they are > written in SQL queries inside square brackets. When using processors based on > {{AbstractDatabaseFetchProcessor}}, such as {{QueryDatabaseTable}} they have > to be specified in "Maximum-value Columns" in square brackets, because > otherwise they would break a SELECT query. However, when such column name is > retrieved from ResultSetMetaData, the driver returns it without square > brackets. This causes a mismatch between the key used to save last seen > maximum value in processor's state and the one used to search for the value > later. > I'm not sure whether the attached patch is very elegant, but it fixes the > issue in a simplest way possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi issue #2424: NIFI-4393: Handle database specific identifier escape char...
Github user ijokarumawak commented on the issue: https://github.com/apache/nifi/pull/2424 @mattyb149 Thanks for your suggestion. I considered that path, too. But I did it this way as it seems simpler to the objective to address the issue. However, I think your comment is a good point. And I prefer having wrap method in DatabaseAdapters instead of unwrap. Let's discuss a bit more. I noticed that table and column names are spilled into few places. I think we should define how we want those to be set. - Processor properties: - Columns to Return - Maximum Value Columns - Additional WHERE clause - Custom SQL (to be added by #2162) - Additional WHERE clause and Custom SQL might be challenging to wrap problematic identifies by Processor automatically. - Processor State: Stored with a key in `{tableName}!@!{columnName}` format. Do we want to keep database specific characters here? - Output FlowFile Attributes: - max.{columnName} = {maxValue} - tableName = {tableName] - Do we want to keep database specific characters here? Even if we change DatabaseAdapter method from unwrap to wrap, it's still possible to use wrap character to unwrap. But we need to make a consensus on how above listed variables are written. ---
[jira] [Created] (NIFI-4812) delete_registry_client call only accepts ID, but endpoint also expects Revision
Daniel Chaffelson created NIFI-4812: --- Summary: delete_registry_client call only accepts ID, but endpoint also expects Revision Key: NIFI-4812 URL: https://issues.apache.org/jira/browse/NIFI-4812 Project: Apache NiFi Issue Type: Bug Components: Core Framework, Flow Versioning Affects Versions: 1.5.0, 1.6.0 Reporter: Daniel Chaffelson Using the Swagger Generated Python Client. When the delete_registry_client command is called from the ControllerApi(), the arguments expected by NiFi (id, revision) and the arguments allowed by swagger (id only) do not match, resulting in a failure. {code:java} ControllerApi().delete_registry_client(test_client.id) HTTP response body: The revision must be specified. ControllerApi().delete_registry_client(test_client.id, test_client.revision) TypeError: delete_registry_client() takes exactly 2 arguments (3 given) {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi pull request #2426: NIFI-4790: support HTTPS Proxy in InvokeHTTP
Github user ijokarumawak commented on a diff in the pull request: https://github.com/apache/nifi/pull/2426#discussion_r163515579 --- Diff: nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/InvokeHTTP.java --- @@ -213,11 +219,21 @@ public static final PropertyDescriptor PROP_SSL_CONTEXT_SERVICE = new PropertyDescriptor.Builder() .name("SSL Context Service") -.description("The SSL Context Service used to provide client certificate information for TLS/SSL (https) connections.") +.description("The SSL Context Service used to provide client certificate information for TLS/SSL (https) connections." ++ " It is also used to connect to HTTPS Proxy.") .required(false) .identifiesControllerService(SSLContextService.class) .build(); +public static final PropertyDescriptor PROP_PROXY_TYPE = new PropertyDescriptor.Builder() --- End diff -- Probably we should support Expression Language with "Proxy Type" because Proxy host and port do so. ---
[jira] [Commented] (NIFI-4790) Support HTTPS proxy in InvokeHTTP
[ https://issues.apache.org/jira/browse/NIFI-4790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337405#comment-16337405 ] ASF GitHub Bot commented on NIFI-4790: -- Github user ijokarumawak commented on a diff in the pull request: https://github.com/apache/nifi/pull/2426#discussion_r163515579 --- Diff: nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/InvokeHTTP.java --- @@ -213,11 +219,21 @@ public static final PropertyDescriptor PROP_SSL_CONTEXT_SERVICE = new PropertyDescriptor.Builder() .name("SSL Context Service") -.description("The SSL Context Service used to provide client certificate information for TLS/SSL (https) connections.") +.description("The SSL Context Service used to provide client certificate information for TLS/SSL (https) connections." ++ " It is also used to connect to HTTPS Proxy.") .required(false) .identifiesControllerService(SSLContextService.class) .build(); +public static final PropertyDescriptor PROP_PROXY_TYPE = new PropertyDescriptor.Builder() --- End diff -- Probably we should support Expression Language with "Proxy Type" because Proxy host and port do so. > Support HTTPS proxy in InvokeHTTP > - > > Key: NIFI-4790 > URL: https://issues.apache.org/jira/browse/NIFI-4790 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Marco Gaido >Assignee: Marco Gaido >Priority: Major > > InvokeHTTP currently assumes that the proxy (if set) uses HTTP. We should > introduce a new property to indicate the protocol used by the proxy (either > http or https) in order to support also HTTPS proxies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (NIFI-4811) Use a newer version of spring-data-redis
Johan Oceanstorm created NIFI-4811: -- Summary: Use a newer version of spring-data-redis Key: NIFI-4811 URL: https://issues.apache.org/jira/browse/NIFI-4811 Project: Apache NiFi Issue Type: Improvement Reporter: Johan Oceanstorm NiFi uses version 1.8.3 of spring-data-redis (as you can see [here|[https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-redis-bundle/pom.xml#L31].] This version is an old version. The newer stable version is 2.0.2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-4790) Support HTTPS proxy in InvokeHTTP
[ https://issues.apache.org/jira/browse/NIFI-4790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337110#comment-16337110 ] ASF GitHub Bot commented on NIFI-4790: -- Github user pvillard31 commented on a diff in the pull request: https://github.com/apache/nifi/pull/2426#discussion_r163476469 --- Diff: nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/InvokeHTTP.java --- @@ -213,11 +219,21 @@ public static final PropertyDescriptor PROP_SSL_CONTEXT_SERVICE = new PropertyDescriptor.Builder() .name("SSL Context Service") -.description("The SSL Context Service used to provide client certificate information for TLS/SSL (https) connections.") +.description("The SSL Context Service used to provide client certificate information for TLS/SSL (https) connections." ++ " It is also used to connect to HTTPS Proxy.") .required(false) .identifiesControllerService(SSLContextService.class) .build(); +public static final PropertyDescriptor PROP_PROXY_TYPE = new PropertyDescriptor.Builder() +.name("Proxy Type") +.displayName("Proxy Type") +.description("The type of the proxy we are connecting to.") +.required(false) --- End diff -- We usually set ``.required(true)`` when you have a list of allowable values with a default value. > Support HTTPS proxy in InvokeHTTP > - > > Key: NIFI-4790 > URL: https://issues.apache.org/jira/browse/NIFI-4790 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Marco Gaido >Assignee: Marco Gaido >Priority: Major > > InvokeHTTP currently assumes that the proxy (if set) uses HTTP. We should > introduce a new property to indicate the protocol used by the proxy (either > http or https) in order to support also HTTPS proxies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-4790) Support HTTPS proxy in InvokeHTTP
[ https://issues.apache.org/jira/browse/NIFI-4790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337109#comment-16337109 ] ASF GitHub Bot commented on NIFI-4790: -- Github user pvillard31 commented on a diff in the pull request: https://github.com/apache/nifi/pull/2426#discussion_r163476703 --- Diff: nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/InvokeHTTP.java --- @@ -513,6 +530,17 @@ public void onPropertyModified(final PropertyDescriptor descriptor, final String results.add(new ValidationResult.Builder().subject("Proxy").valid(false).explanation("If Proxy username is set, proxy host must be set").build()); } +final boolean proxyTypeSet = validationContext.getProperty(PROP_PROXY_TYPE).isSet(); --- End diff -- Will always be true based on the previous comment. > Support HTTPS proxy in InvokeHTTP > - > > Key: NIFI-4790 > URL: https://issues.apache.org/jira/browse/NIFI-4790 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Marco Gaido >Assignee: Marco Gaido >Priority: Major > > InvokeHTTP currently assumes that the proxy (if set) uses HTTP. We should > introduce a new property to indicate the protocol used by the proxy (either > http or https) in order to support also HTTPS proxies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-4790) Support HTTPS proxy in InvokeHTTP
[ https://issues.apache.org/jira/browse/NIFI-4790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337108#comment-16337108 ] ASF GitHub Bot commented on NIFI-4790: -- Github user pvillard31 commented on a diff in the pull request: https://github.com/apache/nifi/pull/2426#discussion_r163476600 --- Diff: nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/InvokeHTTP.java --- @@ -513,6 +530,17 @@ public void onPropertyModified(final PropertyDescriptor descriptor, final String results.add(new ValidationResult.Builder().subject("Proxy").valid(false).explanation("If Proxy username is set, proxy host must be set").build()); } +final boolean proxyTypeSet = validationContext.getProperty(PROP_PROXY_TYPE).isSet(); + +if(proxyHostSet && !validationContext.getProperty(PROP_PROXY_TYPE).isSet()) { --- End diff -- I believe this check could be removed based on the previous comment. > Support HTTPS proxy in InvokeHTTP > - > > Key: NIFI-4790 > URL: https://issues.apache.org/jira/browse/NIFI-4790 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Marco Gaido >Assignee: Marco Gaido >Priority: Major > > InvokeHTTP currently assumes that the proxy (if set) uses HTTP. We should > introduce a new property to indicate the protocol used by the proxy (either > http or https) in order to support also HTTPS proxies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi pull request #2426: NIFI-4790: support HTTPS Proxy in InvokeHTTP
Github user pvillard31 commented on a diff in the pull request: https://github.com/apache/nifi/pull/2426#discussion_r163476703 --- Diff: nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/InvokeHTTP.java --- @@ -513,6 +530,17 @@ public void onPropertyModified(final PropertyDescriptor descriptor, final String results.add(new ValidationResult.Builder().subject("Proxy").valid(false).explanation("If Proxy username is set, proxy host must be set").build()); } +final boolean proxyTypeSet = validationContext.getProperty(PROP_PROXY_TYPE).isSet(); --- End diff -- Will always be true based on the previous comment. ---
[GitHub] nifi pull request #2426: NIFI-4790: support HTTPS Proxy in InvokeHTTP
Github user pvillard31 commented on a diff in the pull request: https://github.com/apache/nifi/pull/2426#discussion_r163476469 --- Diff: nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/InvokeHTTP.java --- @@ -213,11 +219,21 @@ public static final PropertyDescriptor PROP_SSL_CONTEXT_SERVICE = new PropertyDescriptor.Builder() .name("SSL Context Service") -.description("The SSL Context Service used to provide client certificate information for TLS/SSL (https) connections.") +.description("The SSL Context Service used to provide client certificate information for TLS/SSL (https) connections." ++ " It is also used to connect to HTTPS Proxy.") .required(false) .identifiesControllerService(SSLContextService.class) .build(); +public static final PropertyDescriptor PROP_PROXY_TYPE = new PropertyDescriptor.Builder() +.name("Proxy Type") +.displayName("Proxy Type") +.description("The type of the proxy we are connecting to.") +.required(false) --- End diff -- We usually set ``.required(true)`` when you have a list of allowable values with a default value. ---
[GitHub] nifi pull request #2426: NIFI-4790: support HTTPS Proxy in InvokeHTTP
Github user pvillard31 commented on a diff in the pull request: https://github.com/apache/nifi/pull/2426#discussion_r163476600 --- Diff: nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/InvokeHTTP.java --- @@ -513,6 +530,17 @@ public void onPropertyModified(final PropertyDescriptor descriptor, final String results.add(new ValidationResult.Builder().subject("Proxy").valid(false).explanation("If Proxy username is set, proxy host must be set").build()); } +final boolean proxyTypeSet = validationContext.getProperty(PROP_PROXY_TYPE).isSet(); + +if(proxyHostSet && !validationContext.getProperty(PROP_PROXY_TYPE).isSet()) { --- End diff -- I believe this check could be removed based on the previous comment. ---