date:20170825

[jira] [Commented] (NIFI-2528) Update ListenHTTP to honor SSLContextService Protocols

2017-08-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-2528:
--

Github user alopresto commented on the issue:

https://github.com/apache/nifi/pull/1986
  
Also, as @joewitt noted earlier, we should change the available interface 
for other "listener" processors. Here's a preliminary list I put together, but 
I would like confirmation from another member:
* `HandleHTTPRequest`
* `ListenBeats`
* 
`DistributedCacheServer`/`DistributedSetCacheServer`/`DistributedMapCacheServer`
* `ListenSMTP`
* `ListenGRPC`
* `ListenLumberjack` (*Deprecated*)
* `ListenRELP`
* `ListenSyslog`
* `ListenTCP`/`ListenTCPRecord`

Also:
* `AbstractSiteToSiteReportingTask`
* `org.apache.nifi.processors.slack.TestServer`
* `WebSocketService`/`JettyWebSocketService`



> Update ListenHTTP to honor SSLContextService Protocols
> --
>
> Key: NIFI-2528
> URL: https://issues.apache.org/jira/browse/NIFI-2528
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.8.0, 0.7.1
>Reporter: Joe Skora
>Assignee: Michael Hogue
>
> Update ListenHTTP to honor SSLContextService Protocols as [NIFI-1688] did for 
> PostHTTP.



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

