[jira] [Commented] (NIFIREG-128) Swagger spec missing body param for create/update bucket

2018-01-24 Thread Daniel Chaffelson (JIRA)

[ 
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

2018-01-24 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-01-24 Thread Chaffelson
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

2018-01-24 Thread Deon Huang (JIRA)

[ 
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

2018-01-24 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-01-24 Thread apiri
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

2018-01-24 Thread marco polo (JIRA)

 [ 
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

2018-01-24 Thread marco polo (JIRA)

 [ 
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

2018-01-24 Thread Kevin Doran (JIRA)

 [ 
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

2018-01-24 Thread ASF GitHub Bot (JIRA)

[ 
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 Doran 
Date:   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

2018-01-24 Thread Kevin Doran (JIRA)

 [ 
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

2018-01-24 Thread kevdoran
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 Doran 
Date:   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

2018-01-24 Thread Kevin Doran (JIRA)

 [ 
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

2018-01-24 Thread Kevin Doran (JIRA)

 [ 
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

2018-01-24 Thread Daniel Chaffelson (JIRA)
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

2018-01-24 Thread Pierre Villard (JIRA)

 [ 
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

2018-01-24 Thread Pierre Villard (JIRA)

 [ 
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

2018-01-24 Thread asfgit
Github user asfgit closed the pull request at:

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


---


[jira] [Commented] (NIFI-4790) Support HTTPS proxy in InvokeHTTP

2018-01-24 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-01-24 Thread ASF subversion and git services (JIRA)

[ 
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 Villard 

This 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

2018-01-24 Thread pvillard31
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

2018-01-24 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-01-24 Thread Matt Burgess (JIRA)

 [ 
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

2018-01-24 Thread Matt Burgess (JIRA)

 [ 
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

2018-01-24 Thread Matt Burgess (JIRA)

 [ 
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

2018-01-24 Thread Matt Burgess (JIRA)

[ 
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

2018-01-24 Thread Matt Burgess (JIRA)

 [ 
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

2018-01-24 Thread Matt Burgess (JIRA)

 [ 
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

2018-01-24 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-01-24 Thread ASF GitHub Bot (JIRA)

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

2018-01-24 Thread mattyb149
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...

2018-01-24 Thread mattyb149
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

2018-01-24 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-01-24 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-01-24 Thread pvillard31
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

2018-01-24 Thread Pierre Villard (JIRA)

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

2018-01-24 Thread pvillard31
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

2018-01-24 Thread ASF GitHub Bot (JIRA)

[ 
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 Villard 
Date:   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...

2018-01-24 Thread pvillard31
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 Villard 
Date:   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

2018-01-24 Thread Pierre Villard (JIRA)
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

2018-01-24 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-01-24 Thread pvillard31
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

2018-01-24 Thread ASF GitHub Bot (JIRA)

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

2018-01-24 Thread mgaido91
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

2018-01-24 Thread ASF GitHub Bot (JIRA)

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

2018-01-24 Thread mgaido91
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

2018-01-24 Thread ASF GitHub Bot (JIRA)

[ 
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 Map getAllProperties() {
+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...

2018-01-24 Thread mgaido91
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 Map getAllProperties() {
+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

2018-01-24 Thread mgaido91
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

2018-01-24 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-01-24 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-01-24 Thread pvillard31
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)

2018-01-24 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-01-24 Thread mgaido91
Github user mgaido91 commented on the issue:

https://github.com/apache/nifi/pull/2294
  
LGTM


---


[jira] [Commented] (NIFI-3538) Add DeleteHBase processor(s)

2018-01-24 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-01-24 Thread MikeThomsen
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

2018-01-24 Thread ASF GitHub Bot (JIRA)

[ 
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.bugeja 
Date:   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

2018-01-24 Thread ASF GitHub Bot (JIRA)

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

2018-01-24 Thread SunSatION
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.bugeja 
Date:   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/...

2018-01-24 Thread SunSatION
Github user SunSatION closed the pull request at:

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


---


[jira] [Commented] (NIFI-3538) Add DeleteHBase processor(s)

2018-01-24 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-01-24 Thread MikeThomsen
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

2018-01-24 Thread Daniel Chaffelson (JIRA)

 [ 
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

2018-01-24 Thread Jon Kessler (JIRA)

 [ 
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

2018-01-24 Thread Jon Kessler (JIRA)
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

2018-01-24 Thread mgaido91
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)

2018-01-24 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-01-24 Thread Daniel Chaffelson (JIRA)

[ 
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)

2018-01-24 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-01-24 Thread Daniel Chaffelson (JIRA)

 [ 
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

2018-01-24 Thread MikeThomsen
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

2018-01-24 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-01-24 Thread mgaido91
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

2018-01-24 Thread ASF GitHub Bot (JIRA)

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

2018-01-24 Thread ijokarumawak
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

2018-01-24 Thread Daniel Chaffelson (JIRA)
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

2018-01-24 Thread ijokarumawak
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

2018-01-24 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-01-24 Thread Johan Oceanstorm (JIRA)
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

2018-01-24 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-01-24 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-01-24 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-01-24 Thread pvillard31
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

2018-01-24 Thread pvillard31
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

2018-01-24 Thread pvillard31
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.


---