[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...

2017-08-25 Thread alopresto

Github user alopresto commented on the issue:

https://github.com/apache/nifi/pull/1986
  
Also, as @joewitt noted earlier, we should change the available interface 
for other "listener" processors. Here's a preliminary list I put together, but 
I would like confirmation from another member:
* `HandleHTTPRequest`
* `ListenBeats`
* 
`DistributedCacheServer`/`DistributedSetCacheServer`/`DistributedMapCacheServer`
* `ListenSMTP`
* `ListenGRPC`
* `ListenLumberjack` (*Deprecated*)
* `ListenRELP`
* `ListenSyslog`
* `ListenTCP`/`ListenTCPRecord`

Also:
* `AbstractSiteToSiteReportingTask`
* `org.apache.nifi.processors.slack.TestServer`
* `WebSocketService`/`JettyWebSocketService`



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

[jira] [Commented] (NIFI-2528) Update ListenHTTP to honor SSLContextService Protocols

2017-08-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-2528:
--

Github user alopresto commented on the issue:

https://github.com/apache/nifi/pull/1986
  
Ok I left some minor comments on the code. If Michael can reply to those 
and make the changes, I think this is good and ready to be merged. I set up a 
flow with a `ListenHTTP` processor and verified that I could only provide it 
with a `StandardRestrictedSSLContextService` implementation. I verified that it 
received incoming requests (*only*) over TLS v1.2. 

```
hw12203:/Users/alopresto/Workspace/scratch (master) alopresto
🔓 27314s @ 18:11:29 $ openssl s_client -connect localhost: -debug 
-showcerts
CONNECTED(0003)
write to 0x7f80b0d89fd0 [0x7f80b1807e00] (308 bytes => 308 (0x134))
 - 16 03 01 01 2f 01 00 01-2b 03 03 29 cb d3 e6 54   /...+..)...T
...
0050 - 64 f9 0d 7b c4 03 6b 71-03 4d a4 1d 8a f7 4d 45   d..{..kq.MME
---
Certificate chain
 0 s:/OU=NIFI/CN=nifi.nifi.apache.org
   i:/OU=NIFI/CN=localhost
...
---
Server certificate
subject=/OU=NIFI/CN=nifi.nifi.apache.org
issuer=/OU=NIFI/CN=localhost
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2241 bytes and written 490 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-AES256-SHA384
Session-ID: 
59A0CAC680787984AD9B43E8A39BCFB0F4C5EA4F8AC10223C073296EDB8FB66B
Session-ID-ctx:
Master-Key: 
236BC9B03CD3F7B02C363C8DA15F36EA908A631DB0D3828A0CE05E3834D07BB58E9D1A7023A5161DCE13BF58029BCD61
Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1503709893
Timeout   : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
---
Q
DONE
hw12203:/Users/alopresto/Workspace/scratch (master) alopresto
🔓 27323s @ 18:11:38 $ openssl s_client -connect localhost: -debug 
-showcerts -tls1_1
CONNECTED(0003)
write to 0x7fd06181a060 [0x7fd06280f003] (200 bytes => 200 (0xC8))
 - 16 03 01 00 c3 01 00 00-bf 03 02 18 09 95 74 f0   ..t.
...   .(
140735215808592:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert 
handshake failure:s3_pkt.c:1494:SSL alert number 40
140735215808592:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake 
failure:s3_pkt.c:659:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.1
Cipher: 
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1503712071
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
---
hw12203:/Users/alopresto/Workspace/scratch (master) alopresto
🔓 29497s @ 18:47:53 $
```
I also set up two `InvokeHTTP` processors and used a 
`StandardSSLContextService` and `StandardRestrictedSSLContextService` for each. 
Both were able to successfully make outgoing `GET` requests to 
`https://nifi.apache.org`. 

Contrib-check and all tests pass. Just need Michael to respond to the few 
comments above. 


> Update ListenHTTP to honor SSLContextService Protocols
> --
>
> Key: NIFI-2528
> URL: https://issues.apache.org/jira/browse/NIFI-2528
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.8.0, 0.7.1
>Reporter: Joe Skora
>Assignee: Michael Hogue
>
> Update ListenHTTP to honor SSLContextService Protocols as [NIFI-1688] did for 
> PostHTTP.



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

[GitHub] nifi issue #1986: NIFI-2528: added support for SSLContextService protocols i...

2017-08-25 Thread alopresto

Github user alopresto commented on the issue:

https://github.com/apache/nifi/pull/1986
  
Ok I left some minor comments on the code. If Michael can reply to those 
and make the changes, I think this is good and ready to be merged. I set up a 
flow with a `ListenHTTP` processor and verified that I could only provide it 
with a `StandardRestrictedSSLContextService` implementation. I verified that it 
received incoming requests (*only*) over TLS v1.2. 

```
hw12203:/Users/alopresto/Workspace/scratch (master) alopresto
ð 27314s @ 18:11:29 $ openssl s_client -connect localhost: -debug 
-showcerts
CONNECTED(0003)
write to 0x7f80b0d89fd0 [0x7f80b1807e00] (308 bytes => 308 (0x134))
 - 16 03 01 01 2f 01 00 01-2b 03 03 29 cb d3 e6 54   /...+..)...T
...
0050 - 64 f9 0d 7b c4 03 6b 71-03 4d a4 1d 8a f7 4d 45   d..{..kq.MME
---
Certificate chain
 0 s:/OU=NIFI/CN=nifi.nifi.apache.org
   i:/OU=NIFI/CN=localhost
...
---
Server certificate
subject=/OU=NIFI/CN=nifi.nifi.apache.org
issuer=/OU=NIFI/CN=localhost
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2241 bytes and written 490 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-AES256-SHA384
Session-ID: 
59A0CAC680787984AD9B43E8A39BCFB0F4C5EA4F8AC10223C073296EDB8FB66B
Session-ID-ctx:
Master-Key: 
236BC9B03CD3F7B02C363C8DA15F36EA908A631DB0D3828A0CE05E3834D07BB58E9D1A7023A5161DCE13BF58029BCD61
Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1503709893
Timeout   : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
---
Q
DONE
hw12203:/Users/alopresto/Workspace/scratch (master) alopresto
ð 27323s @ 18:11:38 $ openssl s_client -connect localhost: -debug 
-showcerts -tls1_1
CONNECTED(0003)
write to 0x7fd06181a060 [0x7fd06280f003] (200 bytes => 200 (0xC8))
 - 16 03 01 00 c3 01 00 00-bf 03 02 18 09 95 74 f0   ..t.
...   .(
140735215808592:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert 
handshake failure:s3_pkt.c:1494:SSL alert number 40
140735215808592:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake 
failure:s3_pkt.c:659:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.1
Cipher: 
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1503712071
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
---
hw12203:/Users/alopresto/Workspace/scratch (master) alopresto
ð 29497s @ 18:47:53 $
```
I also set up two `InvokeHTTP` processors and used a 
`StandardSSLContextService` and `StandardRestrictedSSLContextService` for each. 
Both were able to successfully make outgoing `GET` requests to 
`https://nifi.apache.org`. 

Contrib-check and all tests pass. Just need Michael to respond to the few 
comments above. 


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

[jira] [Commented] (NIFI-2528) Update ListenHTTP to honor SSLContextService Protocols

2017-08-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-2528:
--

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

https://github.com/apache/nifi/pull/1986#discussion_r135371152
  
--- Diff: 
nifi-nar-bundles/nifi-standard-services/nifi-ssl-context-bundle/nifi-ssl-context-service/src/main/java/org/apache/nifi/ssl/StandardRestrictedSSLContextService.java
 ---
@@ -0,0 +1,81 @@
+/*
+ * 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.ssl;
+
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.List;
+
+import org.apache.nifi.annotation.documentation.CapabilityDescription;
+import org.apache.nifi.annotation.documentation.Tags;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.components.ValidationContext;
+import org.apache.nifi.processor.util.StandardValidators;
+
+/**
+ * This class is functionally the same as {@link 
StandardSSLContextService}, but it restricts the allowable
+ * values that can be selected for SSL protocols.
+ */
+@Tags({"ssl", "secure", "certificate", "keystore", "truststore", "jks", 
"p12", "pkcs12", "pkcs"})
+@CapabilityDescription("Restricted implementation of the 
SSLContextService. Provides the ability to configure "
++ "keystore and/or truststore properties once and reuse that 
configuration throughout the application, "
++ "but only allows a restricted set of SSL protocols to be chosen. 
The set of protocols selectable will "
++ "evolve over time as new protocols emerge and older protocols 
are deprecated. This service is recommended "
++ "over StandardSSLContextService if a component doesn't expect to 
communicate with legacy systems since it's "
++ "unlikely that legacy systems will support these protocols.")
+public class StandardRestrictedSSLContextService extends 
StandardSSLContextService implements RestrictedSSLContextService {
+
+public static final PropertyDescriptor RESTRICTED_SSL_ALGORITHM = new 
PropertyDescriptor.Builder()
+.name("SSL Protocol")
+.defaultValue("TLSv1.2")
--- End diff --

We should include `.displayName("TLS Protocol")` here for human-readable 
naming without conflicting with the legacy property descriptor name. 


> Update ListenHTTP to honor SSLContextService Protocols
> --
>
> Key: NIFI-2528
> URL: https://issues.apache.org/jira/browse/NIFI-2528
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.8.0, 0.7.1
>Reporter: Joe Skora
>Assignee: Michael Hogue
>
> Update ListenHTTP to honor SSLContextService Protocols as [NIFI-1688] did for 
> PostHTTP.



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

[GitHub] nifi pull request #1986: NIFI-2528: added support for SSLContextService prot...

2017-08-25 Thread alopresto

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

https://github.com/apache/nifi/pull/1986#discussion_r135371152
  
--- Diff: 
nifi-nar-bundles/nifi-standard-services/nifi-ssl-context-bundle/nifi-ssl-context-service/src/main/java/org/apache/nifi/ssl/StandardRestrictedSSLContextService.java
 ---
@@ -0,0 +1,81 @@
+/*
+ * 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.ssl;
+
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.List;
+
+import org.apache.nifi.annotation.documentation.CapabilityDescription;
+import org.apache.nifi.annotation.documentation.Tags;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.components.ValidationContext;
+import org.apache.nifi.processor.util.StandardValidators;
+
+/**
+ * This class is functionally the same as {@link 
StandardSSLContextService}, but it restricts the allowable
+ * values that can be selected for SSL protocols.
+ */
+@Tags({"ssl", "secure", "certificate", "keystore", "truststore", "jks", 
"p12", "pkcs12", "pkcs"})
+@CapabilityDescription("Restricted implementation of the 
SSLContextService. Provides the ability to configure "
++ "keystore and/or truststore properties once and reuse that 
configuration throughout the application, "
++ "but only allows a restricted set of SSL protocols to be chosen. 
The set of protocols selectable will "
++ "evolve over time as new protocols emerge and older protocols 
are deprecated. This service is recommended "
++ "over StandardSSLContextService if a component doesn't expect to 
communicate with legacy systems since it's "
++ "unlikely that legacy systems will support these protocols.")
+public class StandardRestrictedSSLContextService extends 
StandardSSLContextService implements RestrictedSSLContextService {
+
+public static final PropertyDescriptor RESTRICTED_SSL_ALGORITHM = new 
PropertyDescriptor.Builder()
+.name("SSL Protocol")
+.defaultValue("TLSv1.2")
--- End diff --

We should include `.displayName("TLS Protocol")` here for human-readable 
naming without conflicting with the legacy property descriptor name. 


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

[jira] [Commented] (NIFI-2528) Update ListenHTTP to honor SSLContextService Protocols

2017-08-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-2528:
--

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

https://github.com/apache/nifi/pull/1986#discussion_r135371045
  
--- Diff: 
nifi-nar-bundles/nifi-standard-services/nifi-ssl-context-bundle/nifi-ssl-context-service/src/main/java/org/apache/nifi/ssl/StandardRestrictedSSLContextService.java
 ---
@@ -0,0 +1,81 @@
+/*
+ * 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.ssl;
+
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.List;
+
+import org.apache.nifi.annotation.documentation.CapabilityDescription;
+import org.apache.nifi.annotation.documentation.Tags;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.components.ValidationContext;
+import org.apache.nifi.processor.util.StandardValidators;
+
+/**
+ * This class is functionally the same as {@link 
StandardSSLContextService}, but it restricts the allowable
--- End diff --

I think in the documentation, tags, and descriptions, *TLS* should be 
emphasized over *SSL*, as SSL is deprecated. I would not recommend changing the 
name of the class though. 


> Update ListenHTTP to honor SSLContextService Protocols
> --
>
> Key: NIFI-2528
> URL: https://issues.apache.org/jira/browse/NIFI-2528
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.8.0, 0.7.1
>Reporter: Joe Skora
>Assignee: Michael Hogue
>
> Update ListenHTTP to honor SSLContextService Protocols as [NIFI-1688] did for 
> PostHTTP.



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

[GitHub] nifi pull request #1986: NIFI-2528: added support for SSLContextService prot...

2017-08-25 Thread alopresto

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

https://github.com/apache/nifi/pull/1986#discussion_r135371045
  
--- Diff: 
nifi-nar-bundles/nifi-standard-services/nifi-ssl-context-bundle/nifi-ssl-context-service/src/main/java/org/apache/nifi/ssl/StandardRestrictedSSLContextService.java
 ---
@@ -0,0 +1,81 @@
+/*
+ * 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.ssl;
+
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.List;
+
+import org.apache.nifi.annotation.documentation.CapabilityDescription;
+import org.apache.nifi.annotation.documentation.Tags;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.components.ValidationContext;
+import org.apache.nifi.processor.util.StandardValidators;
+
+/**
+ * This class is functionally the same as {@link 
StandardSSLContextService}, but it restricts the allowable
--- End diff --

I think in the documentation, tags, and descriptions, *TLS* should be 
emphasized over *SSL*, as SSL is deprecated. I would not recommend changing the 
name of the class though. 


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

[jira] [Commented] (NIFI-2528) Update ListenHTTP to honor SSLContextService Protocols

2017-08-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-2528:
--

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

https://github.com/apache/nifi/pull/1986#discussion_r135370899
  
--- Diff: 
nifi-nar-bundles/nifi-standard-services/nifi-ssl-context-bundle/nifi-ssl-context-service/src/main/java/org/apache/nifi/ssl/SSLContextServiceUtils.java
 ---
@@ -0,0 +1,77 @@
+/*
+ * 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.ssl;
+
+import java.security.NoSuchAlgorithmException;
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Set;
+
+import javax.net.ssl.SSLContext;
+
+import org.apache.nifi.components.AllowableValue;
+
+public class SSLContextServiceUtils {
--- End diff --

Does this need to be a separate utility class? It seems to only have one 
method. I would have anticipated this method being added to the 
`SSLContextService` interface and then implemented by each of the concrete 
classes. Thus the logic would be encapsulated in the implementations rather 
than outside of the provided implementations. 


> Update ListenHTTP to honor SSLContextService Protocols
> --
>
> Key: NIFI-2528
> URL: https://issues.apache.org/jira/browse/NIFI-2528
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.8.0, 0.7.1
>Reporter: Joe Skora
>Assignee: Michael Hogue
>
> Update ListenHTTP to honor SSLContextService Protocols as [NIFI-1688] did for 
> PostHTTP.



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

[GitHub] nifi pull request #1986: NIFI-2528: added support for SSLContextService prot...

2017-08-25 Thread alopresto

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

https://github.com/apache/nifi/pull/1986#discussion_r135370899
  
--- Diff: 
nifi-nar-bundles/nifi-standard-services/nifi-ssl-context-bundle/nifi-ssl-context-service/src/main/java/org/apache/nifi/ssl/SSLContextServiceUtils.java
 ---
@@ -0,0 +1,77 @@
+/*
+ * 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.ssl;
+
+import java.security.NoSuchAlgorithmException;
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Set;
+
+import javax.net.ssl.SSLContext;
+
+import org.apache.nifi.components.AllowableValue;
+
+public class SSLContextServiceUtils {
--- End diff --

Does this need to be a separate utility class? It seems to only have one 
method. I would have anticipated this method being added to the 
`SSLContextService` interface and then implemented by each of the concrete 
classes. Thus the logic would be encapsulated in the implementations rather 
than outside of the provided implementations. 


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

[GitHub] nifi issue #2020: [NiFi-3973] Add PutKudu Processor for ingesting data to Ku...

2017-08-25 Thread cammachusa

Github user cammachusa commented on the issue:

https://github.com/apache/nifi/pull/2020
  
Thanks @rickysaltzer , I didn't mean to rush you :-) . It's just because I 
have to report to my boss, since it's the end of the sprint. It was nice 
working with you, and sure I will contribute more to the community.
Cheer!


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

[jira] [Commented] (NIFI-2528) Update ListenHTTP to honor SSLContextService Protocols

2017-08-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-2528:
--

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

https://github.com/apache/nifi/pull/1986#discussion_r135370201
  
--- Diff: 
nifi-nar-bundles/nifi-standard-services/nifi-ssl-context-bundle/nifi-ssl-context-service/src/main/java/org/apache/nifi/ssl/SSLContextServiceUtils.java
 ---
@@ -0,0 +1,77 @@
+/*
+ * 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.ssl;
+
+import java.security.NoSuchAlgorithmException;
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Set;
+
+import javax.net.ssl.SSLContext;
+
+import org.apache.nifi.components.AllowableValue;
+
+public class SSLContextServiceUtils {
+
+/**
+ * Build a set of allowable SSL protocol algorithms based on JVM 
configuration and whether
+ * or not the list should be restricted to include only certain 
protocols.
+ *
+ * @param restricted whether the set of allowable protocol values 
should be restricted.
+ *
+ * @return the computed set of allowable values
+ */
+public static AllowableValue[] buildSSLAlgorithmAllowableValues(final 
boolean restricted) {
+final Set supportedProtocols = new HashSet<>();
+
+// if restricted, only allow the below set of protocols.
+if(restricted) {
+supportedProtocols.add("TLSv1.2");
--- End diff --

I know having `{TLS, TLSv1.2}` may look ambiguous or confusing in the 
restricted set, but I think including `TLS` is good here because when 
[TLSv1.3](https://blog.cloudflare.com/introducing-tls-1-3/) (see also 
[2](https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/) 
[3](https://kinsta.com/blog/tls-1-3/)) and so on are supported, users won't 
have to revisit this and explicitly enable/upgrade to that protocol version. We 
should improve the `TLS` tooltip to explain that it chooses the highest 
supported TLS protocol version automatically, and perhaps identify the minimum 
supported version. 


> Update ListenHTTP to honor SSLContextService Protocols
> --
>
> Key: NIFI-2528
> URL: https://issues.apache.org/jira/browse/NIFI-2528
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.8.0, 0.7.1
>Reporter: Joe Skora
>Assignee: Michael Hogue
>
> Update ListenHTTP to honor SSLContextService Protocols as [NIFI-1688] did for 
> PostHTTP.



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

[GitHub] nifi pull request #1986: NIFI-2528: added support for SSLContextService prot...

2017-08-25 Thread alopresto

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

https://github.com/apache/nifi/pull/1986#discussion_r135370201
  
--- Diff: 
nifi-nar-bundles/nifi-standard-services/nifi-ssl-context-bundle/nifi-ssl-context-service/src/main/java/org/apache/nifi/ssl/SSLContextServiceUtils.java
 ---
@@ -0,0 +1,77 @@
+/*
+ * 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.ssl;
+
+import java.security.NoSuchAlgorithmException;
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Set;
+
+import javax.net.ssl.SSLContext;
+
+import org.apache.nifi.components.AllowableValue;
+
+public class SSLContextServiceUtils {
+
+/**
+ * Build a set of allowable SSL protocol algorithms based on JVM 
configuration and whether
+ * or not the list should be restricted to include only certain 
protocols.
+ *
+ * @param restricted whether the set of allowable protocol values 
should be restricted.
+ *
+ * @return the computed set of allowable values
+ */
+public static AllowableValue[] buildSSLAlgorithmAllowableValues(final 
boolean restricted) {
+final Set supportedProtocols = new HashSet<>();
+
+// if restricted, only allow the below set of protocols.
+if(restricted) {
+supportedProtocols.add("TLSv1.2");
--- End diff --

I know having `{TLS, TLSv1.2}` may look ambiguous or confusing in the 
restricted set, but I think including `TLS` is good here because when 
[TLSv1.3](https://blog.cloudflare.com/introducing-tls-1-3/) (see also 
[2](https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/) 
[3](https://kinsta.com/blog/tls-1-3/)) and so on are supported, users won't 
have to revisit this and explicitly enable/upgrade to that protocol version. We 
should improve the `TLS` tooltip to explain that it chooses the highest 
supported TLS protocol version automatically, and perhaps identify the minimum 
supported version. 


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

[GitHub] nifi issue #2085: NIFI-4246 - Client Credentials Grant based OAuth2 Controll...

2017-08-25 Thread alopresto

Github user alopresto commented on the issue:

https://github.com/apache/nifi/pull/2085
  
Hi @jdye64 -- do you have a specific service you used for testing this?


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

[jira] [Commented] (NIFI-4246) OAuth 2 Authorization support - Client Credentials Grant

2017-08-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-4246:
--

Github user alopresto commented on the issue:

https://github.com/apache/nifi/pull/2085
  
Hi @jdye64 -- do you have a specific service you used for testing this?


> OAuth 2 Authorization support - Client Credentials Grant
> 
>
> Key: NIFI-4246
> URL: https://issues.apache.org/jira/browse/NIFI-4246
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Jeremy Dyer
>Assignee: Jeremy Dyer
>
> If your interacting with REST endpoints on the web chances are you are going 
> to run into an OAuth2 secured webservice. The IETF (Internet Engineering Task 
> Force) defines 4 methods in which OAuth2 authorization can occur. This JIRA 
> is focused solely on the Client Credentials Grant method defined at 
> https://tools.ietf.org/html/rfc6749#section-4.4
> This implementation should provide a ControllerService in which the enduser 
> can configure the credentials for obtaining the authorization grant (access 
> token) from the resource owner. In turn a new property will be added to the 
> InvokeHTTP processor (if it doesn't already exist from one of the other JIRA 
> efforts similar to this one) where the processor can reference this 
> controller service to obtain the access token and insert the appropriate HTTP 
> header (Authorization: Bearer{access_token}) so that the InvokeHTTP processor 
> can interact with the OAuth protected resources without having to worry about 
> setting up the credentials for each InvokeHTTP processor saving time and 
> complexity.



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

[jira] [Commented] (NIFI-4324) UI - Context Menu Issue

2017-08-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-4324:
--

Github user scottyaslan commented on the issue:

https://github.com/apache/nifi/pull/2109
  
Thanks @mcgilman this has been merged to master.


> UI - Context Menu Issue
> ---
>
> Key: NIFI-4324
> URL: https://issues.apache.org/jira/browse/NIFI-4324
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.4.0
>
>
> If an item in the context menu is a group-item, the sub menu may not trigger 
> when 'mouseenter'-ing the item from outside the context menu. This is most 
> noticeable when the first menu item is a group-item. It appears the menu item 
> 'mouseenter' event is not triggering. If the cursor is already in the context 
> menu (ie when the group-item is second in the list for instance) the event 
> triggers as expected.
> Root cause of the issue is that when the context menu is hidden, sub menu's 
> are hidden instead of removed. So the sub menu works correctly on the first 
> attempt but any subsequent attempts will fail because the sub menu is already 
> part of the DOM. Proper removal will allow the sub menu to be created 
> correctly.



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

[jira] [Commented] (NIFI-4324) UI - Context Menu Issue

2017-08-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-4324:
--

Github user asfgit closed the pull request at:

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


> UI - Context Menu Issue
> ---
>
> Key: NIFI-4324
> URL: https://issues.apache.org/jira/browse/NIFI-4324
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.4.0
>
>
> If an item in the context menu is a group-item, the sub menu may not trigger 
> when 'mouseenter'-ing the item from outside the context menu. This is most 
> noticeable when the first menu item is a group-item. It appears the menu item 
> 'mouseenter' event is not triggering. If the cursor is already in the context 
> menu (ie when the group-item is second in the list for instance) the event 
> triggers as expected.
> Root cause of the issue is that when the context menu is hidden, sub menu's 
> are hidden instead of removed. So the sub menu works correctly on the first 
> attempt but any subsequent attempts will fail because the sub menu is already 
> part of the DOM. Proper removal will allow the sub menu to be created 
> correctly.



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

[jira] [Commented] (NIFI-4324) UI - Context Menu Issue

2017-08-25 Thread ASF subversion and git services (JIRA)


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

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

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

NIFI-4324:
- Ensuring that sub context menus are removed when hiding to ensure they are 
correctly (re)created during mouseenter events.

Signed-off-by: Scott Aslan 

This closes #2109


> UI - Context Menu Issue
> ---
>
> Key: NIFI-4324
> URL: https://issues.apache.org/jira/browse/NIFI-4324
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.4.0
>
>
> If an item in the context menu is a group-item, the sub menu may not trigger 
> when 'mouseenter'-ing the item from outside the context menu. This is most 
> noticeable when the first menu item is a group-item. It appears the menu item 
> 'mouseenter' event is not triggering. If the cursor is already in the context 
> menu (ie when the group-item is second in the list for instance) the event 
> triggers as expected.
> Root cause of the issue is that when the context menu is hidden, sub menu's 
> are hidden instead of removed. So the sub menu works correctly on the first 
> attempt but any subsequent attempts will fail because the sub menu is already 
> part of the DOM. Proper removal will allow the sub menu to be created 
> correctly.



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

[GitHub] nifi issue #2109: NIFI-4324: Addressing sub context menu issue

2017-08-25 Thread scottyaslan

Github user scottyaslan commented on the issue:

https://github.com/apache/nifi/pull/2109
  
Thanks @mcgilman this has been merged to master.


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

[jira] [Updated] (NIFI-4324) UI - Context Menu Issue

2017-08-25 Thread Scott Aslan (JIRA)


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

Scott Aslan updated NIFI-4324:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> UI - Context Menu Issue
> ---
>
> Key: NIFI-4324
> URL: https://issues.apache.org/jira/browse/NIFI-4324
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.4.0
>
>
> If an item in the context menu is a group-item, the sub menu may not trigger 
> when 'mouseenter'-ing the item from outside the context menu. This is most 
> noticeable when the first menu item is a group-item. It appears the menu item 
> 'mouseenter' event is not triggering. If the cursor is already in the context 
> menu (ie when the group-item is second in the list for instance) the event 
> triggers as expected.
> Root cause of the issue is that when the context menu is hidden, sub menu's 
> are hidden instead of removed. So the sub menu works correctly on the first 
> attempt but any subsequent attempts will fail because the sub menu is already 
> part of the DOM. Proper removal will allow the sub menu to be created 
> correctly.



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

[GitHub] nifi pull request #2109: NIFI-4324: Addressing sub context menu issue

2017-08-25 Thread asfgit

Github user asfgit closed the pull request at:

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


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

[GitHub] nifi-minifi-cpp pull request #132: MINIFI-389 Added support for one-way TLS ...

2017-08-25 Thread achristianson

GitHub user achristianson opened a pull request:

https://github.com/apache/nifi-minifi-cpp/pull/132

MINIFI-389 Added support for one-way TLS to SSLContextService

### 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 MINIFI- 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] 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)?
- [x] If applicable, have you updated the LICENSE file?
- [x] If applicable, have you updated the NOTICE file?

### For documentation related changes:
- [x] 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/achristianson/nifi-minifi-cpp MINIFI-389

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

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


commit bee59e723c446a6ac15be085c51798923e93d8e1
Author: Andrew I. Christianson 
Date:   2017-08-25T20:24:12Z

MINIFI-389 Added support for one-way TLS to SSLContextService




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

[GitHub] nifi pull request #2111: Update ExtractEmailHeaders.java

2017-08-25 Thread btwood

GitHub user btwood opened a pull request:

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

Update ExtractEmailHeaders.java

Resolve a null pointer exception when there is no recipient available in a 
TO, CC, or BCC header field.

No JIRA, although I did pull and build and test this change. It fixes the 
previously broken case.

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

$ git pull https://github.com/btwood/nifi patch-1

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

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


commit afec1a35d9c36a4fc35f3a23d7c781c3853ba9a7
Author: btwood <4839861+btw...@users.noreply.github.com>
Date:   2017-08-25T20:37:50Z

Update ExtractEmailHeaders.java

Resolve a null pointer exception when there is no recipient available in a 
TO, CC, or BCC header field.




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

[jira] [Updated] (NIFI-4116) LookupService should allow inserting fields at the root level

2017-08-25 Thread Mark Payne (JIRA)


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

Mark Payne updated NIFI-4116:
-
 Assignee: Mark Payne
Fix Version/s: 1.4.0
   Status: Patch Available  (was: Open)

> LookupService should allow inserting fields at the root level
> -
>
> Key: NIFI-4116
> URL: https://issues.apache.org/jira/browse/NIFI-4116
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Joseph Percivall
>Assignee: Mark Payne
> Fix For: 1.4.0
>
>
> As a user I want to enrich a document with fields from a LookupService and 
> insert the key/values at the root level. Currently the LookupRecord processor 
> requires a value for "Result RecordPath" in order to use it as an enrichment 
> processor (thus not allowing inserting at the root level).
> There should be a way to choose to insert at the root level of the record



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

[jira] [Commented] (NIFI-4116) LookupService should allow inserting fields at the root level

2017-08-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-4116:
--

GitHub user markap14 opened a pull request:

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

NIFI-4116: Allow fields of Record returned from Lookup Service to be …

…placed into record in the input, instead of requiring that the 'wrapper 
record' returned from Lookup be included

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/markap14/nifi NIFI-4116

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

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


commit 46b2c22a6f059881793412d65fd6f0c9df989224
Author: Mark Payne 
Date:   2017-08-25T20:22:43Z

NIFI-4116: Allow fields of Record returned from Lookup Service to be placed 
into record in the input, instead of requiring that the 'wrapper record' 
returned from Lookup be included




> LookupService should allow inserting fields at the root level
> -
>
> Key: NIFI-4116
> URL: https://issues.apache.org/jira/browse/NIFI-4116
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Joseph Percivall
>
> As a user I want to enrich a document with fields from a LookupService and 
> insert the key/values at the root level. Currently the LookupRecord processor 
> requires a value for "Result RecordPath" in order to use it as an enrichment 
> processor (thus not allowing inserting at the root level).
> There should be a way to choose to insert at the root level of the record



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

[GitHub] nifi pull request #2110: NIFI-4116: Allow fields of Record returned from Loo...

2017-08-25 Thread markap14

GitHub user markap14 opened a pull request:

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

NIFI-4116: Allow fields of Record returned from Lookup Service to be â¦

â¦placed into record in the input, instead of requiring that the 'wrapper 
record' returned from Lookup be included

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/markap14/nifi NIFI-4116

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

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


commit 46b2c22a6f059881793412d65fd6f0c9df989224
Author: Mark Payne 
Date:   2017-08-25T20:22:43Z

NIFI-4116: Allow fields of Record returned from Lookup Service to be placed 
into record in the input, instead of requiring that the 'wrapper record' 
returned from Lookup be included




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

[jira] [Updated] (NIFI-4324) UI - Context Menu Issue

2017-08-25 Thread Matt Gilman (JIRA)


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

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

> UI - Context Menu Issue
> ---
>
> Key: NIFI-4324
> URL: https://issues.apache.org/jira/browse/NIFI-4324
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.4.0
>
>
> If an item in the context menu is a group-item, the sub menu may not trigger 
> when 'mouseenter'-ing the item from outside the context menu. This is most 
> noticeable when the first menu item is a group-item. It appears the menu item 
> 'mouseenter' event is not triggering. If the cursor is already in the context 
> menu (ie when the group-item is second in the list for instance) the event 
> triggers as expected.
> Root cause of the issue is that when the context menu is hidden, sub menu's 
> are hidden instead of removed. So the sub menu works correctly on the first 
> attempt but any subsequent attempts will fail because the sub menu is already 
> part of the DOM. Proper removal will allow the sub menu to be created 
> correctly.



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

[jira] [Commented] (NIFI-4324) UI - Context Menu Issue

2017-08-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-4324:
--

GitHub user mcgilman opened a pull request:

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

NIFI-4324: Addressing sub context menu issue

NIFI-4324:
- Ensuring that sub context menus are removed when hiding to ensure they 
are correctly (re)created during mouseenter events.

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

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

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

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


commit d5181e3554dcd173ef7ba8ed2368bbd8d272ab0d
Author: Matt Gilman 
Date:   2017-08-25T20:08:34Z

NIFI-4324:
- Ensuring that sub context menus are removed when hiding to ensure they 
are correctly (re)created during mouseenter events.




> UI - Context Menu Issue
> ---
>
> Key: NIFI-4324
> URL: https://issues.apache.org/jira/browse/NIFI-4324
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.4.0
>
>
> If an item in the context menu is a group-item, the sub menu may not trigger 
> when 'mouseenter'-ing the item from outside the context menu. This is most 
> noticeable when the first menu item is a group-item. It appears the menu item 
> 'mouseenter' event is not triggering. If the cursor is already in the context 
> menu (ie when the group-item is second in the list for instance) the event 
> triggers as expected.
> Root cause of the issue is that when the context menu is hidden, sub menu's 
> are hidden instead of removed. So the sub menu works correctly on the first 
> attempt but any subsequent attempts will fail because the sub menu is already 
> part of the DOM. Proper removal will allow the sub menu to be created 
> correctly.



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

[GitHub] nifi pull request #2109: NIFI-4324: Addressing sub context menu issue

2017-08-25 Thread mcgilman

GitHub user mcgilman opened a pull request:

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

NIFI-4324: Addressing sub context menu issue

NIFI-4324:
- Ensuring that sub context menus are removed when hiding to ensure they 
are correctly (re)created during mouseenter events.

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

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

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

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


commit d5181e3554dcd173ef7ba8ed2368bbd8d272ab0d
Author: Matt Gilman 
Date:   2017-08-25T20:08:34Z

NIFI-4324:
- Ensuring that sub context menus are removed when hiding to ensure they 
are correctly (re)created during mouseenter events.




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

[jira] [Updated] (NIFI-4324) UI - Context Menu Issue

2017-08-25 Thread Matt Gilman (JIRA)


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

Matt Gilman updated NIFI-4324:
--
Description: 
If an item in the context menu is a group-item, the sub menu may not trigger 
when 'mouseenter'-ing the item from outside the context menu. This is most 
noticeable when the first menu item is a group-item. It appears the menu item 
'mouseenter' event is not triggering. If the cursor is already in the context 
menu (ie when the group-item is second in the list for instance) the event 
triggers as expected.

Root cause of the issue is that when the context menu is hidden, sub menu's are 
hidden instead of removed. So the sub menu works correctly on the first attempt 
but any subsequent attempts will fail because the sub menu is already part of 
the DOM. Proper removal will allow the sub menu to be created correctly.

  was:If an item in the context menu is a group-item, the sub menu may not 
trigger when 'mouseenter'-ing the item from outside the context menu. This is 
most noticeable when the first menu item is a group-item. It appears the menu 
item 'mouseenter' event is not triggering. If the cursor is already in the 
context menu (ie when the group-item is second in the list for instance) the 
event triggers as expected.


> UI - Context Menu Issue
> ---
>
> Key: NIFI-4324
> URL: https://issues.apache.org/jira/browse/NIFI-4324
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.4.0
>
>
> If an item in the context menu is a group-item, the sub menu may not trigger 
> when 'mouseenter'-ing the item from outside the context menu. This is most 
> noticeable when the first menu item is a group-item. It appears the menu item 
> 'mouseenter' event is not triggering. If the cursor is already in the context 
> menu (ie when the group-item is second in the list for instance) the event 
> triggers as expected.
> Root cause of the issue is that when the context menu is hidden, sub menu's 
> are hidden instead of removed. So the sub menu works correctly on the first 
> attempt but any subsequent attempts will fail because the sub menu is already 
> part of the DOM. Proper removal will allow the sub menu to be created 
> correctly.



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

[jira] [Commented] (NIFI-4324) UI - Context Menu Issue

2017-08-25 Thread Matt Gilman (JIRA)


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

Matt Gilman commented on NIFI-4324:
---

This bug was introduced in NIFI-3232 and should be resolved prior to it's 
release.

> UI - Context Menu Issue
> ---
>
> Key: NIFI-4324
> URL: https://issues.apache.org/jira/browse/NIFI-4324
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.4.0
>
>
> If an item in the context menu is a group-item, the sub menu may not trigger 
> when 'mouseenter'-ing the item from outside the context menu. This is most 
> noticeable when the first menu item is a group-item. It appears the menu item 
> 'mouseenter' event is not triggering. If the cursor is already in the context 
> menu (ie when the group-item is second in the list for instance) the event 
> triggers as expected.



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

[jira] [Updated] (NIFI-4324) UI - Context Menu Issue

2017-08-25 Thread Matt Gilman (JIRA)


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

Matt Gilman updated NIFI-4324:
--
Fix Version/s: 1.4.0

> UI - Context Menu Issue
> ---
>
> Key: NIFI-4324
> URL: https://issues.apache.org/jira/browse/NIFI-4324
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.4.0
>
>
> If an item in the context menu is a group-item, the sub menu may not trigger 
> when 'mouseenter'-ing the item from outside the context menu. This is most 
> noticeable when the first menu item is a group-item. It appears the menu item 
> 'mouseenter' event is not triggering. If the cursor is already in the context 
> menu (ie when the group-item is second in the list for instance) the event 
> triggers as expected.



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

[jira] [Assigned] (NIFI-4324) UI - Context Menu Issue

2017-08-25 Thread Matt Gilman (JIRA)


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

Matt Gilman reassigned NIFI-4324:
-

Assignee: Matt Gilman

> UI - Context Menu Issue
> ---
>
> Key: NIFI-4324
> URL: https://issues.apache.org/jira/browse/NIFI-4324
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.4.0
>
>
> If an item in the context menu is a group-item, the sub menu may not trigger 
> when 'mouseenter'-ing the item from outside the context menu. This is most 
> noticeable when the first menu item is a group-item. It appears the menu item 
> 'mouseenter' event is not triggering. If the cursor is already in the context 
> menu (ie when the group-item is second in the list for instance) the event 
> triggers as expected.



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

[jira] [Created] (NIFI-4324) UI - Context Menu Issue

2017-08-25 Thread Matt Gilman (JIRA)

Matt Gilman created NIFI-4324:
-

 Summary: UI - Context Menu Issue
 Key: NIFI-4324
 URL: https://issues.apache.org/jira/browse/NIFI-4324
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core UI
Reporter: Matt Gilman


If an item in the context menu is a group-item, the sub menu may not trigger 
when 'mouseenter'-ing the item from outside the context menu. This is most 
noticeable when the first menu item is a group-item. It appears the menu item 
'mouseenter' event is not triggering. If the cursor is already in the context 
menu (ie when the group-item is second in the list for instance) the event 
triggers as expected.



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

[jira] [Commented] (NIFI-3116) Remove Jasypt library

2017-08-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-3116:
--

Github user alopresto commented on the issue:

https://github.com/apache/nifi/pull/2108
  
You should see output like this when running the commands above:

```


hw12203:...assembly/target/nifi-toolkit-1.4.0-SNAPSHOT-bin/nifi-toolkit-1.4.0-SNAPSHOT
 (NIFI-3116) alopresto
🔓 266782s @ 12:05:17 $ ./bin/encrypt-config.sh -n 
../../../../../nifi-assembly/target/nifi-1.4.0-SNAPSHOT-bin/nifi-1.4.0-SNAPSHOT/conf/nifi.properties
 -f ~/Workspace/scratch/encrypt.xml.gz -g 
~/Workspace/scratch/encrypt_changed.xml.gz -v -x -s newpassword
2017/08/25 12:08:05 WARN [main] 
org.apache.nifi.properties.ConfigEncryptionTool: The source nifi.properties and 
destination nifi.properties are identical 
[../../../../../nifi-assembly/target/nifi-1.4.0-SNAPSHOT-bin/nifi-1.4.0-SNAPSHOT/conf/nifi.properties]
 so the original will be overwritten
2017/08/25 12:08:05 INFO [main] 
org.apache.nifi.properties.ConfigEncryptionTool: Handling encryption of 
flow.xml.gz
2017/08/25 12:08:05 INFO [main] 
org.apache.nifi.properties.ConfigEncryptionTool:bootstrap.conf: 
null
2017/08/25 12:08:05 INFO [main] 
org.apache.nifi.properties.ConfigEncryptionTool: (src)  nifi.properties:

../../../../../nifi-assembly/target/nifi-1.4.0-SNAPSHOT-bin/nifi-1.4.0-SNAPSHOT/conf/nifi.properties
2017/08/25 12:08:05 INFO [main] 
org.apache.nifi.properties.ConfigEncryptionTool: (dest) nifi.properties:

../../../../../nifi-assembly/target/nifi-1.4.0-SNAPSHOT-bin/nifi-1.4.0-SNAPSHOT/conf/nifi.properties
2017/08/25 12:08:05 INFO [main] 
org.apache.nifi.properties.ConfigEncryptionTool: (src)  
login-identity-providers.xml:   null
2017/08/25 12:08:05 INFO [main] 
org.apache.nifi.properties.ConfigEncryptionTool: (dest) 
login-identity-providers.xml:   null
2017/08/25 12:08:05 INFO [main] 
org.apache.nifi.properties.ConfigEncryptionTool: (src)  flow.xml.gz:
/Users/alopresto/Workspace/scratch/encrypt.xml.gz
2017/08/25 12:08:05 INFO [main] 
org.apache.nifi.properties.ConfigEncryptionTool: (dest) flow.xml.gz:

/Users/alopresto/Workspace/scratch/encrypt_changed.xml.gz
2017/08/25 12:08:05 INFO [main] 
org.apache.nifi.properties.NiFiPropertiesLoader: Loaded 135 properties from 
/Users/alopresto/Workspace/nifi/nifi-toolkit/nifi-toolkit-assembly/target/nifi-toolkit-1.4.0-SNAPSHOT-bin/nifi-toolkit-1.4.0-SNAPSHOT/../../../../../nifi-assembly/target/nifi-1.4.0-SNAPSHOT-bin/nifi-1.4.0-SNAPSHOT/conf/nifi.properties
2017/08/25 12:08:05 INFO [main] 
org.apache.nifi.properties.NiFiPropertiesLoader: Loaded 135 properties from 
/Users/alopresto/Workspace/nifi/nifi-toolkit/nifi-toolkit-assembly/target/nifi-toolkit-1.4.0-SNAPSHOT-bin/nifi-toolkit-1.4.0-SNAPSHOT/../../../../../nifi-assembly/target/nifi-1.4.0-SNAPSHOT-bin/nifi-1.4.0-SNAPSHOT/conf/nifi.properties
2017/08/25 12:08:05 INFO [main] 
org.apache.nifi.properties.ConfigEncryptionTool: Loaded NiFiProperties instance 
with 135 properties
2017/08/25 12:08:06 INFO [main] 
org.apache.nifi.properties.ConfigEncryptionTool: Decrypted and re-encrypted 4 
elements for flow.xml.gz

hw12203:...assembly/target/nifi-toolkit-1.4.0-SNAPSHOT-bin/nifi-toolkit-1.4.0-SNAPSHOT
 (NIFI-3116) alopresto
🔓 266952s @ 12:08:07 $


hw12203:...space/nifi/nifi-assembly/target/nifi-1.4.0-SNAPSHOT-bin/nifi-1.4.0-SNAPSHOT
 (NIFI-3116) alopresto
🔓 266344s @ 11:57:59 $ cp conf/flow.xml.gz 
~/Workspace/scratch/encrypt.xml.gz

hw12203:...space/nifi/nifi-assembly/target/nifi-1.4.0-SNAPSHOT-bin/nifi-1.4.0-SNAPSHOT
 (NIFI-3116) alopresto
🔓 266371s @ 11:58:27 $ cp ~/Workspace/scratch/encrypt_changed.xml.gz 
conf/flow.xml.gz

hw12203:...space/nifi/nifi-assembly/target/nifi-1.4.0-SNAPSHOT-bin/nifi-1.4.0-SNAPSHOT
 (NIFI-3116) alopresto
🔓 267004s @ 12:08:59 $ npw
nifi.provenance.repository.encryption.key.provider.implementation=
nifi.provenance.repository.encryption.key.provider.location=
nifi.provenance.repository.encryption.key.id=
nifi.provenance.repository.encryption.key=
nifi.sensitive.props.key=newpassword
nifi.sensitive.props.key.protected=
nifi.sensitive.props.algorithm=PBEWITHMD5AND256BITAES-CBC-OPENSSL
nifi.sensitive.props.provider=BC
nifi.sensitive.props.additional.keys=
nifi.security.keystore=
nifi.security.keystoreType=
nifi.security.keystorePasswd=
nifi.security.keyPasswd=
nifi.security.truststore=
nifi.security.truststoreType=
nifi.security.truststorePasswd=
nifi.kerberos.service.keytab.location=
nifi.kerberos.spnego.keytab.location=

hw12203:...space/nifi/nifi-assembly/target/

[GitHub] nifi issue #2108: NIFI-3116 Remove Jasypt

2017-08-25 Thread alopresto

Github user alopresto commented on the issue:

https://github.com/apache/nifi/pull/2108
  
You should see output like this when running the commands above:

```


hw12203:...assembly/target/nifi-toolkit-1.4.0-SNAPSHOT-bin/nifi-toolkit-1.4.0-SNAPSHOT
 (NIFI-3116) alopresto
ð 266782s @ 12:05:17 $ ./bin/encrypt-config.sh -n 
../../../../../nifi-assembly/target/nifi-1.4.0-SNAPSHOT-bin/nifi-1.4.0-SNAPSHOT/conf/nifi.properties
 -f ~/Workspace/scratch/encrypt.xml.gz -g 
~/Workspace/scratch/encrypt_changed.xml.gz -v -x -s newpassword
2017/08/25 12:08:05 WARN [main] 
org.apache.nifi.properties.ConfigEncryptionTool: The source nifi.properties and 
destination nifi.properties are identical 
[../../../../../nifi-assembly/target/nifi-1.4.0-SNAPSHOT-bin/nifi-1.4.0-SNAPSHOT/conf/nifi.properties]
 so the original will be overwritten
2017/08/25 12:08:05 INFO [main] 
org.apache.nifi.properties.ConfigEncryptionTool: Handling encryption of 
flow.xml.gz
2017/08/25 12:08:05 INFO [main] 
org.apache.nifi.properties.ConfigEncryptionTool:bootstrap.conf: 
null
2017/08/25 12:08:05 INFO [main] 
org.apache.nifi.properties.ConfigEncryptionTool: (src)  nifi.properties:

../../../../../nifi-assembly/target/nifi-1.4.0-SNAPSHOT-bin/nifi-1.4.0-SNAPSHOT/conf/nifi.properties
2017/08/25 12:08:05 INFO [main] 
org.apache.nifi.properties.ConfigEncryptionTool: (dest) nifi.properties:

../../../../../nifi-assembly/target/nifi-1.4.0-SNAPSHOT-bin/nifi-1.4.0-SNAPSHOT/conf/nifi.properties
2017/08/25 12:08:05 INFO [main] 
org.apache.nifi.properties.ConfigEncryptionTool: (src)  
login-identity-providers.xml:   null
2017/08/25 12:08:05 INFO [main] 
org.apache.nifi.properties.ConfigEncryptionTool: (dest) 
login-identity-providers.xml:   null
2017/08/25 12:08:05 INFO [main] 
org.apache.nifi.properties.ConfigEncryptionTool: (src)  flow.xml.gz:
/Users/alopresto/Workspace/scratch/encrypt.xml.gz
2017/08/25 12:08:05 INFO [main] 
org.apache.nifi.properties.ConfigEncryptionTool: (dest) flow.xml.gz:

/Users/alopresto/Workspace/scratch/encrypt_changed.xml.gz
2017/08/25 12:08:05 INFO [main] 
org.apache.nifi.properties.NiFiPropertiesLoader: Loaded 135 properties from 
/Users/alopresto/Workspace/nifi/nifi-toolkit/nifi-toolkit-assembly/target/nifi-toolkit-1.4.0-SNAPSHOT-bin/nifi-toolkit-1.4.0-SNAPSHOT/../../../../../nifi-assembly/target/nifi-1.4.0-SNAPSHOT-bin/nifi-1.4.0-SNAPSHOT/conf/nifi.properties
2017/08/25 12:08:05 INFO [main] 
org.apache.nifi.properties.NiFiPropertiesLoader: Loaded 135 properties from 
/Users/alopresto/Workspace/nifi/nifi-toolkit/nifi-toolkit-assembly/target/nifi-toolkit-1.4.0-SNAPSHOT-bin/nifi-toolkit-1.4.0-SNAPSHOT/../../../../../nifi-assembly/target/nifi-1.4.0-SNAPSHOT-bin/nifi-1.4.0-SNAPSHOT/conf/nifi.properties
2017/08/25 12:08:05 INFO [main] 
org.apache.nifi.properties.ConfigEncryptionTool: Loaded NiFiProperties instance 
with 135 properties
2017/08/25 12:08:06 INFO [main] 
org.apache.nifi.properties.ConfigEncryptionTool: Decrypted and re-encrypted 4 
elements for flow.xml.gz

hw12203:...assembly/target/nifi-toolkit-1.4.0-SNAPSHOT-bin/nifi-toolkit-1.4.0-SNAPSHOT
 (NIFI-3116) alopresto
ð 266952s @ 12:08:07 $


hw12203:...space/nifi/nifi-assembly/target/nifi-1.4.0-SNAPSHOT-bin/nifi-1.4.0-SNAPSHOT
 (NIFI-3116) alopresto
ð 266344s @ 11:57:59 $ cp conf/flow.xml.gz 
~/Workspace/scratch/encrypt.xml.gz

hw12203:...space/nifi/nifi-assembly/target/nifi-1.4.0-SNAPSHOT-bin/nifi-1.4.0-SNAPSHOT
 (NIFI-3116) alopresto
ð 266371s @ 11:58:27 $ cp ~/Workspace/scratch/encrypt_changed.xml.gz 
conf/flow.xml.gz

hw12203:...space/nifi/nifi-assembly/target/nifi-1.4.0-SNAPSHOT-bin/nifi-1.4.0-SNAPSHOT
 (NIFI-3116) alopresto
ð 267004s @ 12:08:59 $ npw
nifi.provenance.repository.encryption.key.provider.implementation=
nifi.provenance.repository.encryption.key.provider.location=
nifi.provenance.repository.encryption.key.id=
nifi.provenance.repository.encryption.key=
nifi.sensitive.props.key=newpassword
nifi.sensitive.props.key.protected=
nifi.sensitive.props.algorithm=PBEWITHMD5AND256BITAES-CBC-OPENSSL
nifi.sensitive.props.provider=BC
nifi.sensitive.props.additional.keys=
nifi.security.keystore=
nifi.security.keystoreType=
nifi.security.keystorePasswd=
nifi.security.keyPasswd=
nifi.security.truststore=
nifi.security.truststoreType=
nifi.security.truststorePasswd=
nifi.kerberos.service.keytab.location=
nifi.kerberos.spnego.keytab.location=

hw12203:...space/nifi/nifi-assembly/target/nifi-1.4.0-SNAPSHOT-bin/nifi-1.4.0-SNAPSHOT
 (NIFI-3116) alopresto
ð 267009s @ 12:09:04 $
```


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project doe

[jira] [Commented] (NIFI-3116) Remove Jasypt library

2017-08-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-3116:
--

GitHub user alopresto opened a pull request:

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

NIFI-3116 Remove Jasypt

I removed the Jasypt library (still present w/ `test` scope for 
backwards-compatibility testing). I re-implemented the relevant logic using 
Java cryptographic primitives. This will make unit testing much easier, reduce 
our attack surface because we no longer depend on an un-maintained library, and 
allows for more reasonable security decisions that are not obfuscated by the 
library. 

I added unit tests (some ignored as I will build out additional 
functionality, but this is sufficient for removal of the library), but manual 
verification is important. To do this:

1. Create a flow with processors that store sensitive values (a sample flow 
[here](https://gist.github.com/alopresto/28e748358455e93bfc774556ba820b6e) 
encrypts and then decrypts text -- both components store a key value). 
1. Stop NiFi
1. Use the `encrypt-config` tool to migrate the `flow.xml.gz` to use a new 
`nifi.sensitive.props.key` (and be sure to update the value in 
`nifi.properties` as well). 
1. Note that the flow provided above already uses the `...key` 
*newpassword*, so enter something different if using that flow
1. This command is operating on a copied flow definition, be sure to 
point at your actual `flow.xml.gz`
```
./bin/encrypt-config.sh -n 
../../../../../nifi-assembly/target/nifi-1.4.0-SNAPSHOT-bin/nifi-1.4.0-SNAPSHOT/conf/nifi.properties
 -f ~/Workspace/scratch/encrypt.xml.gz -g 
~/Workspace/scratch/encrypt_changed.xml.gz -v -x -s newpassword
```
1. Verify that the `nifi.properties` file has a new 
`nifi.sensitive.props.key` value. `more conf/nifi.properties | grep 
'\''sensitive\|assw\|key\|trust'\''`
1. Start NiFi. 
1. Verify that the flow still works. 


-
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/alopresto/nifi NIFI-3116

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

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


commit 84c631c005269ad0b9297714f21e813169e7bfb1
Author: Andy LoPresto 
Date:   2017-08-15T19:33:19Z

NIFI-3116 Added initial regression test for StringEncryptor to ensure 
continued functionality during removal of Jasypt.

commit ae0c54178fd5d857947d0c06902e3e24a1f2efc0
Author: Andy LoPresto 
Date:   2017-08-16T17:10:15Z

NIFI-3116 Added external compatibility regression test for StringEncryptor 
to ensure continued functionality during removal of Jasypt.
Documents custom salt lengths and iteration counts for each encryption 
method.

commit 875d3d434b95bdd71503b9fc1fadee3a06decd64
Author: Andy LoPresto 
Date:   2017-08-16T17:56:04Z

NIFI-3116 C

[GitHub] nifi pull request #2108: NIFI-3116 Remove Jasypt

2017-08-25 Thread alopresto

GitHub user alopresto opened a pull request:

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

NIFI-3116 Remove Jasypt

I removed the Jasypt library (still present w/ `test` scope for 
backwards-compatibility testing). I re-implemented the relevant logic using 
Java cryptographic primitives. This will make unit testing much easier, reduce 
our attack surface because we no longer depend on an un-maintained library, and 
allows for more reasonable security decisions that are not obfuscated by the 
library. 

I added unit tests (some ignored as I will build out additional 
functionality, but this is sufficient for removal of the library), but manual 
verification is important. To do this:

1. Create a flow with processors that store sensitive values (a sample flow 
[here](https://gist.github.com/alopresto/28e748358455e93bfc774556ba820b6e) 
encrypts and then decrypts text -- both components store a key value). 
1. Stop NiFi
1. Use the `encrypt-config` tool to migrate the `flow.xml.gz` to use a new 
`nifi.sensitive.props.key` (and be sure to update the value in 
`nifi.properties` as well). 
1. Note that the flow provided above already uses the `...key` 
*newpassword*, so enter something different if using that flow
1. This command is operating on a copied flow definition, be sure to 
point at your actual `flow.xml.gz`
```
./bin/encrypt-config.sh -n 
../../../../../nifi-assembly/target/nifi-1.4.0-SNAPSHOT-bin/nifi-1.4.0-SNAPSHOT/conf/nifi.properties
 -f ~/Workspace/scratch/encrypt.xml.gz -g 
~/Workspace/scratch/encrypt_changed.xml.gz -v -x -s newpassword
```
1. Verify that the `nifi.properties` file has a new 
`nifi.sensitive.props.key` value. `more conf/nifi.properties | grep 
'\''sensitive\|assw\|key\|trust'\''`
1. Start NiFi. 
1. Verify that the flow still works. 


-
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/alopresto/nifi NIFI-3116

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

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


commit 84c631c005269ad0b9297714f21e813169e7bfb1
Author: Andy LoPresto 
Date:   2017-08-15T19:33:19Z

NIFI-3116 Added initial regression test for StringEncryptor to ensure 
continued functionality during removal of Jasypt.

commit ae0c54178fd5d857947d0c06902e3e24a1f2efc0
Author: Andy LoPresto 
Date:   2017-08-16T17:10:15Z

NIFI-3116 Added external compatibility regression test for StringEncryptor 
to ensure continued functionality during removal of Jasypt.
Documents custom salt lengths and iteration counts for each encryption 
method.

commit 875d3d434b95bdd71503b9fc1fadee3a06decd64
Author: Andy LoPresto 
Date:   2017-08-16T17:56:04Z

NIFI-3116 Cleaned up test.

commit 86f0921eee5ed6a5d31a714488278374ae22ac39
Author: Andy LoPresto 
Date:   2017-08-16T18:04:10Z

NIFI-3116 Added (ignored) failing tests for keyed encryption (Jasypt does 
not support keyed encryption).

commit 98163625b69a48482

[jira] [Resolved] (NIFIREG-11) Refactor Domain Model

2017-08-25 Thread Bryan Bende (JIRA)


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

Bryan Bende resolved NIFIREG-11.

Resolution: Fixed

> Refactor Domain Model
> -
>
> Key: NIFIREG-11
> URL: https://issues.apache.org/jira/browse/NIFIREG-11
> Project: NiFi Registry
>  Issue Type: Improvement
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Minor
> Fix For: 0.0.1
>
>
> We should create a separate object model for the provider API so that those 
> objects can be decoupled from the standard data model.



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

[jira] [Commented] (NIFIREG-11) Refactor Domain Model

2017-08-25 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFIREG-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16142050#comment-16142050
 ] 

ASF GitHub Bot commented on NIFIREG-11:
---

Github user asfgit closed the pull request at:

https://github.com/apache/nifi-registry/pull/6


> Refactor Domain Model
> -
>
> Key: NIFIREG-11
> URL: https://issues.apache.org/jira/browse/NIFIREG-11
> Project: NiFi Registry
>  Issue Type: Improvement
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Minor
> Fix For: 0.0.1
>
>
> We should create a separate object model for the provider API so that those 
> objects can be decoupled from the standard data model.



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

[GitHub] nifi-registry pull request #6: NIFIREG-11 Data model refactoring

2017-08-25 Thread asfgit

Github user asfgit closed the pull request at:

https://github.com/apache/nifi-registry/pull/6


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

[jira] [Commented] (NIFI-4310) Certain flow configurations are improperly identified as empty during flow election

2017-08-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-4310:
--

Github user YolandaMDavis commented on the issue:

https://github.com/apache/nifi/pull/2107
  
@markap14 thank you!


> Certain flow configurations are improperly identified as empty during flow 
> election
> ---
>
> Key: NIFI-4310
> URL: https://issues.apache.org/jira/browse/NIFI-4310
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.3.0
>Reporter: Yolanda M. Davis
>Assignee: Yolanda M. Davis
> Fix For: 1.4.0
>
>
> While testing a cluster containing nodes with two different flows on initial 
> startup, I discovered that one flow, with an empty root processor group but 
> containing reporting tasks, would lose a flow election against flows that 
> also had empty root processor groups yet with no reporting tasks or 
> controller tasks. This caused an issue downstream during startup where it 
> attempted to replace the non-empty flow with an empty flow on certain nodes, 
> which led to UninheritableFlowExceptions. Further investigation revealed that 
> during election there is a check to determine if the flow is empty however 
> the check does not account for the existence of a reporting task or 
> controller services. This should be repaired to ensure that flows are 
> properly identified as non-empty for election.



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

[GitHub] nifi issue #2107: NIFI-4310 - added changes to support detection of reportin...

2017-08-25 Thread YolandaMDavis

Github user YolandaMDavis commented on the issue:

https://github.com/apache/nifi/pull/2107
  
@markap14 thank you!


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

[jira] [Commented] (NIFIREG-11) Refactor Domain Model

2017-08-25 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFIREG-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16141977#comment-16141977
 ] 

ASF GitHub Bot commented on NIFIREG-11:
---

Github user kevdoran commented on the issue:

https://github.com/apache/nifi-registry/pull/6
  
@bbende - I'm good with those changes, that all makes sense from my 
perspective as well. Code still builds for me as well so all looks good on my 
end.


> Refactor Domain Model
> -
>
> Key: NIFIREG-11
> URL: https://issues.apache.org/jira/browse/NIFIREG-11
> Project: NiFi Registry
>  Issue Type: Improvement
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Minor
> Fix For: 0.0.1
>
>
> We should create a separate object model for the provider API so that those 
> objects can be decoupled from the standard data model.



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

[GitHub] nifi-registry issue #6: NIFIREG-11 Data model refactoring

2017-08-25 Thread kevdoran

Github user kevdoran commented on the issue:

https://github.com/apache/nifi-registry/pull/6
  
@bbende - I'm good with those changes, that all makes sense from my 
perspective as well. Code still builds for me as well so all looks good on my 
end.


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

[jira] [Commented] (NIFIREG-11) Refactor Domain Model

2017-08-25 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFIREG-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16141976#comment-16141976
 ] 

ASF GitHub Bot commented on NIFIREG-11:
---

Github user bbende commented on the issue:

https://github.com/apache/nifi-registry/pull/6
  
@kevdoran thanks for reviewing!

I pushed up another commit that changes the equals method you mentioned... 
I agree that as long as flow id's are globally unique, then we only need to use 
flow id + version for the hash/equals of the snapshot method.

Regarding using the metadata objects in the REST layer... I think we should 
still leave the REST end-points using the original data model, and the service 
layer will translate from the provider API to the regular data model.

I also added a "BucketItemType" in BucketItem so that if the front-end was 
looking at bucket item they could easily look at field to determine the type.

If you are good with those changes then I am going to merge this in. Thanks!


> Refactor Domain Model
> -
>
> Key: NIFIREG-11
> URL: https://issues.apache.org/jira/browse/NIFIREG-11
> Project: NiFi Registry
>  Issue Type: Improvement
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Minor
> Fix For: 0.0.1
>
>
> We should create a separate object model for the provider API so that those 
> objects can be decoupled from the standard data model.



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

[GitHub] nifi-registry issue #6: NIFIREG-11 Data model refactoring

2017-08-25 Thread bbende

Github user bbende commented on the issue:

https://github.com/apache/nifi-registry/pull/6
  
@kevdoran thanks for reviewing!

I pushed up another commit that changes the equals method you mentioned... 
I agree that as long as flow id's are globally unique, then we only need to use 
flow id + version for the hash/equals of the snapshot method.

Regarding using the metadata objects in the REST layer... I think we should 
still leave the REST end-points using the original data model, and the service 
layer will translate from the provider API to the regular data model.

I also added a "BucketItemType" in BucketItem so that if the front-end was 
looking at bucket item they could easily look at field to determine the type.

If you are good with those changes then I am going to merge this in. Thanks!


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

[jira] [Commented] (NIFI-4004) Refactor RecordReaderFactory and SchemaAccessStrategy to be used without incoming FlowFile

2017-08-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-4004:
--

Github user markap14 commented on the issue:

https://github.com/apache/nifi/pull/1877
  
@ijokarumawak thanks. Mostly looks good, but I'm concerned about the change 
to the writer, as I outlined in the inline comments. Can you elaborate on the 
idea there?


> Refactor RecordReaderFactory and SchemaAccessStrategy to be used without 
> incoming FlowFile
> --
>
> Key: NIFI-4004
> URL: https://issues.apache.org/jira/browse/NIFI-4004
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: 1.2.0
>Reporter: Koji Kawamura
>Assignee: Koji Kawamura
>
> Current RecordReaderFactory and SchemaAccessStrategy implementation assumes 
> there's always an incoming FlowFile available, and use it to resolve Record 
> Schema.
> That is fine for components those convert or update incoming FlowFiles, 
> however there are other components those does not have any incoming 
> FlowFiles, for example, ConsumeKafkaRecord_0_10. Typically, ones fetches data 
> from external system do not have incoming FlowFile. And current API doesn't 
> fit well with these as it requires a FlowFile.
> In fact, [ConsumeKafkaRecord creates a temporal 
> FlowFile|https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-kafka-bundle/nifi-kafka-0-10-processors/src/main/java/org/apache/nifi/processors/kafka/pubsub/ConsumerLease.java#L426]
>  only to get RecordSchema. This should be avoided as we expect more 
> components start using Record reader mechanism.
> This JIRA proposes refactoring current API to allow accessing RecordReaders 
> without needing an incoming FlowFile.
> Additionally, since there's Schema Access Strategy that requires incoming 
> FlowFile containing attribute values to access schema registry, it'd be 
> useful if we could tell user when such RecordReader is specified that it 
> can't be used.



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

[GitHub] nifi issue #1877: NIFI-4004: Use RecordReaderFactory without FlowFile.

2017-08-25 Thread markap14

Github user markap14 commented on the issue:

https://github.com/apache/nifi/pull/1877
  
@ijokarumawak thanks. Mostly looks good, but I'm concerned about the change 
to the writer, as I outlined in the inline comments. Can you elaborate on the 
idea there?


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

[jira] [Commented] (NIFI-4004) Refactor RecordReaderFactory and SchemaAccessStrategy to be used without incoming FlowFile

2017-08-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-4004:
--

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

https://github.com/apache/nifi/pull/1877#discussion_r135305805
  
--- Diff: 
nifi-nar-bundles/nifi-standard-services/nifi-record-serialization-service-api/src/main/java/org/apache/nifi/serialization/RecordSetWriterFactory.java
 ---
@@ -45,20 +51,23 @@
  */
 public interface RecordSetWriterFactory extends ControllerService {
 
+InputStream EMPTY_INPUT_STREAM = new ByteArrayInputStream(new byte[0]);
+
 /**
  * 
- * Returns the Schema that will be used for writing Records. Note that 
the FlowFile and InputStream that are given
- * may well be different than the FlowFile that the writer will write 
to. The given FlowFile and InputStream are
+ * Returns the Schema that will be used for writing Records. Note that 
the InputStream that are given
+ * may well be different than the content that the writer will write. 
The given variables and InputStream are
  * intended to be used for determining the schema that should be used 
when writing records.
  * 
  *
- * @param flowFile the FlowFile from which the schema should be 
determined.
+ * @param variables the variables which is used to resolve Record 
Schema via Expression Language, can be null or empty
+ * @param content the contents of the input data from which to 
determine the schema
  * @param readSchema the schema that was read from the incoming 
FlowFile, or null if there is no input schema
  *
  * @return the Schema that should be used for writing Records
  * @throws SchemaNotFoundException if unable to find the schema
  */
-RecordSchema getSchema(FlowFile flowFile, RecordSchema readSchema) 
throws SchemaNotFoundException, IOException;
+RecordSchema getSchema(Map variables, InputStream 
content, RecordSchema readSchema) throws SchemaNotFoundException, IOException;
--- End diff --

@ijokarumawak can you explain the reasoning here for providing a 
Map and an InputStream? Previously, with just the FlowFile, the 
Writer had access only to the attributes, not the content (because it had no 
Process Session). I believe that is the correct abstraction. The RecordSchema 
from the reader already is passed in, and the FlowFile being written to will 
have no content, generally, so reading from the destination FlowFile wouldn't 
make sense. It's possible that I'm just misunderstanding the idea here, though.


> Refactor RecordReaderFactory and SchemaAccessStrategy to be used without 
> incoming FlowFile
> --
>
> Key: NIFI-4004
> URL: https://issues.apache.org/jira/browse/NIFI-4004
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: 1.2.0
>Reporter: Koji Kawamura
>Assignee: Koji Kawamura
>
> Current RecordReaderFactory and SchemaAccessStrategy implementation assumes 
> there's always an incoming FlowFile available, and use it to resolve Record 
> Schema.
> That is fine for components those convert or update incoming FlowFiles, 
> however there are other components those does not have any incoming 
> FlowFiles, for example, ConsumeKafkaRecord_0_10. Typically, ones fetches data 
> from external system do not have incoming FlowFile. And current API doesn't 
> fit well with these as it requires a FlowFile.
> In fact, [ConsumeKafkaRecord creates a temporal 
> FlowFile|https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-kafka-bundle/nifi-kafka-0-10-processors/src/main/java/org/apache/nifi/processors/kafka/pubsub/ConsumerLease.java#L426]
>  only to get RecordSchema. This should be avoided as we expect more 
> components start using Record reader mechanism.
> This JIRA proposes refactoring current API to allow accessing RecordReaders 
> without needing an incoming FlowFile.
> Additionally, since there's Schema Access Strategy that requires incoming 
> FlowFile containing attribute values to access schema registry, it'd be 
> useful if we could tell user when such RecordReader is specified that it 
> can't be used.



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

[GitHub] nifi pull request #1877: NIFI-4004: Use RecordReaderFactory without FlowFile...

2017-08-25 Thread markap14

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

https://github.com/apache/nifi/pull/1877#discussion_r135305805
  
--- Diff: 
nifi-nar-bundles/nifi-standard-services/nifi-record-serialization-service-api/src/main/java/org/apache/nifi/serialization/RecordSetWriterFactory.java
 ---
@@ -45,20 +51,23 @@
  */
 public interface RecordSetWriterFactory extends ControllerService {
 
+InputStream EMPTY_INPUT_STREAM = new ByteArrayInputStream(new byte[0]);
+
 /**
  * 
- * Returns the Schema that will be used for writing Records. Note that 
the FlowFile and InputStream that are given
- * may well be different than the FlowFile that the writer will write 
to. The given FlowFile and InputStream are
+ * Returns the Schema that will be used for writing Records. Note that 
the InputStream that are given
+ * may well be different than the content that the writer will write. 
The given variables and InputStream are
  * intended to be used for determining the schema that should be used 
when writing records.
  * 
  *
- * @param flowFile the FlowFile from which the schema should be 
determined.
+ * @param variables the variables which is used to resolve Record 
Schema via Expression Language, can be null or empty
+ * @param content the contents of the input data from which to 
determine the schema
  * @param readSchema the schema that was read from the incoming 
FlowFile, or null if there is no input schema
  *
  * @return the Schema that should be used for writing Records
  * @throws SchemaNotFoundException if unable to find the schema
  */
-RecordSchema getSchema(FlowFile flowFile, RecordSchema readSchema) 
throws SchemaNotFoundException, IOException;
+RecordSchema getSchema(Map variables, InputStream 
content, RecordSchema readSchema) throws SchemaNotFoundException, IOException;
--- End diff --

@ijokarumawak can you explain the reasoning here for providing a 
Map and an InputStream? Previously, with just the FlowFile, the 
Writer had access only to the attributes, not the content (because it had no 
Process Session). I believe that is the correct abstraction. The RecordSchema 
from the reader already is passed in, and the FlowFile being written to will 
have no content, generally, so reading from the destination FlowFile wouldn't 
make sense. It's possible that I'm just misunderstanding the idea here, though.


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

[jira] [Updated] (NIFI-4323) Get/List/DeleteHDFS processors should use UGI.doAs when invoking HDFS operations

2017-08-25 Thread Jeff Storck (JIRA)


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

Jeff Storck updated NIFI-4323:
--
Description: While the Get/List/DeleteHDFS processors are working without 
wrapping HDFS operations in UGI.doAs calls, for best practice, those operations 
should be performed as PrivilegedExceptionActions supplied to the UGI.doAs 
method.  (was: While the Get/List/DeleteHDFS processors are working without 
wrapping HDFS operations in UGI.doAs calls, for best practice, those operations 
should be done as PrivilegedExceptionActions.)

> Get/List/DeleteHDFS processors should use UGI.doAs when invoking HDFS 
> operations
> 
>
> Key: NIFI-4323
> URL: https://issues.apache.org/jira/browse/NIFI-4323
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: 1.3.0
>Reporter: Jeff Storck
>Assignee: Jeff Storck
>
> While the Get/List/DeleteHDFS processors are working without wrapping HDFS 
> operations in UGI.doAs calls, for best practice, those operations should be 
> performed as PrivilegedExceptionActions supplied to the UGI.doAs method.



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

[jira] [Updated] (NIFI-4323) Get/List/DeleteHDFS processors should use UGI.doAs when invoking HDFS operations

2017-08-25 Thread Jeff Storck (JIRA)


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

Jeff Storck updated NIFI-4323:
--
Summary: Get/List/DeleteHDFS processors should use UGI.doAs when invoking 
HDFS operations  (was: Add UGI.doAs around HDFS operations in 
Get/List/DeleteHDFS processors)

> Get/List/DeleteHDFS processors should use UGI.doAs when invoking HDFS 
> operations
> 
>
> Key: NIFI-4323
> URL: https://issues.apache.org/jira/browse/NIFI-4323
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: 1.3.0
>Reporter: Jeff Storck
>Assignee: Jeff Storck
>
> While the Get/List/DeleteHDFS processors are working without wrapping HDFS 
> operations in UGI.doAs calls, for best practice, those operations should be 
> done as PrivilegedExceptionActions.



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

[jira] [Created] (NIFI-4323) Add UGI.doAs around HDFS operations in Get/List/DeleteHDFS processors

2017-08-25 Thread Jeff Storck (JIRA)

Jeff Storck created NIFI-4323:
-

 Summary: Add UGI.doAs around HDFS operations in 
Get/List/DeleteHDFS processors
 Key: NIFI-4323
 URL: https://issues.apache.org/jira/browse/NIFI-4323
 Project: Apache NiFi
  Issue Type: Improvement
  Components: Extensions
Affects Versions: 1.3.0
Reporter: Jeff Storck
Assignee: Jeff Storck


While the Get/List/DeleteHDFS processors are working without wrapping HDFS 
operations in UGI.doAs calls, for best practice, those operations should be 
done as PrivilegedExceptionActions.



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

[GitHub] nifi issue #2020: [NiFi-3973] Add PutKudu Processor for ingesting data to Ku...

2017-08-25 Thread rickysaltzer

Github user rickysaltzer commented on the issue:

https://github.com/apache/nifi/pull/2020
  
@cammachusa 

I committed the changes below 


https://git1-us-west.apache.org/repos/asf?p=nifi.git;a=commit;h=e3da44fb626a495f18ead72955a0854d6b1f7151

Thanks for your patience, and hope to see another contribution in the 
future! 

Ricky 


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

[GitHub] nifi issue #1975: NIFI-3332: ListXXX to not miss files with the latest proce...

2017-08-25 Thread bbende

Github user bbende commented on the issue:

https://github.com/apache/nifi/pull/1975
  
@ijokarumawak was reviewing this, running a full build rebased against 
master i am consistently getting this test failure:

java.lang.IndexOutOfBoundsException: Index: 0, Size: 0

at java.util.ArrayList.rangeCheck(ArrayList.java:653)
at java.util.ArrayList.get(ArrayList.java:429)
at 
org.apache.nifi.processors.standard.TestFTP.basicFileList(TestFTP.java:224)

Also, any reason why the junit dependency was changed from test to compile?


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

[jira] [Commented] (NIFI-3332) Bug in ListXXX causes matching timestamps to be ignored on later runs

2017-08-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-3332:
--

Github user bbende commented on the issue:

https://github.com/apache/nifi/pull/1975
  
@ijokarumawak was reviewing this, running a full build rebased against 
master i am consistently getting this test failure:

java.lang.IndexOutOfBoundsException: Index: 0, Size: 0

at java.util.ArrayList.rangeCheck(ArrayList.java:653)
at java.util.ArrayList.get(ArrayList.java:429)
at 
org.apache.nifi.processors.standard.TestFTP.basicFileList(TestFTP.java:224)

Also, any reason why the junit dependency was changed from test to compile?


> Bug in ListXXX causes matching timestamps to be ignored on later runs
> -
>
> Key: NIFI-3332
> URL: https://issues.apache.org/jira/browse/NIFI-3332
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 0.7.1, 1.1.1
>Reporter: Joe Skora
>Assignee: Koji Kawamura
>Priority: Critical
> Attachments: listfiles.png, Test-showing-ListFile-timestamp-bug.log, 
> Test-showing-ListFile-timestamp-bug.patch
>
>
> The new state implementation for the ListXXX processors based on 
> AbstractListProcessor creates a race conditions when processor runs occur 
> while a batch of files is being written with the same timestamp.
> The changes to state management dropped tracking of the files processed for a 
> given timestamp.  Without the record of files processed, the remainder of the 
> batch is ignored on the next processor run since their timestamp is not 
> greater than the one timestamp stored in processor state.  With the file 
> tracking it was possible to process files that matched the timestamp exactly 
> and exclude the previously processed files.
> A basic time goes as follows.
>   T0 - system creates or receives batch of files with Tx timestamp where Tx 
> is more than the current timestamp in processor state.
>   T1 - system writes 1st half of Tx batch to the ListFile source directory.
>   T2 - ListFile runs picking up 1st half of Tx batch and stores Tx timestamp 
> in processor state.
>   T3 - system writes 2nd half of Tx batch to ListFile source directory.
>   T4 - ListFile runs ignoring any files with T <= Tx, eliminating 2nd half Tx 
> timestamp batch.
> I've attached a patch[1] for TestListFile.java that adds an instrumented unit 
> test demonstrates the problem and a log[2] of the output from one such run.  
> The test writes 3 files each in two batches with processor runs after each 
> batch.  Batch 2 writes files with timestamps older than, equal to, and newer 
> than the timestamp stored when batch 1 was processed, but only the newer file 
> is picked up.  The older file is correctly ignored but file with the matchin 
> timestamp file should have been processed.
> [1] Test-showing-ListFile-timestamp-bug.patch
> [2] Test-showing-ListFile-timestamp-bug.log



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

[jira] [Created] (NIFI-4322) If RuntimeException thrown during checkpoint of FlowFile Repository, repo stops checkpointing

2017-08-25 Thread Mark Payne (JIRA)

Mark Payne created NIFI-4322:


 Summary: If RuntimeException thrown during checkpoint of FlowFile 
Repository, repo stops checkpointing
 Key: NIFI-4322
 URL: https://issues.apache.org/jira/browse/NIFI-4322
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework
Reporter: Mark Payne
Assignee: Mark Payne


The WriteAheadFlowFileRepository has a 'checkpointRunnable' task that is 
scheduled periodically, which is responsible for checkpointing the FlowFile 
Repository. It catches IOException but no other Exceptions. So if an OOME 
occurs or a RuntimeException, the repository will stop checkpointing. As a 
result, it can fill all disk space and/or take a very long time to recover upon 
restart, depending on how large the FlowFile repository has become.



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

[jira] [Commented] (NIFIREG-11) Refactor Domain Model

2017-08-25 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/NIFIREG-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16141683#comment-16141683
 ] 

ASF GitHub Bot commented on NIFIREG-11:
---

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

https://github.com/apache/nifi-registry/pull/6#discussion_r135267708
  
--- Diff: 
nifi-registry-data-model/src/main/java/org/apache/nifi/registry/flow/VersionedFlowSnapshotMetadata.java
 ---
@@ -0,0 +1,117 @@
+/*
+ * 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.registry.flow;
+
+import io.swagger.annotations.ApiModel;
+import io.swagger.annotations.ApiModelProperty;
+
+import java.util.Objects;
+
+/**
+ * The metadata information about a VersionedFlowSnapshot. This class 
implements Comparable in order
+ * to sort based on the snapshot version in ascending order.
+ */
+@ApiModel(value = "versionedFlowSnapshot")
+public class VersionedFlowSnapshotMetadata implements 
Comparable {
+
+private String bucketIdentifier;
+private String flowIdentifier;
+private String flowName;
+private int version;
+private long timestamp;
+private String comments;
+
+@ApiModelProperty("The identifier of the bucket this snapshot belongs 
to.")
+public String getBucketIdentifier() {
+return bucketIdentifier;
+}
+
+public void setBucketIdentifier(String bucketIdentifier) {
+this.bucketIdentifier = bucketIdentifier;
+}
+
+@ApiModelProperty("The identifier of the flow this snapshot belongs 
to.")
+public String getFlowIdentifier() {
+return flowIdentifier;
+}
+
+public void setFlowIdentifier(String flowIdentifier) {
+this.flowIdentifier = flowIdentifier;
+}
+
+@ApiModelProperty("The name of the flow this snapshot belongs to.")
+public String getFlowName() {
+return flowName;
+}
+
+public void setFlowName(String flowName) {
+this.flowName = flowName;
+}
+
+@ApiModelProperty("The version of this snapshot of the flow.")
+public int getVersion() {
+return version;
+}
+
+public void setVersion(int version) {
+this.version = version;
+}
+
+@ApiModelProperty("The timestamp when the flow was saved.")
+public long getTimestamp() {
+return timestamp;
+}
+
+public void setTimestamp(long timestamp) {
+this.timestamp = timestamp;
+}
+
+@ApiModelProperty("The comments provided by the user when creating the 
snapshot.")
+public String getComments() {
+return comments;
+}
+
+public void setComments(String comments) {
+this.comments = comments;
+}
+
+@Override
+public int compareTo(final VersionedFlowSnapshotMetadata o) {
+return o == null ? -1 : Integer.compare(version, o.version);
+}
+
+@Override
+public int hashCode() {
+return Objects.hash(this.bucketIdentifier, this.flowIdentifier, 
Integer.valueOf(this.version));
+}
+
+@Override
+public boolean equals(final Object obj) {
+if (obj == null) {
+return false;
+}
+if (getClass() != obj.getClass()) {
+return false;
+}
+
+final VersionedFlowSnapshotMetadata other = 
(VersionedFlowSnapshotMetadata) obj;
+
+return Objects.equals(this.bucketIdentifier, 
other.bucketIdentifier)
+&& Objects.equals(this.flowIdentifier, 
other.flowIdentifier)
+&& Objects.equals(this.version, other.version);
+}
--- End diff --

This is a a nit-pick, but is including bucketIdentifier necessary for 
equals() and hashcode() here? It's omitted from BucketItem, where only th

[GitHub] nifi-registry pull request #6: NIFIREG-11 Data model refactoring

2017-08-25 Thread kevdoran

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

https://github.com/apache/nifi-registry/pull/6#discussion_r135267708
  
--- Diff: 
nifi-registry-data-model/src/main/java/org/apache/nifi/registry/flow/VersionedFlowSnapshotMetadata.java
 ---
@@ -0,0 +1,117 @@
+/*
+ * 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.registry.flow;
+
+import io.swagger.annotations.ApiModel;
+import io.swagger.annotations.ApiModelProperty;
+
+import java.util.Objects;
+
+/**
+ * The metadata information about a VersionedFlowSnapshot. This class 
implements Comparable in order
+ * to sort based on the snapshot version in ascending order.
+ */
+@ApiModel(value = "versionedFlowSnapshot")
+public class VersionedFlowSnapshotMetadata implements 
Comparable {
+
+private String bucketIdentifier;
+private String flowIdentifier;
+private String flowName;
+private int version;
+private long timestamp;
+private String comments;
+
+@ApiModelProperty("The identifier of the bucket this snapshot belongs 
to.")
+public String getBucketIdentifier() {
+return bucketIdentifier;
+}
+
+public void setBucketIdentifier(String bucketIdentifier) {
+this.bucketIdentifier = bucketIdentifier;
+}
+
+@ApiModelProperty("The identifier of the flow this snapshot belongs 
to.")
+public String getFlowIdentifier() {
+return flowIdentifier;
+}
+
+public void setFlowIdentifier(String flowIdentifier) {
+this.flowIdentifier = flowIdentifier;
+}
+
+@ApiModelProperty("The name of the flow this snapshot belongs to.")
+public String getFlowName() {
+return flowName;
+}
+
+public void setFlowName(String flowName) {
+this.flowName = flowName;
+}
+
+@ApiModelProperty("The version of this snapshot of the flow.")
+public int getVersion() {
+return version;
+}
+
+public void setVersion(int version) {
+this.version = version;
+}
+
+@ApiModelProperty("The timestamp when the flow was saved.")
+public long getTimestamp() {
+return timestamp;
+}
+
+public void setTimestamp(long timestamp) {
+this.timestamp = timestamp;
+}
+
+@ApiModelProperty("The comments provided by the user when creating the 
snapshot.")
+public String getComments() {
+return comments;
+}
+
+public void setComments(String comments) {
+this.comments = comments;
+}
+
+@Override
+public int compareTo(final VersionedFlowSnapshotMetadata o) {
+return o == null ? -1 : Integer.compare(version, o.version);
+}
+
+@Override
+public int hashCode() {
+return Objects.hash(this.bucketIdentifier, this.flowIdentifier, 
Integer.valueOf(this.version));
+}
+
+@Override
+public boolean equals(final Object obj) {
+if (obj == null) {
+return false;
+}
+if (getClass() != obj.getClass()) {
+return false;
+}
+
+final VersionedFlowSnapshotMetadata other = 
(VersionedFlowSnapshotMetadata) obj;
+
+return Objects.equals(this.bucketIdentifier, 
other.bucketIdentifier)
+&& Objects.equals(this.flowIdentifier, 
other.flowIdentifier)
+&& Objects.equals(this.version, other.version);
+}
--- End diff --

This is a a nit-pick, but is including bucketIdentifier necessary for 
equals() and hashcode() here? It's omitted from BucketItem, where only the 
item's identifier is used. It should work fine both ways as we will be using 
UUIDs. I don't know if anything is needed, it just caught my eye as a minor 
inconsistency between BucketItem (and VersionedFlow which extends BucketItem) 
and VersionedFlowSn

[jira] [Updated] (NIFI-4310) Certain flow configurations are improperly identified as empty during flow election

2017-08-25 Thread Mark Payne (JIRA)


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

Mark Payne updated NIFI-4310:
-
   Resolution: Fixed
Fix Version/s: 1.4.0
   Status: Resolved  (was: Patch Available)

> Certain flow configurations are improperly identified as empty during flow 
> election
> ---
>
> Key: NIFI-4310
> URL: https://issues.apache.org/jira/browse/NIFI-4310
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.3.0
>Reporter: Yolanda M. Davis
>Assignee: Yolanda M. Davis
> Fix For: 1.4.0
>
>
> While testing a cluster containing nodes with two different flows on initial 
> startup, I discovered that one flow, with an empty root processor group but 
> containing reporting tasks, would lose a flow election against flows that 
> also had empty root processor groups yet with no reporting tasks or 
> controller tasks. This caused an issue downstream during startup where it 
> attempted to replace the non-empty flow with an empty flow on certain nodes, 
> which led to UninheritableFlowExceptions. Further investigation revealed that 
> during election there is a check to determine if the flow is empty however 
> the check does not account for the existence of a reporting task or 
> controller services. This should be repaired to ensure that flows are 
> properly identified as non-empty for election.



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

[jira] [Commented] (NIFI-4310) Certain flow configurations are improperly identified as empty during flow election

2017-08-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-4310:
--

Github user markap14 commented on the issue:

https://github.com/apache/nifi/pull/2107
  
@YolandaMDavis that was a great find. PR looks good - all new (and old) 
unit tests pass, was able to test behavior manually as well. Thanks for 
knocking that out! +1 merged to master.


> Certain flow configurations are improperly identified as empty during flow 
> election
> ---
>
> Key: NIFI-4310
> URL: https://issues.apache.org/jira/browse/NIFI-4310
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.3.0
>Reporter: Yolanda M. Davis
>Assignee: Yolanda M. Davis
>
> While testing a cluster containing nodes with two different flows on initial 
> startup, I discovered that one flow, with an empty root processor group but 
> containing reporting tasks, would lose a flow election against flows that 
> also had empty root processor groups yet with no reporting tasks or 
> controller tasks. This caused an issue downstream during startup where it 
> attempted to replace the non-empty flow with an empty flow on certain nodes, 
> which led to UninheritableFlowExceptions. Further investigation revealed that 
> during election there is a check to determine if the flow is empty however 
> the check does not account for the existence of a reporting task or 
> controller services. This should be repaired to ensure that flows are 
> properly identified as non-empty for election.



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

[GitHub] nifi issue #2107: NIFI-4310 - added changes to support detection of reportin...

2017-08-25 Thread markap14

Github user markap14 commented on the issue:

https://github.com/apache/nifi/pull/2107
  
@YolandaMDavis that was a great find. PR looks good - all new (and old) 
unit tests pass, was able to test behavior manually as well. Thanks for 
knocking that out! +1 merged to master.


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

[GitHub] nifi pull request #2107: NIFI-4310 - added changes to support detection of r...

2017-08-25 Thread asfgit

Github user asfgit closed the pull request at:

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


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

[jira] [Commented] (NIFI-4310) Certain flow configurations are improperly identified as empty during flow election

2017-08-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-4310:
--

Github user asfgit closed the pull request at:

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


> Certain flow configurations are improperly identified as empty during flow 
> election
> ---
>
> Key: NIFI-4310
> URL: https://issues.apache.org/jira/browse/NIFI-4310
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.3.0
>Reporter: Yolanda M. Davis
>Assignee: Yolanda M. Davis
>
> While testing a cluster containing nodes with two different flows on initial 
> startup, I discovered that one flow, with an empty root processor group but 
> containing reporting tasks, would lose a flow election against flows that 
> also had empty root processor groups yet with no reporting tasks or 
> controller tasks. This caused an issue downstream during startup where it 
> attempted to replace the non-empty flow with an empty flow on certain nodes, 
> which led to UninheritableFlowExceptions. Further investigation revealed that 
> during election there is a check to determine if the flow is empty however 
> the check does not account for the existence of a reporting task or 
> controller services. This should be repaired to ensure that flows are 
> properly identified as non-empty for election.



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

[jira] [Commented] (NIFI-4310) Certain flow configurations are improperly identified as empty during flow election

2017-08-25 Thread ASF subversion and git services (JIRA)


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

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

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

NIFI-4310 - added changes to support detection of reporting tasks and 
controller services during isEmpty flow check. Added testing scenarios. This 
closes #2107.


> Certain flow configurations are improperly identified as empty during flow 
> election
> ---
>
> Key: NIFI-4310
> URL: https://issues.apache.org/jira/browse/NIFI-4310
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.3.0
>Reporter: Yolanda M. Davis
>Assignee: Yolanda M. Davis
>
> While testing a cluster containing nodes with two different flows on initial 
> startup, I discovered that one flow, with an empty root processor group but 
> containing reporting tasks, would lose a flow election against flows that 
> also had empty root processor groups yet with no reporting tasks or 
> controller tasks. This caused an issue downstream during startup where it 
> attempted to replace the non-empty flow with an empty flow on certain nodes, 
> which led to UninheritableFlowExceptions. Further investigation revealed that 
> during election there is a check to determine if the flow is empty however 
> the check does not account for the existence of a reporting task or 
> controller services. This should be repaired to ensure that flows are 
> properly identified as non-empty for election.



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

[jira] [Commented] (NIFI-4310) Certain flow configurations are improperly identified as empty during flow election

2017-08-25 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-4310:
--

Github user markap14 commented on the issue:

https://github.com/apache/nifi/pull/2107
  
Will review...


> Certain flow configurations are improperly identified as empty during flow 
> election
> ---
>
> Key: NIFI-4310
> URL: https://issues.apache.org/jira/browse/NIFI-4310
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.3.0
>Reporter: Yolanda M. Davis
>Assignee: Yolanda M. Davis
>
> While testing a cluster containing nodes with two different flows on initial 
> startup, I discovered that one flow, with an empty root processor group but 
> containing reporting tasks, would lose a flow election against flows that 
> also had empty root processor groups yet with no reporting tasks or 
> controller tasks. This caused an issue downstream during startup where it 
> attempted to replace the non-empty flow with an empty flow on certain nodes, 
> which led to UninheritableFlowExceptions. Further investigation revealed that 
> during election there is a check to determine if the flow is empty however 
> the check does not account for the existence of a reporting task or 
> controller services. This should be repaired to ensure that flows are 
> properly identified as non-empty for election.



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

[GitHub] nifi issue #2107: NIFI-4310 - added changes to support detection of reportin...

2017-08-25 Thread markap14

Github user markap14 commented on the issue:

https://github.com/apache/nifi/pull/2107
  
Will review...


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

68 matches

Mail list logo