[jira] [Updated] (NIFI-2049) Bulletins do not show the 'Category'

[Matt Gilman (JIRA)]

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

Matt Gilman updated NIFI-2049:
--
Fix Version/s: (was: 1.0.0)
   1.1.0

> Bulletins do not show the 'Category'
> 
>
> Key: NIFI-2049
> URL: https://issues.apache.org/jira/browse/NIFI-2049
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Mark Payne
>Priority: Minor
> Fix For: 1.1.0
>
>
> Currently, when bulletins are rendered in the UI, the bulletin's category is 
> not shown.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-619) update MonitorActivity processor to be cluster friendly

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-619:
-

Github user ijokarumawak commented on the issue:

https://github.com/apache/nifi/pull/575
  
@JPercivall I was wrong with above comment. If one uses `On primary node`, 
then its onTrigger won't be executed, it means it can't update state in 
Zookeeper either. I'll add property to indicate whether inactive / restored 
notification should be sent only from primary node.


> update MonitorActivity processor to be cluster friendly
> ---
>
> Key: NIFI-619
> URL: https://issues.apache.org/jira/browse/NIFI-619
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Brandon DeVries
>Assignee: Koji Kawamura
>Priority: Minor
> Fix For: 1.0.0
>
>
> This processor should be able to be used to monitor activity across the 
> cluster.  In its current state, alerting is based on activity of a single 
> node, not the entire cluster.
> For example, in a 2 node cluster, if system A is getting data from a given 
> flow and system B is not, system B will alert for lack of activity even 
> though the flow is functioning "normally".
> The ideal behavior would be fore an alert to be generated only if both 
> systems did not see data in the specified time.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #575: NIFI-619: Make MonitorActivity more cluster friendly

[ijokarumawak]

Github user ijokarumawak commented on the issue:

https://github.com/apache/nifi/pull/575
  
@JPercivall I was wrong with above comment. If one uses `On primary node`, 
then its onTrigger won't be executed, it means it can't update state in 
Zookeeper either. I'll add property to indicate whether inactive / restored 
notification should be sent only from primary node.


---
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-1152) StandardProcessSession and MockProcessSession should handle transfer to unregistered relationship correctly

[Joseph Witt (JIRA)]

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

Joseph Witt commented on NIFI-1152:
---

[~puspendu.baner...@gmail.com] I'd like to apologize as I now more fully 
understand what you were facing and I see why you did NIFI-1152 and NIFI-2117 
together - you were definitely on the right track.  I'll have a new PR in later 
this evening hopefully that addresses NIFI-1152 and NIFI-2117 together because 
as you probably found fixing NIFI-1152 reveals a bug in NIFI-2117.  Fortunately 
this event has led to finding the root problem which was a bug in 
StandardProcessSession as it was not honoring API definitions which is now 
fixed, the mock session has been fixed, and we'll get the invoke script sorted 
as you found.

[~mattyb149]  Would love to hear your intent for SUCCESS and FAILURE on 
InvokeScriptedProcessor.  You have code which suggests you only want 
success/failure relationships there if no other relationships have been 
provided by the invoked script.  But, as Puspendu rightly points out the 
javadocs state they'll always be there.  I think on balance we need to probably 
make them always available and take the migration hit that might occur.  It 
will only make flows invalid and need relationships added worst case - won't 
break behavior so is ok.  But please confirm.

Once this PR is sorted then the groovy tests can be addressed if that is a 
problem and so long as I don't find that one has to be in here too!

Thanks
Joe

> StandardProcessSession and MockProcessSession should handle transfer to 
> unregistered relationship correctly
> ---
>
> Key: NIFI-1152
> URL: https://issues.apache.org/jira/browse/NIFI-1152
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Tools and Build
>Affects Versions: 1.0.0, 0.6.0, 0.7.0, 0.6.1
>Reporter: Mark Payne
>Assignee: Joseph Witt
>  Labels: beginner, newbie
> Fix For: 1.0.0
>
> Attachments: 
> 0001-Fix-for-NIFI-1838-NIFI-1152-Code-modification-for-ty.patch
>
>
> If a processor calls ProcessSession.transfer(flowFile, 
> NON_EXISTENT_RELATIONSHIP) the NiFi framework will throw a 
> FlowFileHandlingException. However, the Mock Framework simply allows it and 
> does not throw any sort of Exception. This needs to be addressed so that the 
> Mock framework functions the same way as the normal NiFi framework.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #563: NIFI-2078: External state management.

[ijokarumawak]

Github user ijokarumawak commented on the issue:

https://github.com/apache/nifi/pull/563
  
@mcgilman Yes, I noticed that 'Clear state' moved above the state table, so 
I removed z-index change. 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.
---

[GitHub] nifi pull request #502: Nifi-1972 Apache Ignite Put Cache Processor

[pvillard31]

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

https://github.com/apache/nifi/pull/502#discussion_r70520699
  
--- Diff: 
nifi-nar-bundles/nifi-ignite-bundle/nifi-ignite-processors/src/main/java/org/apache/nifi/processors/ignite/cache/AbstractIgniteCacheProcessor.java
 ---
@@ -0,0 +1,125 @@
+/*
+ * 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.processors.ignite.cache;
+
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Set;
+
+import org.apache.ignite.IgniteCache;
+import org.apache.nifi.annotation.lifecycle.OnStopped;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.processor.ProcessContext;
+import org.apache.nifi.processor.Relationship;
+import org.apache.nifi.processor.exception.ProcessException;
+import org.apache.nifi.processor.util.StandardValidators;
+import org.apache.nifi.processors.ignite.AbstractIgniteProcessor;
+
+/**
+ * Base class of Ignite cache based processor
+ */
+public abstract class AbstractIgniteCacheProcessor extends 
AbstractIgniteProcessor {
+
+/**
+ * Flow File attribute for cache entry key
+ */
+public static final String IGNITE_CACHE_ENTRY_KEY = 
"ignite.cache.entry.key";
+
+/**
+ * Ignite cache name
+ */
+protected static final PropertyDescriptor CACHE_NAME = new 
PropertyDescriptor.Builder()
+.displayName("Ignite Cache Name")
+.name("ignite-cache-name")
+.description("The name of the ignite cache where e")
--- End diff --

"where e"?


---
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-2095) Introduce UI for managing Users & User Groups

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2095:
--

Github user markap14 commented on the issue:

https://github.com/apache/nifi/pull/631
  
@mcgilman looks great! A whole lot of work has gone into this, and it looks 
fantastic. Was able to verify functionality of the different access policies. I 
create a handful of additional JIRA's that were minor but I didn't want them to 
hold up merging this PR. This is now merged to master. Thanks!


> Introduce UI for managing Users & User Groups
> -
>
> Key: NIFI-2095
> URL: https://issues.apache.org/jira/browse/NIFI-2095
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>Priority: Blocker
> Fix For: 1.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2168) Extension Repositories (aka Extension Registry) for Dynamically-loaded Extensions

[Matt Foley (JIRA)]

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

Matt Foley updated NIFI-2168:
-
Summary: Extension Repositories (aka Extension Registry) for 
Dynamically-loaded Extensions  (was: External Repositories (aka Extension 
Registry) for Dynamically-loaded Extensions)

> Extension Repositories (aka Extension Registry) for Dynamically-loaded 
> Extensions
> -
>
> Key: NIFI-2168
> URL: https://issues.apache.org/jira/browse/NIFI-2168
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Matt Foley
>Assignee: Matt Foley
>
> Enable repositories external to the NiFi deployment (aka "Extension 
> Registry") and enable dynamically-loaded extensions from external 
> repositories.
> Please see the wiki for Design Proposal:
> * 
> https://cwiki.apache.org/confluence/display/NIFI/External+Repositories+%28aka+Extension+Registry%29+for+Dynamically-loaded+Extensions
> Please see prototype implementation (or the beginnings of one) in github:
> * https://github.com/PuspenduBanerjee/nifi/tree/NIFI-ExtRegistry



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2168) Extension Repositories (aka Extension Registry) for Dynamically-loaded Extensions

[Matt Foley (JIRA)]

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

Matt Foley commented on NIFI-2168:
--

Updated Jira title to match Wiki page decision to call them "Extension 
Repositories" rather than "External Repositories".

> Extension Repositories (aka Extension Registry) for Dynamically-loaded 
> Extensions
> -
>
> Key: NIFI-2168
> URL: https://issues.apache.org/jira/browse/NIFI-2168
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Matt Foley
>Assignee: Matt Foley
>
> Enable repositories external to the NiFi deployment (aka "Extension 
> Registry") and enable dynamically-loaded extensions from external 
> repositories.
> Please see the wiki for Design Proposal:
> * 
> https://cwiki.apache.org/confluence/display/NIFI/External+Repositories+%28aka+Extension+Registry%29+for+Dynamically-loaded+Extensions
> Please see prototype implementation (or the beginnings of one) in github:
> * https://github.com/PuspenduBanerjee/nifi/tree/NIFI-ExtRegistry



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #627: [NIFI-2205] [NIFI-2217] [NIFI-2219] [NIFI-2180] [NIFI-2140]...

[mcgilman]

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/627
  
@scottyaslan Looks good... Ran into a couple minor issues...

1) Progress bar flickers and seems to default to 100%.
2) Label color preview does not update automatically.


---
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-2017) Root Group Port Transmission Icon is inaccurate

[Matt Gilman (JIRA)]

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

Matt Gilman commented on NIFI-2017:
---

I believe this UI is accurately reflecting the component status being returned. 
There may be an issue with that transmission flag in the port status. 
[~markap14] thoughts?

> Root Group Port Transmission Icon is inaccurate
> ---
>
> Key: NIFI-2017
> URL: https://issues.apache.org/jira/browse/NIFI-2017
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Matt Gilman
>Priority: Minor
> Fix For: 1.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #563: NIFI-2078: External state management.

[mcgilman]

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/563
  
@ijokarumawak Awesome, thank you. There was just some confusion about 
whether we could resolve the PR for NIFI-2078 and just wanted to verify with 
you first.


---
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-2078) State management for processors whose states are managed externally

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2078:
--

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/563
  
@ijokarumawak Awesome, thank you. There was just some confusion about 
whether we could resolve the PR for NIFI-2078 and just wanted to verify with 
you first.


> State management for processors whose states are managed externally
> ---
>
> Key: NIFI-2078
> URL: https://issues.apache.org/jira/browse/NIFI-2078
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Koji Kawamura
>Assignee: Koji Kawamura
> Fix For: 1.0.0
>
>
> Inherently by the nature of a given processor it may involve state managed by 
> itself (using nifi state management), or can be managed by some external 
> service it interacts with (kafka's offset), and theoretically some might have 
> both going on. With the new state management, we're giving users a way to 
> reset state managed by nifi for a given processor. But it doesnt apply to 
> those processors who have external state.
> we should consider offering a way to reset state that allows a processor to 
> call out to whatever external store it impacts



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (NIFI-2244) Cannot modify connection if user does not have permissions to modify source or destination

[Mark Payne (JIRA)]

Mark Payne created NIFI-2244:


 Summary: Cannot modify connection if user does not have 
permissions to modify source or destination
 Key: NIFI-2244
 URL: https://issues.apache.org/jira/browse/NIFI-2244
 Project: Apache NiFi
  Issue Type: Sub-task
  Components: Core UI
Reporter: Mark Payne
 Fix For: 1.0.0


A user is unable to modify a connection if its source or destination is a 
processor that is running. However, it appears that this logic is also applied 
when considering permissions. If I have permissions to modify a connection but 
the not permissions to modify the source or the destination, the UI does not 
allow me to Configure the connection with a right-click menu. Instead, the 
context menu shows "View Configuration" but the Operation palette menu allows 
me to configure the Connection (the palette vs. context menu issue is part of 
NIFI-2235).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (NIFI-2247) Controller bulletins tooltip rendering off screen

[Matt Gilman (JIRA)]

Matt Gilman created NIFI-2247:
-

 Summary: Controller bulletins tooltip rendering off screen
 Key: NIFI-2247
 URL: https://issues.apache.org/jira/browse/NIFI-2247
 Project: Apache NiFi
  Issue Type: Sub-task
  Components: Core UI
Reporter: Matt Gilman
 Fix For: 1.0.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (NIFI-2112) Perform Release Management Functions for 0.7.0

[Joseph Percivall (JIRA)]

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

Joseph Percivall resolved NIFI-2112.

Resolution: Fixed

> Perform Release Management Functions for 0.7.0
> --
>
> Key: NIFI-2112
> URL: https://issues.apache.org/jira/browse/NIFI-2112
> Project: Apache NiFi
>  Issue Type: Task
>Reporter: Joseph Percivall
>Assignee: Joseph Percivall
>  Labels: release
> Fix For: 0.7.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2234) Provenance Lineage not working

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2234:
--

GitHub user markap14 opened a pull request:

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

NIFI-2234: Fixed but that was overwriting the cluster node identifier…

… in provenance events

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

$ git pull https://github.com/markap14/nifi NIFI-2234

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

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


commit fd08d6249501798b9951725d14f10eb116fd9562
Author: Mark Payne 
Date:   2016-07-12T21:23:40Z

NIFI-2234: Fixed but that was overwriting the cluster node identifier in 
provenance events




> Provenance Lineage not working
> --
>
> Key: NIFI-2234
> URL: https://issues.apache.org/jira/browse/NIFI-2234
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Blocker
> Fix For: 1.0.0
>
>
> In the most recent version of NiFi, when a Provenance query is submitted, the 
> events are returned, but when I click the 'View Lineage' button, it shows no 
> nodes or links in the returned graph.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2205) Filter components / border not rendered properly in the Cluster dialog

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2205:
--

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/627
  
Reviewing...


> Filter components / border not rendered properly in the Cluster dialog
> --
>
> Key: NIFI-2205
> URL: https://issues.apache.org/jira/browse/NIFI-2205
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Affects Versions: 1.0.0
>Reporter: Mark Payne
>Assignee: Scott Aslan
> Fix For: 1.0.0
>
> Attachments: screenshot-1.png
>
>
> When I go to the "Cluster" dialog, I see that the filter boxes are hidden 
> behind the table and there is no border around the dialog.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2205) Filter components / border not rendered properly in the Cluster dialog

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2205:
--

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/627
  
@scottyaslan Looks good... Ran into a couple minor issues...

1) Progress bar flickers and seems to default to 100%.
2) Label color preview does not update automatically.


> Filter components / border not rendered properly in the Cluster dialog
> --
>
> Key: NIFI-2205
> URL: https://issues.apache.org/jira/browse/NIFI-2205
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Affects Versions: 1.0.0
>Reporter: Mark Payne
>Assignee: Scott Aslan
> Fix For: 1.0.0
>
> Attachments: screenshot-1.png
>
>
> When I go to the "Cluster" dialog, I see that the filter boxes are hidden 
> behind the table and there is no border around the dialog.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2022) Update Site-to-Site Authorization Code

[ASF subversion and git services (JIRA)]

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

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

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

NIFI-2095:
- Adding a page for managing users and groups.
- Adding a page for managing access policies.
- Renaming accessPolicy in entity to permissions to avoid confusion with the 
accessPolicy model.
- Adding an Authorizable for access policies.
- Refactoring access policies endpoints.
NIFI-2022:
- Implementing site to site authorizations.


> Update Site-to-Site Authorization Code
> --
>
> Key: NIFI-2022
> URL: https://issues.apache.org/jira/browse/NIFI-2022
> Project: Apache NiFi
>  Issue Type: Task
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Mark Payne
>Assignee: Matt Gilman
>Priority: Blocker
> Fix For: 1.0.0
>
>
> Currently, we authorize users in the StandardRootGroupPort. However, we 
> should extract the user authorization out from there and raise it up to the 
> higher levels. I.e., at the SiteToSiteResource and SocketRemoteSiteListener 
> levels. The reason for this is two-fold:
> 1. We should authorize as soon as possible in order to avoid doing work for a 
> user that is not authorized.
> 2. This brings the SiteToSiteResource inline with how we perform 
> authorization in all other Resource classes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (NIFI-2245) Summary Page: Node-wise break down incomplete

[Matt Gilman (JIRA)]

Matt Gilman created NIFI-2245:
-

 Summary: Summary Page: Node-wise break down incomplete 
 Key: NIFI-2245
 URL: https://issues.apache.org/jira/browse/NIFI-2245
 Project: Apache NiFi
  Issue Type: Improvement
  Components: Core Framework
Reporter: Matt Gilman
Priority: Minor
 Fix For: 1.0.0


Node-wise break down is missing some nodes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #502: Nifi-1972 Apache Ignite Put Cache Processor

[pvillard31]

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

https://github.com/apache/nifi/pull/502#discussion_r70520573
  
--- Diff: 
nifi-nar-bundles/nifi-ignite-bundle/nifi-ignite-processors/src/main/java/org/apache/nifi/processors/ignite/AbstractIgniteProcessor.java
 ---
@@ -0,0 +1,107 @@
+/*
+ * 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.processors.ignite;
+
+import org.apache.commons.lang3.StringUtils;
+import org.apache.ignite.Ignite;
+import org.apache.ignite.Ignition;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.processor.AbstractProcessor;
+import org.apache.nifi.processor.ProcessContext;
+import org.apache.nifi.processor.Relationship;
+import org.apache.nifi.processor.util.StandardValidators;
+
+/**
+ * Base class for Ignite processors
+ */
+public abstract class AbstractIgniteProcessor extends AbstractProcessor  {
+
+/**
+ * Ignite spring configuration file
+ */
+public static final PropertyDescriptor IGNITE_CONFIGURATION_FILE = new 
PropertyDescriptor.Builder()
+.displayName("Ignite Spring Properties Xml File")
+.name("ignite-spring-properties-xml-file")
+.description("Ignite spring configuration file, 
/.xml. If the " +
+"configuration file is not provided, default Ignite 
configuration is used which default " +
+"configuration is used which binds to 127.0.0.1:47500..47509")
+.required(false)
+.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
+.build();
+
+/**
+ * Success relation
+ */
+public static final Relationship REL_SUCCESS = new 
Relationship.Builder().name("success")
+.description("All FlowFiles that are written to Ignite cache 
are routed to this relationship").build();
+
+/**
+ * Failure relation
+ */
+public static final Relationship REL_FAILURE = new 
Relationship.Builder().name("failure")
+.description("All FlowFiles that cannot be written to Ignite 
cache are routed to this relationship").build();
+
+/**
+ * The ignite instance
+ */
+private transient Ignite ignite;
+
+/**
+ * Get ignite instance
+ * @return iginte instance
+ */
+protected Ignite getIgnite() {
+return ignite;
+}
+
+/**
+ * Close ignite instance
+ */
+public void closeIgnite() {
+if (ignite != null) {
+getLogger().info("Closing ignite client");
+ignite.close();
+ignite = null;
+}
+}
+
+/**
+ * Initialize ignite instance
+ * @param context process context
+ */
+public void initializeIgnite(ProcessContext context) {
+
+if ( getIgnite() != null ) {
+getLogger().info("Ignite already initilaized");
--- End diff --

Typo. Also, do we want this with info level instead of debug? just asking 
in case we could have this message a lot...


---
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 #502: Nifi-1972 Apache Ignite Put Cache Processor

[pvillard31]

Github user pvillard31 commented on the issue:

https://github.com/apache/nifi/pull/502
  
@mans2singh I added some minor comments. You also need to add a NOTICE file 
for licensing aspects in the nar project (you may want to have a look to other 
processors).

I just tried to run the processor on my laptop with a local running Ignite 
instance (1.6.0). It seems to behave as expected. I didn't run into issues like 
I did the last time. Regarding the comments/suggestions you made, I'm not very 
familiar with Ignite and I am not the best one to judge. I think that once all 
remarks are addressed we can get this merged into master and see if changes are 
needed depending on how this processor is used.

However, regarding point 4 (logs) did you make any progress? I am not sure 
we want all the Ignite client logs into the NiFi log file.


---
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-2095) Introduce UI for managing Users & User Groups

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2095:
--

Github user asfgit closed the pull request at:

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


> Introduce UI for managing Users & User Groups
> -
>
> Key: NIFI-2095
> URL: https://issues.apache.org/jira/browse/NIFI-2095
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>Priority: Blocker
> Fix For: 1.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2168) Extension Repositories (aka Extension Registry) for Dynamically-loaded Extensions

[Matt Foley (JIRA)]

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

Matt Foley updated NIFI-2168:
-
Description: 
Enable repositories external to the NiFi deployment (aka "Extension Registry") 
and enable dynamically-loaded extensions from external repositories.

Please see the wiki for Design Proposal:
* 
https://cwiki.apache.org/confluence/display/NIFI/Extension+Repositories+%28aka+Extension+Registry%29+for+Dynamically-loaded+Extensions

Please see prototype implementation (or the beginnings of one) in github:
* https://github.com/PuspenduBanerjee/nifi/tree/NIFI-ExtRegistry


  was:
Enable repositories external to the NiFi deployment (aka "Extension Registry") 
and enable dynamically-loaded extensions from external repositories.

Please see the wiki for Design Proposal:
* 
https://cwiki.apache.org/confluence/display/NIFI/External+Repositories+%28aka+Extension+Registry%29+for+Dynamically-loaded+Extensions

Please see prototype implementation (or the beginnings of one) in github:
* https://github.com/PuspenduBanerjee/nifi/tree/NIFI-ExtRegistry



> Extension Repositories (aka Extension Registry) for Dynamically-loaded 
> Extensions
> -
>
> Key: NIFI-2168
> URL: https://issues.apache.org/jira/browse/NIFI-2168
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Matt Foley
>Assignee: Matt Foley
>
> Enable repositories external to the NiFi deployment (aka "Extension 
> Registry") and enable dynamically-loaded extensions from external 
> repositories.
> Please see the wiki for Design Proposal:
> * 
> https://cwiki.apache.org/confluence/display/NIFI/Extension+Repositories+%28aka+Extension+Registry%29+for+Dynamically-loaded+Extensions
> Please see prototype implementation (or the beginnings of one) in github:
> * https://github.com/PuspenduBanerjee/nifi/tree/NIFI-ExtRegistry



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (NIFI-2017) Root Group Port Transmission Icon is inaccurate

[Matt Gilman (JIRA)]

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

Matt Gilman edited comment on NIFI-2017 at 7/12/16 10:29 PM:
-

I believe this UI is accurately reflecting the component status being returned. 
There may be an issue with the transmission flag in the port status. 
[~markap14] thoughts?


was (Author: mcgilman):
I believe this UI is accurately reflecting the component status being returned. 
There may be an issue with that transmission flag in the port status. 
[~markap14] thoughts?

> Root Group Port Transmission Icon is inaccurate
> ---
>
> Key: NIFI-2017
> URL: https://issues.apache.org/jira/browse/NIFI-2017
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Matt Gilman
>Priority: Minor
> Fix For: 1.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2093) Clear state link on Component State window is hidden

[Koji Kawamura (JIRA)]

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

Koji Kawamura commented on NIFI-2093:
-

[~scottyaslan] Thanks, I noticed that and removed related fix using z-index 
from my PR. However, I noticed that component state filter is hidden by the 
state table when I tested. Please take a look at the screenshot attached to 
this issue. I hope that's an OBE, too.

> Clear state link on Component State window is hidden
> 
>
> Key: NIFI-2093
> URL: https://issues.apache.org/jira/browse/NIFI-2093
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 1.0.0
>Reporter: Koji Kawamura
>Assignee: Koji Kawamura
> Fix For: 1.0.0
>
> Attachments: ComponentState-ConsumeKafka.png, State filter is 
> hidden.png
>
>
> It seems that ComponentStateEntity should have accessPolicy so that 
> CanvasUtis.supportsModification() can handle whether the link is active or 
> not.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2225) Improvement to archetypes and version management

[Stephane Maarek (JIRA)]

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

Stephane Maarek updated NIFI-2225:
--
Description: 
Hi,

Just done writing my first processor and there are two things I think could be 
improved:
- The version number is defined in three pom.xml. I believe it should only be 
defined in the parent one and the children should inherit it (under the tag 
). This will decrease the number of changes that need to happen when a 
new version appears
- There should be a separate parameter for NiFi version vs processor version

I.e. the final nar would be:

processor-name...nar

  was:
Hi,

Just done writing my first processor and there are two things I think could be 
improved:
- The version number is defined in three pom.xml. I believe it should only be 
defined in the parent one and the children should inherit it (under the tag 
). This will decrease the number of changes that need to happen when a 
new version appears
- There should be a separate parameter for NiFi version vs processor version

I.e. the final nar would be:

nar-name...nar


> Improvement to archetypes and version management
> 
>
> Key: NIFI-2225
> URL: https://issues.apache.org/jira/browse/NIFI-2225
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 0.6.1
>Reporter: Stephane Maarek
>Priority: Minor
> Fix For: 1.0.0
>
>
> Hi,
> Just done writing my first processor and there are two things I think could 
> be improved:
> - The version number is defined in three pom.xml. I believe it should only be 
> defined in the parent one and the children should inherit it (under the tag 
> ). This will decrease the number of changes that need to happen when 
> a new version appears
> - There should be a separate parameter for NiFi version vs processor version
> I.e. the final nar would be:
> processor-name...nar



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-906) Docs do not display well on mobile/smaller res devices

[Koji Kawamura (JIRA)]

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

Koji Kawamura commented on NIFI-906:


[~joewitt] I've fixed the table layout to wrap text. Changed the place of 
toggle button, and fixed layout issue on Microsoft Edge. The PR is updated, 
please check that again.

Note, some of the layout issues you had before might be related to browser 
cache. I had similar issue when I switched from other branch. So please clear 
the cache beforehand, thanks!

> Docs do not display well on mobile/smaller res devices
> --
>
> Key: NIFI-906
> URL: https://issues.apache.org/jira/browse/NIFI-906
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Documentation & Website
>Affects Versions: 1.0.0
> Environment: Mobile, Small res devices
>Reporter: Joseph Witt
>Assignee: Koji Kawamura
> Fix For: 1.0.0
>
> Attachments: Screen Shot 2016-07-08 at 5.05.00 PM.png, Screen Shot 
> 2016-07-08 at 5.20.37 PM.png, pc-hide-list.png, pc.png, 
> screenshot-20160712-mobile.png, screenshot-20160712-pc-hide-list.png, 
> screenshot-20160712-pc.png, smartphone-hide-list.png, smartphone.png
>
>
> Tweet from @cyroxx
> @apachenifi Unfortunately, the docs (http://nifi.apache.org/docs.html ) are 
> not mobile-friendly, makes it hard to read about this interesting project
> https://twitter.com/cyroxx/status/637305973938483200



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-1152) StandardProcessSession and MockProcessSession should handle transfer to unregistered relationship correctly

[Joseph Witt (JIRA)]

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

Joseph Witt commented on NIFI-1152:
---

yep totally on same page now.  will have that addressed in PR shortly.

> StandardProcessSession and MockProcessSession should handle transfer to 
> unregistered relationship correctly
> ---
>
> Key: NIFI-1152
> URL: https://issues.apache.org/jira/browse/NIFI-1152
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Tools and Build
>Affects Versions: 1.0.0, 0.6.0, 0.7.0, 0.6.1
>Reporter: Mark Payne
>Assignee: Joseph Witt
>  Labels: beginner, newbie
> Fix For: 1.0.0
>
> Attachments: 
> 0001-Fix-for-NIFI-1838-NIFI-1152-Code-modification-for-ty.patch
>
>
> If a processor calls ProcessSession.transfer(flowFile, 
> NON_EXISTENT_RELATIONSHIP) the NiFi framework will throw a 
> FlowFileHandlingException. However, the Mock Framework simply allows it and 
> does not throw any sort of Exception. This needs to be addressed so that the 
> Mock framework functions the same way as the normal NiFi framework.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-1152) StandardProcessSession and MockProcessSession should handle transfer to unregistered relationship correctly

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-1152:
--

GitHub user joewitt opened a pull request:

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

NIFI-1152 NIFI-2117 Fixed standard session impl api adherance, mock session 
api adherance, corrected code and tests for script processors that had issues 
due to that process session bug



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

$ git pull https://github.com/joewitt/incubator-nifi NIFI-1152

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

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


commit cb5f09b4491c572708f8bf1d54f0d20a8964f091
Author: joewitt 
Date:   2016-07-13T03:16:19Z

NIFI-1152 NIFI-2117 Fixed standard session impl api adherance, mock session 
api adherance, corrected code and tests for script processors that had issues 
due to that process session bug




> StandardProcessSession and MockProcessSession should handle transfer to 
> unregistered relationship correctly
> ---
>
> Key: NIFI-1152
> URL: https://issues.apache.org/jira/browse/NIFI-1152
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Tools and Build
>Affects Versions: 1.0.0, 0.6.0, 0.7.0, 0.6.1
>Reporter: Mark Payne
>Assignee: Joseph Witt
>  Labels: beginner, newbie
> Fix For: 1.0.0
>
> Attachments: 
> 0001-Fix-for-NIFI-1838-NIFI-1152-Code-modification-for-ty.patch
>
>
> If a processor calls ProcessSession.transfer(flowFile, 
> NON_EXISTENT_RELATIONSHIP) the NiFi framework will throw a 
> FlowFileHandlingException. However, the Mock Framework simply allows it and 
> does not throw any sort of Exception. This needs to be addressed so that the 
> Mock framework functions the same way as the normal NiFi framework.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2140) Update preview image for Change Color dialog

[ASF subversion and git services (JIRA)]

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

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

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

[NIFI-2205] Update Cluster Shell
[NIFI-2217] fix single node and cluster link
[NIFI-2219] Fix styles on provenance cluster search combo
[NIFI-2180] Fix settings shell table text alignment for run status
[NIFI-2140] Update preview image for Change Color dialog
[NIFI-2131] update progress bars/percent complete to use angular material 
progress linear directive
[NIFI-2099] add header text to all ok and yes/no dialogs
[NIFI-2233] fix invalid/warning icon shifts position as tasks are added
[NIFI-2131] update progress bars/percent complete
[NIFI-2140] Update preview image for label. This closes #627


> Update preview image for Change Color dialog
> 
>
> Key: NIFI-2140
> URL: https://issues.apache.org/jira/browse/NIFI-2140
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Rob Moran
>Assignee: Scott Aslan
> Attachments: nifi-2140_change-color-dialog.png
>
>
> Let's try using just the processor icon (icon-processor) for the preview 
> since it accepts the color change. It can be larger – something like 64px.
> Default is {code}fill:rgb(173, 152, 151){code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2233) Reporting Tasks table – invalid/warning icon shifts position as tasks are added

[ASF subversion and git services (JIRA)]

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

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

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

[NIFI-2205] Update Cluster Shell
[NIFI-2217] fix single node and cluster link
[NIFI-2219] Fix styles on provenance cluster search combo
[NIFI-2180] Fix settings shell table text alignment for run status
[NIFI-2140] Update preview image for Change Color dialog
[NIFI-2131] update progress bars/percent complete to use angular material 
progress linear directive
[NIFI-2099] add header text to all ok and yes/no dialogs
[NIFI-2233] fix invalid/warning icon shifts position as tasks are added
[NIFI-2131] update progress bars/percent complete
[NIFI-2140] Update preview image for label. This closes #627


> Reporting Tasks table – invalid/warning icon shifts position as tasks are 
> added
> ---
>
> Key: NIFI-2233
> URL: https://issues.apache.org/jira/browse/NIFI-2233
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Rob Moran
>Assignee: Scott Aslan
>Priority: Minor
> Attachments: reporting-task-added-2.png, reporting-tasked-added-1.png
>
>
> See attached screenshots:
> # First task added with icon at right-most position (reporting-tasked-added-1)
> # Second task added, icon shifts to middle position (reporting-tasked-added-2)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #627: [NIFI-2205] [NIFI-2217] [NIFI-2219] [NIFI-2180] [NIFI-2140]...

[mcgilman]

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/627
  
Thanks @scottyaslan. 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] [Commented] (NIFI-1152) StandardProcessSession and MockProcessSession should handle transfer to unregistered relationship correctly

[Joseph Witt (JIRA)]

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

Joseph Witt commented on NIFI-1152:
---

[~mattyb149] can you please review the script processor updates.
[~markap14] can you please review the process session impl corrections.
[~puspendu.baner...@gmail.com] i believe pr639 builds on your findings, 
addresses the root cause, and honors the intent of script procs.  Please take a 
look if you can and let me know if you see any issues.

> StandardProcessSession and MockProcessSession should handle transfer to 
> unregistered relationship correctly
> ---
>
> Key: NIFI-1152
> URL: https://issues.apache.org/jira/browse/NIFI-1152
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Tools and Build
>Affects Versions: 1.0.0, 0.6.0, 0.7.0, 0.6.1
>Reporter: Mark Payne
>Assignee: Joseph Witt
>  Labels: beginner, newbie
> Fix For: 1.0.0
>
> Attachments: 
> 0001-Fix-for-NIFI-1838-NIFI-1152-Code-modification-for-ty.patch
>
>
> If a processor calls ProcessSession.transfer(flowFile, 
> NON_EXISTENT_RELATIONSHIP) the NiFi framework will throw a 
> FlowFileHandlingException. However, the Mock Framework simply allows it and 
> does not throw any sort of Exception. This needs to be addressed so that the 
> Mock framework functions the same way as the normal NiFi framework.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2182) Processor's Active Thread Count no longer shown in UI

[Matt Gilman (JIRA)]

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

Matt Gilman updated NIFI-2182:
--
Status: Patch Available  (was: In Progress)

> Processor's Active Thread Count no longer shown in UI
> -
>
> Key: NIFI-2182
> URL: https://issues.apache.org/jira/browse/NIFI-2182
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Affects Versions: 1.0.0
>Reporter: Mark Payne
>Assignee: Matt Gilman
>Priority: Blocker
> Fix For: 1.0.0
>
>
> The UI no longer shows the number of active threads that a processor is 
> using. To replicate, create a GenerateFlowFile processor and configure it to 
> create 1 MB flowfiles. Then route to a CompressContent processor. Configure 
> CompressContent to use GZIP compression with a compression level of 9. This 
> will ensure that Compress Content is not able to keep up with 
> GenerateFlowFile, so it should always have active threads. Start both 
> processors and notice that neither shows any active threads.
> I have not tried testing this in standalone mode, only in clustered mode.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-1152) StandardProcessSession and MockProcessSession should handle transfer to unregistered relationship correctly

[Joseph Witt (JIRA)]

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

Joseph Witt commented on NIFI-1152:
---

Ok now as I read further it does appear it was intended that these default 
relationships be there only if others are not provided.  There was a test 
script file using the wrong relationship which has now been corrected and 
another test which was failing because of a bug in the invokescriptprocessor 
itself which is now corrected as well.  Will update the documentation to 
reflect this behavior and submit the PR.

> StandardProcessSession and MockProcessSession should handle transfer to 
> unregistered relationship correctly
> ---
>
> Key: NIFI-1152
> URL: https://issues.apache.org/jira/browse/NIFI-1152
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Tools and Build
>Affects Versions: 1.0.0, 0.6.0, 0.7.0, 0.6.1
>Reporter: Mark Payne
>Assignee: Joseph Witt
>  Labels: beginner, newbie
> Fix For: 1.0.0
>
> Attachments: 
> 0001-Fix-for-NIFI-1838-NIFI-1152-Code-modification-for-ty.patch
>
>
> If a processor calls ProcessSession.transfer(flowFile, 
> NON_EXISTENT_RELATIONSHIP) the NiFi framework will throw a 
> FlowFileHandlingException. However, the Mock Framework simply allows it and 
> does not throw any sort of Exception. This needs to be addressed so that the 
> Mock framework functions the same way as the normal NiFi framework.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2232) UI - Support dynamic updating of user's permissions to items in Global Menu

[Matt Gilman (JIRA)]

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

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

> UI - Support dynamic updating of user's permissions to items in Global Menu
> ---
>
> Key: NIFI-2232
> URL: https://issues.apache.org/jira/browse/NIFI-2232
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core UI
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>Priority: Blocker
> Fix For: 1.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #483: NIFI-1899 - Introduce ExtractEmailAttachments and Ex...

[JPercivall]

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

https://github.com/apache/nifi/pull/483#discussion_r70562091
  
--- Diff: 
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/smtp/handler/SMTPMessageHandlerFactory.java
 ---
@@ -0,0 +1,147 @@
+/*
+ * 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.processors.email.smtp.handler;
+
+import java.io.IOException;
+import java.io.InputStream;
+import java.security.cert.X509Certificate;
+import java.util.concurrent.LinkedBlockingQueue;
+import java.util.concurrent.TimeUnit;
+
+import org.apache.nifi.logging.ComponentLog;
+import org.apache.nifi.stream.io.ByteArrayOutputStream;
+import org.apache.nifi.util.StopWatch;
+import org.subethamail.smtp.DropConnectionException;
+import org.subethamail.smtp.MessageContext;
+import org.subethamail.smtp.MessageHandler;
+import org.subethamail.smtp.MessageHandlerFactory;
+import org.subethamail.smtp.RejectException;
+import org.subethamail.smtp.TooMuchDataException;
+import org.subethamail.smtp.server.SMTPServer;
+
+import org.apache.nifi.processors.email.smtp.event.SmtpEvent;
+
+
+public class SMTPMessageHandlerFactory implements MessageHandlerFactory {
+final LinkedBlockingQueue incomingMessages;
+final ComponentLog logger;
+
+public SMTPMessageHandlerFactory(LinkedBlockingQueue 
incomingMessages, ComponentLog logger) {
+this.incomingMessages = incomingMessages;
+this.logger = logger;
+}
+
+@Override
+public MessageHandler create(MessageContext messageContext) {
+return new Handler(messageContext, incomingMessages, logger);
+}
+
+class Handler implements MessageHandler {
+final MessageContext messageContext;
+String from;
+String recipient;
+byte [] messageBody;
+
+
+public Handler(MessageContext messageContext, 
LinkedBlockingQueue incomingMessages, ComponentLog logger){
+this.messageContext = messageContext;
+}
+
+@Override
+public void from(String from) throws RejectException {
+// TODO: possibly whitelist senders?
+this.from = from;
+}
+
+@Override
+public void recipient(String recipient) throws RejectException {
+// TODO: possibly whitelist receivers?
+this.recipient = recipient;
+}
+
+@Override
+public void data(InputStream inputStream) throws RejectException, 
TooMuchDataException, IOException {
+// Start counting the timer...
+
+StopWatch watch = new StopWatch(false);
+
+SMTPServer server = messageContext.getSMTPServer();
+
+ByteArrayOutputStream baos = new ByteArrayOutputStream();
+
+byte [] buffer = new byte[1024];
+int rd;
+
+while ((rd = inputStream.read(buffer, 0, buffer.length)) != 
-1) {
+baos.write(buffer, 0, rd);
+}
+if (baos.getBufferLength() > server.getMaxMessageSize()) {
+throw new TooMuchDataException("Data exceeds the amount 
allowed.");
+}
+
+baos.flush();
+this.messageBody = baos.toByteArray();
+
+
+X509Certificate[] certificates = new X509Certificate[]{};
+
+String remoteIP = messageContext.getRemoteAddress().toString();
+String helo = messageContext.getHelo();
+if (messageContext.getTlsPeerCertificates() != null ){
+certificates = (X509Certificate[]) 
messageContext.getTlsPeerCertificates().clone();
+}
+
+SmtpEvent message = new SmtpEvent(remoteIP, helo, from, 
recipient, certificates, messageBody);
+try {
+

[jira] [Commented] (NIFI-1899) Create ListenSMTP & ExtractEmailAttachment processors

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-1899:
--

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

https://github.com/apache/nifi/pull/483#discussion_r70562091
  
--- Diff: 
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/smtp/handler/SMTPMessageHandlerFactory.java
 ---
@@ -0,0 +1,147 @@
+/*
+ * 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.processors.email.smtp.handler;
+
+import java.io.IOException;
+import java.io.InputStream;
+import java.security.cert.X509Certificate;
+import java.util.concurrent.LinkedBlockingQueue;
+import java.util.concurrent.TimeUnit;
+
+import org.apache.nifi.logging.ComponentLog;
+import org.apache.nifi.stream.io.ByteArrayOutputStream;
+import org.apache.nifi.util.StopWatch;
+import org.subethamail.smtp.DropConnectionException;
+import org.subethamail.smtp.MessageContext;
+import org.subethamail.smtp.MessageHandler;
+import org.subethamail.smtp.MessageHandlerFactory;
+import org.subethamail.smtp.RejectException;
+import org.subethamail.smtp.TooMuchDataException;
+import org.subethamail.smtp.server.SMTPServer;
+
+import org.apache.nifi.processors.email.smtp.event.SmtpEvent;
+
+
+public class SMTPMessageHandlerFactory implements MessageHandlerFactory {
+final LinkedBlockingQueue incomingMessages;
+final ComponentLog logger;
+
+public SMTPMessageHandlerFactory(LinkedBlockingQueue 
incomingMessages, ComponentLog logger) {
+this.incomingMessages = incomingMessages;
+this.logger = logger;
+}
+
+@Override
+public MessageHandler create(MessageContext messageContext) {
+return new Handler(messageContext, incomingMessages, logger);
+}
+
+class Handler implements MessageHandler {
+final MessageContext messageContext;
+String from;
+String recipient;
+byte [] messageBody;
+
+
+public Handler(MessageContext messageContext, 
LinkedBlockingQueue incomingMessages, ComponentLog logger){
+this.messageContext = messageContext;
+}
+
+@Override
+public void from(String from) throws RejectException {
+// TODO: possibly whitelist senders?
+this.from = from;
+}
+
+@Override
+public void recipient(String recipient) throws RejectException {
+// TODO: possibly whitelist receivers?
+this.recipient = recipient;
+}
+
+@Override
+public void data(InputStream inputStream) throws RejectException, 
TooMuchDataException, IOException {
+// Start counting the timer...
+
+StopWatch watch = new StopWatch(false);
+
+SMTPServer server = messageContext.getSMTPServer();
+
+ByteArrayOutputStream baos = new ByteArrayOutputStream();
+
+byte [] buffer = new byte[1024];
+int rd;
+
+while ((rd = inputStream.read(buffer, 0, buffer.length)) != 
-1) {
+baos.write(buffer, 0, rd);
+}
+if (baos.getBufferLength() > server.getMaxMessageSize()) {
+throw new TooMuchDataException("Data exceeds the amount 
allowed.");
+}
+
+baos.flush();
+this.messageBody = baos.toByteArray();
+
+
+X509Certificate[] certificates = new X509Certificate[]{};
+
+String remoteIP = messageContext.getRemoteAddress().toString();
+String helo = messageContext.getHelo();
+if (messageContext.getTlsPeerCertificates() != null ){
+certificates = 

[jira] [Commented] (NIFI-1899) Create ListenSMTP & ExtractEmailAttachment processors

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-1899:
--

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

https://github.com/apache/nifi/pull/483#discussion_r70565378
  
--- Diff: 
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/smtp/handler/SMTPMessageHandlerFactory.java
 ---
@@ -0,0 +1,147 @@
+/*
+ * 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.processors.email.smtp.handler;
+
+import java.io.IOException;
+import java.io.InputStream;
+import java.security.cert.X509Certificate;
+import java.util.concurrent.LinkedBlockingQueue;
+import java.util.concurrent.TimeUnit;
+
+import org.apache.nifi.logging.ComponentLog;
+import org.apache.nifi.stream.io.ByteArrayOutputStream;
+import org.apache.nifi.util.StopWatch;
+import org.subethamail.smtp.DropConnectionException;
+import org.subethamail.smtp.MessageContext;
+import org.subethamail.smtp.MessageHandler;
+import org.subethamail.smtp.MessageHandlerFactory;
+import org.subethamail.smtp.RejectException;
+import org.subethamail.smtp.TooMuchDataException;
+import org.subethamail.smtp.server.SMTPServer;
+
+import org.apache.nifi.processors.email.smtp.event.SmtpEvent;
+
+
+public class SMTPMessageHandlerFactory implements MessageHandlerFactory {
+final LinkedBlockingQueue incomingMessages;
+final ComponentLog logger;
+
+public SMTPMessageHandlerFactory(LinkedBlockingQueue 
incomingMessages, ComponentLog logger) {
+this.incomingMessages = incomingMessages;
+this.logger = logger;
+}
+
+@Override
+public MessageHandler create(MessageContext messageContext) {
+return new Handler(messageContext, incomingMessages, logger);
+}
+
+class Handler implements MessageHandler {
+final MessageContext messageContext;
+String from;
+String recipient;
+byte [] messageBody;
+
+
+public Handler(MessageContext messageContext, 
LinkedBlockingQueue incomingMessages, ComponentLog logger){
+this.messageContext = messageContext;
+}
+
+@Override
+public void from(String from) throws RejectException {
+// TODO: possibly whitelist senders?
+this.from = from;
+}
+
+@Override
+public void recipient(String recipient) throws RejectException {
+// TODO: possibly whitelist receivers?
+this.recipient = recipient;
+}
+
+@Override
+public void data(InputStream inputStream) throws RejectException, 
TooMuchDataException, IOException {
+// Start counting the timer...
+
+StopWatch watch = new StopWatch(false);
+
+SMTPServer server = messageContext.getSMTPServer();
+
+ByteArrayOutputStream baos = new ByteArrayOutputStream();
+
+byte [] buffer = new byte[1024];
+int rd;
+
+while ((rd = inputStream.read(buffer, 0, buffer.length)) != 
-1) {
+baos.write(buffer, 0, rd);
+}
+if (baos.getBufferLength() > server.getMaxMessageSize()) {
+throw new TooMuchDataException("Data exceeds the amount 
allowed.");
+}
+
+baos.flush();
+this.messageBody = baos.toByteArray();
+
+
+X509Certificate[] certificates = new X509Certificate[]{};
+
+String remoteIP = messageContext.getRemoteAddress().toString();
+String helo = messageContext.getHelo();
+if (messageContext.getTlsPeerCertificates() != null ){
+certificates = 

[GitHub] nifi issue #564: NIFI-2020 - Enhance JoltTransformJSON processor to support ...

[mattyb149]

Github user mattyb149 commented on the issue:

https://github.com/apache/nifi/pull/564
  
I had forgotten about the checked exception thing. If the lamdbas/streams 
are just as awkward as Java 7 code (due to the exceptions, etc.) then there's 
probably no need to force it.  Everything else looks good, I still need to 
build and run it, but if you anticipate another change I can wait for that 
(might as well rebase then too)


---
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-1152) StandardProcessSession and MockProcessSession should handle transfer to unregistered relationship correctly

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-1152:
--

GitHub user joewitt opened a pull request:

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

NIFI-1152 NIFI-2117 Fixed standard session impl api adherance, mock session 
api adherance, corrected code and tests for script processors that had issues 
due to that process session bug



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

$ git pull https://github.com/joewitt/incubator-nifi NIFI-1152

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

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


commit 05a0bf84970183afbce4d39bc34047fb2951ce89
Author: joewitt 
Date:   2016-07-13T02:20:33Z

NIFI-1152 NIFI-2117 Fixed standard session impl api adherance, mock session 
api adherance, corrected code and tests for script processors that had issues 
due to that process session bug




> StandardProcessSession and MockProcessSession should handle transfer to 
> unregistered relationship correctly
> ---
>
> Key: NIFI-1152
> URL: https://issues.apache.org/jira/browse/NIFI-1152
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Tools and Build
>Affects Versions: 1.0.0, 0.6.0, 0.7.0, 0.6.1
>Reporter: Mark Payne
>Assignee: Joseph Witt
>  Labels: beginner, newbie
> Fix For: 1.0.0
>
> Attachments: 
> 0001-Fix-for-NIFI-1838-NIFI-1152-Code-modification-for-ty.patch
>
>
> If a processor calls ProcessSession.transfer(flowFile, 
> NON_EXISTENT_RELATIONSHIP) the NiFi framework will throw a 
> FlowFileHandlingException. However, the Mock Framework simply allows it and 
> does not throw any sort of Exception. This needs to be addressed so that the 
> Mock framework functions the same way as the normal NiFi framework.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #638: NIFI-1152 NIFI-2117 Fixed standard session impl api ...

[joewitt]

GitHub user joewitt opened a pull request:

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

NIFI-1152 NIFI-2117 Fixed standard session impl api adherance, mock session 
api adherance, corrected code and tests for script processors that had issues 
due to that process session bug



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

$ git pull https://github.com/joewitt/incubator-nifi NIFI-1152

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

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


commit 05a0bf84970183afbce4d39bc34047fb2951ce89
Author: joewitt 
Date:   2016-07-13T02:20:33Z

NIFI-1152 NIFI-2117 Fixed standard session impl api adherance, mock session 
api adherance, corrected code and tests for script processors that had issues 
due to that process session bug




---
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-1152) StandardProcessSession and MockProcessSession should handle transfer to unregistered relationship correctly

[Joseph Witt (JIRA)]

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

Joseph Witt updated NIFI-1152:
--
Status: Patch Available  (was: In Progress)

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

> StandardProcessSession and MockProcessSession should handle transfer to 
> unregistered relationship correctly
> ---
>
> Key: NIFI-1152
> URL: https://issues.apache.org/jira/browse/NIFI-1152
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Tools and Build
>Affects Versions: 0.6.1, 0.7.0, 0.6.0, 1.0.0
>Reporter: Mark Payne
>Assignee: Joseph Witt
>  Labels: beginner, newbie
> Fix For: 1.0.0
>
> Attachments: 
> 0001-Fix-for-NIFI-1838-NIFI-1152-Code-modification-for-ty.patch
>
>
> If a processor calls ProcessSession.transfer(flowFile, 
> NON_EXISTENT_RELATIONSHIP) the NiFi framework will throw a 
> FlowFileHandlingException. However, the Mock Framework simply allows it and 
> does not throw any sort of Exception. This needs to be addressed so that the 
> Mock framework functions the same way as the normal NiFi framework.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2205) Filter components / border not rendered properly in the Cluster dialog

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2205:
--

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/627
  
Thanks @scottyaslan. This has been merged to master.


> Filter components / border not rendered properly in the Cluster dialog
> --
>
> Key: NIFI-2205
> URL: https://issues.apache.org/jira/browse/NIFI-2205
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Affects Versions: 1.0.0
>Reporter: Mark Payne
>Assignee: Scott Aslan
> Fix For: 1.0.0
>
> Attachments: screenshot-1.png
>
>
> When I go to the "Cluster" dialog, I see that the filter boxes are hidden 
> behind the table and there is no border around the dialog.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2180) controller services/reporting tasks text alignment

[ASF subversion and git services (JIRA)]

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

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

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

[NIFI-2205] Update Cluster Shell
[NIFI-2217] fix single node and cluster link
[NIFI-2219] Fix styles on provenance cluster search combo
[NIFI-2180] Fix settings shell table text alignment for run status
[NIFI-2140] Update preview image for Change Color dialog
[NIFI-2131] update progress bars/percent complete to use angular material 
progress linear directive
[NIFI-2099] add header text to all ok and yes/no dialogs
[NIFI-2233] fix invalid/warning icon shifts position as tasks are added
[NIFI-2131] update progress bars/percent complete
[NIFI-2140] Update preview image for label. This closes #627


> controller services/reporting tasks text alignment
> --
>
> Key: NIFI-2180
> URL: https://issues.apache.org/jira/browse/NIFI-2180
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Scott Aslan
>Assignee: Scott Aslan
>
> controller services/reporting tasks slick grid state col text wraps to new 
> line and should not like in the summary grid



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2131) update progress bars/percent complete

[ASF subversion and git services (JIRA)]

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

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

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

[NIFI-2205] Update Cluster Shell
[NIFI-2217] fix single node and cluster link
[NIFI-2219] Fix styles on provenance cluster search combo
[NIFI-2180] Fix settings shell table text alignment for run status
[NIFI-2140] Update preview image for Change Color dialog
[NIFI-2131] update progress bars/percent complete to use angular material 
progress linear directive
[NIFI-2099] add header text to all ok and yes/no dialogs
[NIFI-2233] fix invalid/warning icon shifts position as tasks are added
[NIFI-2131] update progress bars/percent complete
[NIFI-2140] Update preview image for label. This closes #627


> update progress bars/percent complete
> -
>
> Key: NIFI-2131
> URL: https://issues.apache.org/jira/browse/NIFI-2131
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Scott Aslan
>Assignee: Scott Aslan
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #483: NIFI-1899 - Introduce ExtractEmailAttachments and Ex...

[JPercivall]

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

https://github.com/apache/nifi/pull/483#discussion_r70561030
  
--- Diff: 
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/smtp/handler/SMTPMessageHandlerFactory.java
 ---
@@ -0,0 +1,147 @@
+/*
+ * 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.processors.email.smtp.handler;
+
+import java.io.IOException;
+import java.io.InputStream;
+import java.security.cert.X509Certificate;
+import java.util.concurrent.LinkedBlockingQueue;
+import java.util.concurrent.TimeUnit;
+
+import org.apache.nifi.logging.ComponentLog;
+import org.apache.nifi.stream.io.ByteArrayOutputStream;
+import org.apache.nifi.util.StopWatch;
+import org.subethamail.smtp.DropConnectionException;
+import org.subethamail.smtp.MessageContext;
+import org.subethamail.smtp.MessageHandler;
+import org.subethamail.smtp.MessageHandlerFactory;
+import org.subethamail.smtp.RejectException;
+import org.subethamail.smtp.TooMuchDataException;
+import org.subethamail.smtp.server.SMTPServer;
+
+import org.apache.nifi.processors.email.smtp.event.SmtpEvent;
+
+
+public class SMTPMessageHandlerFactory implements MessageHandlerFactory {
+final LinkedBlockingQueue incomingMessages;
+final ComponentLog logger;
+
+public SMTPMessageHandlerFactory(LinkedBlockingQueue 
incomingMessages, ComponentLog logger) {
+this.incomingMessages = incomingMessages;
+this.logger = logger;
+}
+
+@Override
+public MessageHandler create(MessageContext messageContext) {
+return new Handler(messageContext, incomingMessages, logger);
+}
+
+class Handler implements MessageHandler {
+final MessageContext messageContext;
+String from;
+String recipient;
+byte [] messageBody;
+
+
+public Handler(MessageContext messageContext, 
LinkedBlockingQueue incomingMessages, ComponentLog logger){
+this.messageContext = messageContext;
+}
+
+@Override
+public void from(String from) throws RejectException {
+// TODO: possibly whitelist senders?
+this.from = from;
+}
+
+@Override
+public void recipient(String recipient) throws RejectException {
+// TODO: possibly whitelist receivers?
+this.recipient = recipient;
+}
+
+@Override
+public void data(InputStream inputStream) throws RejectException, 
TooMuchDataException, IOException {
+// Start counting the timer...
+
+StopWatch watch = new StopWatch(false);
+
+SMTPServer server = messageContext.getSMTPServer();
+
+ByteArrayOutputStream baos = new ByteArrayOutputStream();
+
+byte [] buffer = new byte[1024];
+int rd;
+
+while ((rd = inputStream.read(buffer, 0, buffer.length)) != 
-1) {
+baos.write(buffer, 0, rd);
+}
+if (baos.getBufferLength() > server.getMaxMessageSize()) {
+throw new TooMuchDataException("Data exceeds the amount 
allowed.");
+}
+
+baos.flush();
+this.messageBody = baos.toByteArray();
--- End diff --

This doesn't address passing a stream instead of bytes. The 
ByteArrayOutputStream is backed by a byte array[1] so it's getting copied into 
memory anyway. I'm suggesting to pass the InputStream itself so that in the 
onTrigger you can just stream it from input to the content.

[1] 
https://docs.oracle.com/javase/7/docs/api/java/io/ByteArrayOutputStream.html


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

[GitHub] nifi pull request #634: [NIFI-2182] [NIFI-2019] [NIFI-2183]

[mcgilman]

GitHub user mcgilman opened a pull request:

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

[NIFI-2182] [NIFI-2019] [NIFI-2183]

NIFI-2182:
- Ensuring the active thread count is shown.

NIFI-2019:
- Ensuring correct color of the run status in the From connection label.

NIFI-2183:
- Removing the DownloadSvg servlet and hidding the download icon until 
we're able to support saving the svg entirely from the client side.

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

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

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

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


commit d21ea4cd5b5aafd4972bd17f9778477016cb75ea
Author: Matt Gilman 
Date:   2016-07-12T23:24:11Z

NIFI-2182:
- Ensuring the active thread count is shown.
NIFI-2019:
- Ensuring correct color of the run status in the From connection label.
NIFI-2183:
- Removing the DownloadSvg servlet and hidding the download icon until 
we're able to support save the svg entirely from the client side.




---
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] [Created] (NIFI-2249) Move URI into ComponentEntity from ComponentDTO

[Matt Gilman (JIRA)]

Matt Gilman created NIFI-2249:
-

 Summary: Move URI into ComponentEntity from ComponentDTO
 Key: NIFI-2249
 URL: https://issues.apache.org/jira/browse/NIFI-2249
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework, Core UI
Reporter: Matt Gilman
Assignee: Matt Gilman
Priority: Blocker
 Fix For: 1.0.0


The URI needs to be moved out of the ComponentDTO and into the ComponentEntity. 
This change is necessary for cases when the user does not have permission to 
the underlying ComponentDTO.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-1152) StandardProcessSession and MockProcessSession should handle transfer to unregistered relationship correctly

[Matt Burgess (JIRA)]

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

Matt Burgess commented on NIFI-1152:


Including the default relationships for InvokeScriptedProcessor was an 
oversight on my part (i.e. cut-and-paste error from ExecuteScript). No default 
relationships should be supplied by InvokeScriptedProcessor if none are given 
by the scripted processor (or if there is an error in the script itself). 
Otherwise the scripted processor would be using provided relationships, which 
is inconsistent with all other processors ("real" processors must provide their 
own). The idea behind InvokeScriptedProcessor is that the script defines a 
"full" Processor implementation that acts as if it were a "real" one.

I think the relationships should be removed and the doc updated to reflect 
that.  Just my two cents :)

> StandardProcessSession and MockProcessSession should handle transfer to 
> unregistered relationship correctly
> ---
>
> Key: NIFI-1152
> URL: https://issues.apache.org/jira/browse/NIFI-1152
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Tools and Build
>Affects Versions: 1.0.0, 0.6.0, 0.7.0, 0.6.1
>Reporter: Mark Payne
>Assignee: Joseph Witt
>  Labels: beginner, newbie
> Fix For: 1.0.0
>
> Attachments: 
> 0001-Fix-for-NIFI-1838-NIFI-1152-Code-modification-for-ty.patch
>
>
> If a processor calls ProcessSession.transfer(flowFile, 
> NON_EXISTENT_RELATIONSHIP) the NiFi framework will throw a 
> FlowFileHandlingException. However, the Mock Framework simply allows it and 
> does not throw any sort of Exception. This needs to be addressed so that the 
> Mock framework functions the same way as the normal NiFi framework.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #637: NIFI-1152 NIFI-2117 Fixed standard session impl api ...

[joewitt]

GitHub user joewitt opened a pull request:

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

NIFI-1152 NIFI-2117 Fixed standard session impl api adherance, mock session 
api adherance, corrected code and tests for script processors that had issues 
due to that process session bug



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

$ git pull https://github.com/joewitt/incubator-nifi NIFI-1152

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

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


commit cf20bb18e87d5847b4307169ddf0157f27dede47
Author: joewitt 
Date:   2016-07-13T02:20:33Z

NIFI-1152 NIFI-2117 Fixed standard session impl api adherance, mock session 
api adherance, corrected code and tests for script processors that had issues 
due to that process session bug




---
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-1899) Create ListenSMTP & ExtractEmailAttachment processors

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-1899:
--

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

https://github.com/apache/nifi/pull/483#discussion_r70561030
  
--- Diff: 
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/smtp/handler/SMTPMessageHandlerFactory.java
 ---
@@ -0,0 +1,147 @@
+/*
+ * 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.processors.email.smtp.handler;
+
+import java.io.IOException;
+import java.io.InputStream;
+import java.security.cert.X509Certificate;
+import java.util.concurrent.LinkedBlockingQueue;
+import java.util.concurrent.TimeUnit;
+
+import org.apache.nifi.logging.ComponentLog;
+import org.apache.nifi.stream.io.ByteArrayOutputStream;
+import org.apache.nifi.util.StopWatch;
+import org.subethamail.smtp.DropConnectionException;
+import org.subethamail.smtp.MessageContext;
+import org.subethamail.smtp.MessageHandler;
+import org.subethamail.smtp.MessageHandlerFactory;
+import org.subethamail.smtp.RejectException;
+import org.subethamail.smtp.TooMuchDataException;
+import org.subethamail.smtp.server.SMTPServer;
+
+import org.apache.nifi.processors.email.smtp.event.SmtpEvent;
+
+
+public class SMTPMessageHandlerFactory implements MessageHandlerFactory {
+final LinkedBlockingQueue incomingMessages;
+final ComponentLog logger;
+
+public SMTPMessageHandlerFactory(LinkedBlockingQueue 
incomingMessages, ComponentLog logger) {
+this.incomingMessages = incomingMessages;
+this.logger = logger;
+}
+
+@Override
+public MessageHandler create(MessageContext messageContext) {
+return new Handler(messageContext, incomingMessages, logger);
+}
+
+class Handler implements MessageHandler {
+final MessageContext messageContext;
+String from;
+String recipient;
+byte [] messageBody;
+
+
+public Handler(MessageContext messageContext, 
LinkedBlockingQueue incomingMessages, ComponentLog logger){
+this.messageContext = messageContext;
+}
+
+@Override
+public void from(String from) throws RejectException {
+// TODO: possibly whitelist senders?
+this.from = from;
+}
+
+@Override
+public void recipient(String recipient) throws RejectException {
+// TODO: possibly whitelist receivers?
+this.recipient = recipient;
+}
+
+@Override
+public void data(InputStream inputStream) throws RejectException, 
TooMuchDataException, IOException {
+// Start counting the timer...
+
+StopWatch watch = new StopWatch(false);
+
+SMTPServer server = messageContext.getSMTPServer();
+
+ByteArrayOutputStream baos = new ByteArrayOutputStream();
+
+byte [] buffer = new byte[1024];
+int rd;
+
+while ((rd = inputStream.read(buffer, 0, buffer.length)) != 
-1) {
+baos.write(buffer, 0, rd);
+}
+if (baos.getBufferLength() > server.getMaxMessageSize()) {
+throw new TooMuchDataException("Data exceeds the amount 
allowed.");
+}
+
+baos.flush();
+this.messageBody = baos.toByteArray();
--- End diff --

This doesn't address passing a stream instead of bytes. The 
ByteArrayOutputStream is backed by a byte array[1] so it's getting copied into 
memory anyway. I'm suggesting to pass the InputStream itself so that in the 
onTrigger you can just stream it from input to the content.

[1] 

[GitHub] nifi pull request #483: NIFI-1899 - Introduce ExtractEmailAttachments and Ex...

[JPercivall]

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

https://github.com/apache/nifi/pull/483#discussion_r70561569
  
--- Diff: 
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/smtp/handler/SMTPMessageHandlerFactory.java
 ---
@@ -0,0 +1,155 @@
+/*
+ * 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.processors.email.smtp.handler;
+
+import java.io.IOException;
+import java.io.InputStream;
+import java.security.cert.X509Certificate;
+import java.util.concurrent.CountDownLatch;
+import java.util.concurrent.LinkedBlockingQueue;
+import java.util.concurrent.TimeUnit;
+
+import org.apache.nifi.logging.ComponentLog;
+import org.apache.nifi.stream.io.ByteArrayOutputStream;
+import org.apache.nifi.util.StopWatch;
+import org.subethamail.smtp.DropConnectionException;
+import org.subethamail.smtp.MessageContext;
+import org.subethamail.smtp.MessageHandler;
+import org.subethamail.smtp.MessageHandlerFactory;
+import org.subethamail.smtp.RejectException;
+import org.subethamail.smtp.TooMuchDataException;
+import org.subethamail.smtp.server.SMTPServer;
+
+import org.apache.nifi.processors.email.smtp.event.SmtpEvent;
+
+
+public class SMTPMessageHandlerFactory implements MessageHandlerFactory {
+final LinkedBlockingQueue incomingMessages;
+final ComponentLog logger;
+private CountDownLatch latch;
+
+public SMTPMessageHandlerFactory(LinkedBlockingQueue 
incomingMessages, ComponentLog logger) {
+this.incomingMessages = incomingMessages;
+this.logger = logger;
+this.latch =  new CountDownLatch(1);
+}
+
+@Override
+public MessageHandler create(MessageContext messageContext) {
+return new Handler(messageContext, incomingMessages, logger);
+}
+
+class Handler implements MessageHandler {
+final MessageContext messageContext;
+String from;
+String recipient;
+ByteArrayOutputStream messageData;
+
+public Handler(MessageContext messageContext, 
LinkedBlockingQueue incomingMessages, ComponentLog logger){
+this.messageContext = messageContext;
+}
+
+@Override
+public void from(String from) throws RejectException {
+// TODO: possibly whitelist senders?
+this.from = from;
+}
+
+@Override
+public void recipient(String recipient) throws RejectException {
+// TODO: possibly whitelist receivers?
+this.recipient = recipient;
+}
+
+@Override
+public void data(InputStream inputStream) throws RejectException, 
TooMuchDataException {
+// Start counting the timer...
+
+StopWatch watch = new StopWatch(true);
+
+SMTPServer server = messageContext.getSMTPServer();
+
+final long serverTimeout = 
TimeUnit.MILLISECONDS.convert(messageContext.getSMTPServer().getConnectionTimeout(),
 TimeUnit.MILLISECONDS);
+
+ByteArrayOutputStream baos = new ByteArrayOutputStream();
+
+byte [] buffer = new byte[1024];
+
+int rd;
+
+try {
+while ((rd = inputStream.read(buffer, 0, buffer.length)) 
!= -1 ) {
+baos.write(buffer, 0, rd);
+if (baos.getBufferLength() > 
server.getMaxMessageSize() ) {
+throw new TooMuchDataException("Data exceeds the 
amount allowed.");
+}
+}
+baos.flush();
+} catch (IOException e) {
+throw new DropConnectionException(450, "Unexpected error 
processing your message. ");
+}
+
+this.messageData = baos;
+
+X509Certificate[] certificates = new 

[GitHub] nifi pull request #575: NIFI-619: Make MonitorActivity more cluster friendly

[ijokarumawak]

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

https://github.com/apache/nifi/pull/575#discussion_r70437957
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/MonitorActivity.java
 ---
@@ -201,17 +253,57 @@ public void process(final OutputStream out) throws 
IOException {
 }
 } else {
 session.transfer(flowFiles, REL_SUCCESS);
+updatedLatestSuccessTransfer = now;
 logger.info("Transferred {} FlowFiles to 'success'", new 
Object[]{flowFiles.size()});
 
-final long inactivityStartMillis = 
latestSuccessTransfer.getAndSet(now);
+final long latestStateReportTimestamp = 
latestReportedNodeState.get();
+if (SCOPE_CLUSTER.equals(monitoringScope)
+&& (now - latestStateReportTimestamp) > 
(thresholdMillis / 3)) {
+// We don't want to hit the state manager every 
onTrigger(), but often enough to detect activeness.
+try {
+final StateManager stateManager = 
context.getStateManager();
+final StateMap state = 
stateManager.getState(Scope.CLUSTER);
+
+final Map newValues = new HashMap<>();
+
+// Persist attributes so that other nodes can copy it
+if (copyAttributes) {
+newValues.putAll(flowFiles.get(0).getAttributes());
+}
+newValues.put(STATE_KEY_LATEST_SUCCESS_TRANSFER, 
String.valueOf(now));
+
+if (state == null || state.getVersion() == -1) {
+stateManager.setState(newValues, Scope.CLUSTER);
+} else {
+// If this returns false due to race condition, 
it's not a problem since we just need
+// the latest active timestamp.
+stateManager.replace(state, newValues, 
Scope.CLUSTER);
--- End diff --

Thanks for catching this, I'll add code to check if the current timestamp 
is newer than the one stored in Zookeeper.

For retrying, I'd let NiFi scheduler and onTrigger() manage that, instead 
of adding a retry mechanism here, for simplicity and controllability. If it's 
trying to update state, it means that the node is active, so it will report 
correctly. The only problem I can imagine from not updating the state, is the 
possibility for other nodes to emit false alarms. But it's also inevitable if 
other nodes themselves are inactive and Zk is not working. If the issue is 
solved, further onTrigger() call will write state and it will work correctly 
eventually.


---
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 #628: NIFI-2003 Creating abstract authentication provider ...

[mcgilman]

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

https://github.com/apache/nifi/pull/628#discussion_r70423287
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-authorization/src/main/java/org/apache/nifi/authorization/user/StandardNiFiUser.java
 ---
@@ -23,18 +23,20 @@
  */
 public class StandardNiFiUser implements NiFiUser {
 
-public static final StandardNiFiUser ANONYMOUS = new 
StandardNiFiUser("anonymous");
+public static final StandardNiFiUser ANONYMOUS = new 
StandardNiFiUser("anonymous", null);
 
 private final String identity;
 private final NiFiUser chain;
+private final String clientAddress;
 
-public StandardNiFiUser(String identity) {
-this(identity, null);
+public StandardNiFiUser(String identity, String clientAddress) {
--- End diff --

Should we offer another constructor for when we don't have a client address?


---
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-2003) User Identity Normalization

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2003:
--

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

https://github.com/apache/nifi/pull/628#discussion_r70422981
  
--- Diff: 
nifi-api/src/main/java/org/apache/nifi/authorization/resource/Authorizable.java 
---
@@ -67,7 +69,8 @@ default boolean isAuthorized(Authorizer authorizer, 
RequestAction action, NiFiUs
  * @return is authorized
  */
 default AuthorizationResult checkAuthorization(Authorizer authorizer, 
RequestAction action, NiFiUser user, Map resourceContext) {
-// TODO - include user details context
+final Map userContext = new HashMap<>();
+userContext.put(UserContextKeys.CLIENT_ADDRESS.name(), 
user.getClientAddress());
--- End diff --

I think we have some instances where the client address is not set on the 
user. We should probably not include the userContext in those cases.


> User Identity Normalization
> ---
>
> Key: NIFI-2003
> URL: https://issues.apache.org/jira/browse/NIFI-2003
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Bryan Bende
> Fix For: 1.0.0
>
>
> NiFi allows for a number of different authentication mechanisms. Once the 
> user has authenticated he/she is identified by their identity. This is a 
> String that is returned by the authentication mechanism. For certificate or 
> LDAP based authentication this is a DN. For Kerberos it is the user 
> principal. If the same user authenticates through different mechanisms, they 
> may have different identities. In 0.x this was annoying but not a big deal as 
> it was just a matter of (re)assigning the user role. However, in 1.x this is 
> unacceptable given the nature of fine grain authorization and the number of 
> access policies that must be duplicated.
>  
> Because we’ve delegated user authorization and the underlying implementation 
> can choose to authenticate however they want, we cannot rely on our internal 
> User/Group/Policy model to enforce any normalization.
>  
> After discussions with Andy, Joe, and Bryan, I think we have a proposal that 
> will provide the flexibility needed without requiring continued maintenance 
> by an Administrator. Additionally, it shouldn’t require too many additional 
> development cycles.
>  
> The basic idea is to add configurable mappings that will run after the user 
> identity determined but before any authorizations. These mappings are 
> purposefully decoupled from the authentication mechanisms to reduce 
> duplicative configurations and support a more flexible solution. These 
> mappings could be configured in nifi.properties as follows. Here, the last 
> segment of the property name is an identifier used to associate the pattern 
> with the replacement value.
>  
> {noformat}
> nifi.security.identity.mapping.pattern.dn=^cn=(.*?),dc=(.*?),dc=(.*?)$
> nifi.security.identity.mapping.value.dn=$1@$2.$3
> nifi.security.identity.mapping.pattern.kerb=^(.*?)/instance@(.*?)$
> nifi.security.identity.mapping.value.kerb=$1@$2
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #575: NIFI-619: Make MonitorActivity more cluster friendly

[ijokarumawak]

Github user ijokarumawak commented on the issue:

https://github.com/apache/nifi/pull/575
  
@JPercivall Thanks for reviewing this.

For the 1st comment:

I didn't notice that it's failing Travis test... I'll check what caused the 
error. Thanks for pointing that.

For the 2nd and last comment: 

> When running clustered and monitoring on the cluster, it needs to take 
into account generating the inactive flowfiles in a cluster friendly way as 
well. Currently each Node will generate a flowfile when the inactivity time 
hits. Probably need to track in clustered state whether or not a marker has 
been sent.

I wrote onTrigger like that intentionally, because I thought there're 
use-cases in which user would like to do something on each node when NiFi went 
inactive or recovered activity. If one would like to get notification flow-file 
only on a single node in the cluster, then they can use `On primary node` 
scheduling strategy. Excuse me if I misunderstood your comments, but does this 
address your concern?


---
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 #627: [NIFI-2205] [NIFI-2217] [NIFI-2219] [NIFI-2180] [NIFI-2140]...

[moranr]

Github user moranr commented on the issue:

https://github.com/apache/nifi/pull/627
  
@scottyaslan I don't see headerText for Processor Group Configuration – 
for example if you edit a process group name and click APPLY – dialog header 
is empty.


---
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-2205) Filter components / border not rendered properly in the Cluster dialog

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2205:
--

Github user scottyaslan commented on the issue:

https://github.com/apache/nifi/pull/627
  
@moranr copy/paste error...I have updated the PR


> Filter components / border not rendered properly in the Cluster dialog
> --
>
> Key: NIFI-2205
> URL: https://issues.apache.org/jira/browse/NIFI-2205
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Affects Versions: 1.0.0
>Reporter: Mark Payne
>Assignee: Scott Aslan
> Fix For: 1.0.0
>
> Attachments: screenshot-1.png
>
>
> When I go to the "Cluster" dialog, I see that the filter boxes are hidden 
> behind the table and there is no border around the dialog.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #627: [NIFI-2205] [NIFI-2217] [NIFI-2219] [NIFI-2180] [NIFI-2140]...

[scottyaslan]

Github user scottyaslan commented on the issue:

https://github.com/apache/nifi/pull/627
  
@moranr copy/paste error...I have updated the PR


---
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-619) update MonitorActivity processor to be cluster friendly

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-619:
-

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

https://github.com/apache/nifi/pull/575#discussion_r70437957
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/MonitorActivity.java
 ---
@@ -201,17 +253,57 @@ public void process(final OutputStream out) throws 
IOException {
 }
 } else {
 session.transfer(flowFiles, REL_SUCCESS);
+updatedLatestSuccessTransfer = now;
 logger.info("Transferred {} FlowFiles to 'success'", new 
Object[]{flowFiles.size()});
 
-final long inactivityStartMillis = 
latestSuccessTransfer.getAndSet(now);
+final long latestStateReportTimestamp = 
latestReportedNodeState.get();
+if (SCOPE_CLUSTER.equals(monitoringScope)
+&& (now - latestStateReportTimestamp) > 
(thresholdMillis / 3)) {
+// We don't want to hit the state manager every 
onTrigger(), but often enough to detect activeness.
+try {
+final StateManager stateManager = 
context.getStateManager();
+final StateMap state = 
stateManager.getState(Scope.CLUSTER);
+
+final Map newValues = new HashMap<>();
+
+// Persist attributes so that other nodes can copy it
+if (copyAttributes) {
+newValues.putAll(flowFiles.get(0).getAttributes());
+}
+newValues.put(STATE_KEY_LATEST_SUCCESS_TRANSFER, 
String.valueOf(now));
+
+if (state == null || state.getVersion() == -1) {
+stateManager.setState(newValues, Scope.CLUSTER);
+} else {
+// If this returns false due to race condition, 
it's not a problem since we just need
+// the latest active timestamp.
+stateManager.replace(state, newValues, 
Scope.CLUSTER);
--- End diff --

Thanks for catching this, I'll add code to check if the current timestamp 
is newer than the one stored in Zookeeper.

For retrying, I'd let NiFi scheduler and onTrigger() manage that, instead 
of adding a retry mechanism here, for simplicity and controllability. If it's 
trying to update state, it means that the node is active, so it will report 
correctly. The only problem I can imagine from not updating the state, is the 
possibility for other nodes to emit false alarms. But it's also inevitable if 
other nodes themselves are inactive and Zk is not working. If the issue is 
solved, further onTrigger() call will write state and it will work correctly 
eventually.


> update MonitorActivity processor to be cluster friendly
> ---
>
> Key: NIFI-619
> URL: https://issues.apache.org/jira/browse/NIFI-619
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Brandon DeVries
>Assignee: Koji Kawamura
>Priority: Minor
> Fix For: 1.0.0
>
>
> This processor should be able to be used to monitor activity across the 
> cluster.  In its current state, alerting is based on activity of a single 
> node, not the entire cluster.
> For example, in a 2 node cluster, if system A is getting data from a given 
> flow and system B is not, system B will alert for lack of activity even 
> though the flow is functioning "normally".
> The ideal behavior would be fore an alert to be generated only if both 
> systems did not see data in the specified time.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (NIFI-1951) Custom UIs

[Matt Gilman (JIRA)]

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

Matt Gilman resolved NIFI-1951.
---
Resolution: Fixed

> Custom UIs
> --
>
> Key: NIFI-1951
> URL: https://issues.apache.org/jira/browse/NIFI-1951
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.0.0
>
>
> - Remove deprecated NiFiWebContext and related classes
> - Ensure appropriate access for calls into NiFiWebConfigurationContext



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #635: NIFI-2232: Dynamically updating the global menu acco...

[mcgilman]

GitHub user mcgilman opened a pull request:

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

NIFI-2232: Dynamically updating the global menu according to the current 
users permissions

- Dynamically updating the global menu according to the current users 
permissions.

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

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

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

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


commit b56f6dcd5661843e4849f50f1e2479b956fbc99c
Author: Matt Gilman 
Date:   2016-07-13T00:26:27Z

NIFI-2232:
- Dynamically updating the global menu according to the current users 
permissions.




---
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-2232) UI - Support dynamic updating of user's permissions to items in Global Menu

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2232:
--

GitHub user mcgilman opened a pull request:

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

NIFI-2232: Dynamically updating the global menu according to the current 
users permissions

- Dynamically updating the global menu according to the current users 
permissions.

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

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

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

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


commit b56f6dcd5661843e4849f50f1e2479b956fbc99c
Author: Matt Gilman 
Date:   2016-07-13T00:26:27Z

NIFI-2232:
- Dynamically updating the global menu according to the current users 
permissions.




> UI - Support dynamic updating of user's permissions to items in Global Menu
> ---
>
> Key: NIFI-2232
> URL: https://issues.apache.org/jira/browse/NIFI-2232
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core UI
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>Priority: Blocker
> Fix For: 1.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2020) Enhance JoltTransformJSON processor to support custom transforms

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2020:
--

Github user mattyb149 commented on the issue:

https://github.com/apache/nifi/pull/564
  
I had forgotten about the checked exception thing. If the lamdbas/streams 
are just as awkward as Java 7 code (due to the exceptions, etc.) then there's 
probably no need to force it.  Everything else looks good, I still need to 
build and run it, but if you anticipate another change I can wait for that 
(might as well rebase then too)


> Enhance JoltTransformJSON processor to support custom transforms
> 
>
> Key: NIFI-2020
> URL: https://issues.apache.org/jira/browse/NIFI-2020
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Yolanda M. Davis
>Assignee: Yolanda M. Davis
> Fix For: 1.0.0
>
>
> Jolt supports additional custom transforms via fully-qualified Java 
> classnames. Would like to provide the ability to support custom 
> transformation (via drop in jars) for the Jolt Transform processor.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #636: NIFI-2249: Move URI out of component so it is access...

[mcgilman]

GitHub user mcgilman opened a pull request:

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

NIFI-2249: Move URI out of component so it is accessible without read 
permissions

- Making the URI accessible outside of the component.

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

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

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

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


commit b20518e18088d14b7e17022dfaa1d42ca8dc4dca
Author: Matt Gilman 
Date:   2016-07-13T02:10:21Z

NIFI-2249:
- Making the URI accessibility outside of the component.




---
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 #638: NIFI-1152 NIFI-2117 Fixed standard session impl api ...

[joewitt]

Github user joewitt closed the pull request at:

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


---
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-1152) StandardProcessSession and MockProcessSession should handle transfer to unregistered relationship correctly

[Joseph Witt (JIRA)]

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

Joseph Witt commented on NIFI-1152:
---

ok i believe pr 639 addresses all we've discussed.

Fixes the root problem bug in StandardProcessSession where when calling the 
transfer methods with specified relationship it was not validating that the 
relationship was supported by that processor and throwing the appropriate 
IllegalArgumentException as stated it would in the nifi-api docs for that 
method.

Adds support in the MockProcessSession to honor this API behavior as well.

Adds tests for both StandardProcessSession and MockProcessSession to verify 
that it will now indeed throw the proper exception when transfer is called with 
invalid/unknown relationships.

These changes then caused InvokeScriptedProcessor tests to break.  This was 
because a couple of tests worked because their behavior was hidden due to the 
previously mentioned StandardProcessSession bug.  This resulted in two tests 
failing because they were using SUCCESS and FAILURE relationships but those 
relationships were not defined as being supported by those scripts.  Also fixed 
the Javadocs for getRelationship of that invoke script processor which claimed 
that SUCCESS and FAILURE would always be provided.  They should never be 
provided as the whole point of invoke scripted processor is to allow full 
processor implementations.

> StandardProcessSession and MockProcessSession should handle transfer to 
> unregistered relationship correctly
> ---
>
> Key: NIFI-1152
> URL: https://issues.apache.org/jira/browse/NIFI-1152
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Tools and Build
>Affects Versions: 1.0.0, 0.6.0, 0.7.0, 0.6.1
>Reporter: Mark Payne
>Assignee: Joseph Witt
>  Labels: beginner, newbie
> Fix For: 1.0.0
>
> Attachments: 
> 0001-Fix-for-NIFI-1838-NIFI-1152-Code-modification-for-ty.patch
>
>
> If a processor calls ProcessSession.transfer(flowFile, 
> NON_EXISTENT_RELATIONSHIP) the NiFi framework will throw a 
> FlowFileHandlingException. However, the Mock Framework simply allows it and 
> does not throw any sort of Exception. This needs to be addressed so that the 
> Mock framework functions the same way as the normal NiFi framework.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #483: NIFI-1899 - Introduce ExtractEmailAttachments and Ex...

[JPercivall]

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

https://github.com/apache/nifi/pull/483#discussion_r70561694
  
--- Diff: 
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/smtp/handler/SMTPMessageHandlerFactory.java
 ---
@@ -0,0 +1,155 @@
+/*
+ * 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.processors.email.smtp.handler;
+
+import java.io.IOException;
+import java.io.InputStream;
+import java.security.cert.X509Certificate;
+import java.util.concurrent.CountDownLatch;
+import java.util.concurrent.LinkedBlockingQueue;
+import java.util.concurrent.TimeUnit;
+
+import org.apache.nifi.logging.ComponentLog;
+import org.apache.nifi.stream.io.ByteArrayOutputStream;
+import org.apache.nifi.util.StopWatch;
+import org.subethamail.smtp.DropConnectionException;
+import org.subethamail.smtp.MessageContext;
+import org.subethamail.smtp.MessageHandler;
+import org.subethamail.smtp.MessageHandlerFactory;
+import org.subethamail.smtp.RejectException;
+import org.subethamail.smtp.TooMuchDataException;
+import org.subethamail.smtp.server.SMTPServer;
+
+import org.apache.nifi.processors.email.smtp.event.SmtpEvent;
+
+
+public class SMTPMessageHandlerFactory implements MessageHandlerFactory {
+final LinkedBlockingQueue incomingMessages;
+final ComponentLog logger;
+private CountDownLatch latch;
--- End diff --

Shouldn't this be moved to the Handler class? If I understand it correctly, 
a handler gets created for each message. By having this latch in 
SMTPMessageHandlerFactory, the only the first message will properly wait.


---
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-2222) Jetty reversal of KeyStore, Key passwords in nifi.properties

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-:
--

Github user jvwing commented on the issue:

https://github.com/apache/nifi/pull/632
  
I will review.  I'm glad you looked into this, @brosander.  I have been 
developing superstitious beliefs about the keystore settings, but I had assumed 
it was just a personal problem.


> Jetty reversal of KeyStore, Key passwords in nifi.properties
> 
>
> Key: NIFI-
> URL: https://issues.apache.org/jira/browse/NIFI-
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Bryan Rosander
>
> In JettyServer, currently if you define both nifi.security.keystorePasswd and 
> nifi.security.keyPasswd, the keyPasswd value will be used for the 
> SslContext's keyStorePassword and the keyStorePasswd will be used for the 
> keyManagerPassword.
> Additionally if you only define the keyPasswd, it will set keyStorePassword 
> instead of keyManagerPassword.
> I believe that this is backwards from the expected behaviour of the two 
> properties.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (NIFI-2044) Require revision for component creation

[Matt Gilman (JIRA)]

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

Matt Gilman resolved NIFI-2044.
---
Resolution: Fixed

This issue was addressed in a PR along with NIFI-1554

> Require revision for component creation
> ---
>
> Key: NIFI-2044
> URL: https://issues.apache.org/jira/browse/NIFI-2044
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core Framework, Core UI
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.0.0
>
>
> - When creating a component, require the revision to be specified to ensure 
> we're using the appropriate client id.
> - Require component exists for PUT requests.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #399: First cut at NIFI-1833 - Adding Azure Storage processors

[atilcock]

Github user atilcock commented on the issue:

https://github.com/apache/nifi/pull/399
  
Hi Simon  - are you still working on this?Not sure if it's related to 
the duplicate nar issue you mentioned but I've found an issue after a restart 
of NIFI where the processor stops working.  i.e. implement a workflow with a 
putAzureBlob call.  Stop and restart NIFI and the processor no longer responds 
to data in the queue.   


---
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-2164) ConsumeJMS should allow user to configure trade-off between 'best effort' and 'guaranteed receipt' of data

[Joseph Witt (JIRA)]

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

Joseph Witt updated NIFI-2164:
--
Fix Version/s: (was: 1.0.0)

> ConsumeJMS should allow user to configure trade-off between 'best effort' and 
> 'guaranteed receipt' of data
> --
>
> Key: NIFI-2164
> URL: https://issues.apache.org/jira/browse/NIFI-2164
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Mark Payne
>Assignee: Oleg Zhurakousky
>
> Currently the ConsumeJMS Processor uses auto-acknowledge acknowledgement. 
> This is beneficial for many use cases but could result in data loss if NiFi 
> is shut down. We should expose a 'Delivery Guarantee' property that allows 
> the user to choose between 'Best Effort', which will provide better 
> performance or 'Guaranteed Receipt', which will guarantee that data has been 
> committed to NiFi's Content & FlowFile Repositories before acknowledging the 
> message.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2167) Disabled state not including in a Processor that was copy/paste

[Joseph Witt (JIRA)]

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

Joseph Witt updated NIFI-2167:
--
Fix Version/s: (was: 1.0.0)

> Disabled state not including in a Processor that was copy/paste
> ---
>
> Key: NIFI-2167
> URL: https://issues.apache.org/jira/browse/NIFI-2167
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Matt Gilman
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2169) Improve RouteText performance with pre-compilation of RegEx in certain cases

[Joseph Witt (JIRA)]

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

Joseph Witt commented on NIFI-2169:
---

removing fix version for now until progress/PR is available and at that time it 
can be slotted to the appropriate release.  Looks like a good thing to work.

> Improve RouteText performance with pre-compilation of RegEx in certain cases
> 
>
> Key: NIFI-2169
> URL: https://issues.apache.org/jira/browse/NIFI-2169
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 0.6.1
>Reporter: Stephane Maarek
>  Labels: beginner, easy
>
> When using RegEx matches for the RouteText processor (and possibly other 
> processors), the RegEx gets recompiled every time the processor works. The 
> RegEx could be precompiled / cached under certain conditions, in order to 
> improve the performance of the processor
> See email from Mark Payne:
> Re #2: The regular expression is compiled every time. This is done, though, 
> because the Regex allows the Expression
> Language to be used, so the Regex could actually be different for each 
> FlowFile. That being said, it could certainly be
> improved by either (a) pre-compiling in the case that no Expression Language 
> is used and/or (b) cache up to say 10
> Regex'es once they are compiled. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2170) Separate RevisionManager into a DistributedLockingManager and Revision Manager

[Joseph Witt (JIRA)]

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

Joseph Witt commented on NIFI-2170:
---

[~mcgilman][~markap14]looks like this can be closed?

> Separate RevisionManager into a DistributedLockingManager and Revision Manager
> --
>
> Key: NIFI-2170
> URL: https://issues.apache.org/jira/browse/NIFI-2170
> Project: Apache NiFi
>  Issue Type: Task
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Critical
> Fix For: 1.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2186) Cluster communication treats client and server sockets identically for peer certificate DN extraction

[Joseph Witt (JIRA)]

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

Joseph Witt commented on NIFI-2186:
---

[~alopresto] can this be closed?

> Cluster communication treats client and server sockets identically for peer 
> certificate DN extraction
> -
>
> Key: NIFI-2186
> URL: https://issues.apache.org/jira/browse/NIFI-2186
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>Priority: Critical
>  Labels: certificate, cluster, security, tls
> Fix For: 1.0.0
>
>
> The code to extract the peer certificate DN is identical for client and 
> server {{SSLSocket}}, which means that servers are subject to the 
> {{nifi.security.needClientAuth}} setting being set to {{true}}. Server 
> certificates must be present in a secure connection regardless of this 
> setting. This was fixed in {{0.x}} in [NIFI-2119] and must be ported to the 
> {{master}} branch.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (NIFI-2234) Provenance Lineage not working

[Mark Payne (JIRA)]

Mark Payne created NIFI-2234:


 Summary: Provenance Lineage not working
 Key: NIFI-2234
 URL: https://issues.apache.org/jira/browse/NIFI-2234
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework
Affects Versions: 1.0.0
Reporter: Mark Payne
Assignee: Mark Payne
Priority: Blocker
 Fix For: 1.0.0


In the most recent version of NiFi, when a Provenance query is submitted, the 
events are returned, but when I click the 'View Lineage' button, it shows no 
nodes or links in the returned graph.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2169) Improve RouteText performance with pre-compilation of RegEx in certain cases

[Joseph Witt (JIRA)]

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

Joseph Witt updated NIFI-2169:
--
Fix Version/s: (was: 1.0.0)

> Improve RouteText performance with pre-compilation of RegEx in certain cases
> 
>
> Key: NIFI-2169
> URL: https://issues.apache.org/jira/browse/NIFI-2169
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 0.6.1
>Reporter: Stephane Maarek
>  Labels: beginner, easy
>
> When using RegEx matches for the RouteText processor (and possibly other 
> processors), the RegEx gets recompiled every time the processor works. The 
> RegEx could be precompiled / cached under certain conditions, in order to 
> improve the performance of the processor
> See email from Mark Payne:
> Re #2: The regular expression is compiled every time. This is done, though, 
> because the Regex allows the Expression
> Language to be used, so the Regex could actually be different for each 
> FlowFile. That being said, it could certainly be
> improved by either (a) pre-compiling in the case that no Expression Language 
> is used and/or (b) cache up to say 10
> Regex'es once they are compiled. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2205) Filter components / border not rendered properly in the Cluster dialog

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2205:
--

Github user moranr commented on the issue:

https://github.com/apache/nifi/pull/627
  
@scottyaslan I don't see headerText for Processor Group Configuration – for 
example if you edit a process group name and click APPLY – dialog header is 
empty.


> Filter components / border not rendered properly in the Cluster dialog
> --
>
> Key: NIFI-2205
> URL: https://issues.apache.org/jira/browse/NIFI-2205
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Affects Versions: 1.0.0
>Reporter: Mark Payne
>Assignee: Scott Aslan
> Fix For: 1.0.0
>
> Attachments: screenshot-1.png
>
>
> When I go to the "Cluster" dialog, I see that the filter boxes are hidden 
> behind the table and there is no border around the dialog.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2174) QueryCassandra is handling timestamps as strings

[Joseph Witt (JIRA)]

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

Joseph Witt commented on NIFI-2174:
---

[~mattyb149] do you still plan to tackle for 1.0?

> QueryCassandra is handling timestamps as strings
> 
>
> Key: NIFI-2174
> URL: https://issues.apache.org/jira/browse/NIFI-2174
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Matt Burgess
> Fix For: 1.0.0
>
>
> QueryCassandra fails when selecting a column of timestamp type, with the 
> following error:
> com.datastax.driver.core.exceptions.CodecNotFoundException: Codec not found 
> for requested operation: [timestamp <-> com.datastax.driver.core.LocalDate]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2186) Cluster communication treats client and server sockets identically for peer certificate DN extraction

[Joseph Witt (JIRA)]

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

Joseph Witt commented on NIFI-2186:
---

[~mcgilman] can this be closed?

> Cluster communication treats client and server sockets identically for peer 
> certificate DN extraction
> -
>
> Key: NIFI-2186
> URL: https://issues.apache.org/jira/browse/NIFI-2186
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>Priority: Critical
>  Labels: certificate, cluster, security, tls
> Fix For: 1.0.0
>
>
> The code to extract the peer certificate DN is identical for client and 
> server {{SSLSocket}}, which means that servers are subject to the 
> {{nifi.security.needClientAuth}} setting being set to {{true}}. Server 
> certificates must be present in a secure connection regardless of this 
> setting. This was fixed in {{0.x}} in [NIFI-2119] and must be ported to the 
> {{master}} branch.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2170) Separate RevisionManager into a DistributedLockingManager and Revision Manager

[Matt Gilman (JIRA)]

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

Matt Gilman updated NIFI-2170:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Separate RevisionManager into a DistributedLockingManager and Revision Manager
> --
>
> Key: NIFI-2170
> URL: https://issues.apache.org/jira/browse/NIFI-2170
> Project: Apache NiFi
>  Issue Type: Task
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Critical
> Fix For: 1.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2225) Improvement to archetypes and version management

[Joseph Witt (JIRA)]

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

Joseph Witt commented on NIFI-2225:
---

For the first mention of version references keep in mind the release plugin and 
process automatically takes care of the version references so for the 
programmer they only have to enter them the first time.  I agree though it 
would be ideal to have only one.  I think due to perhaps maven issues in older 
versions of maven or improper use of maven we found the behavior to be 
problematic while doing releases so we went with explicit references.  Probably 
could fix that now.

For the second point I'd suggest that there is no need for a specific nifi 
version reference there.  Backward compatibility for extensions is a pretty 
firmly held item and has defined major release behaviors.  The compatibility is 
to the series/version of the nifi-api as well and not nifi itself.  As we 
tackle the extension repository I think we can also more meaningfully capture 
this information too if needed.

> Improvement to archetypes and version management
> 
>
> Key: NIFI-2225
> URL: https://issues.apache.org/jira/browse/NIFI-2225
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 0.6.1
>Reporter: Stephane Maarek
>Priority: Minor
>
> Hi,
> Just done writing my first processor and there are two things I think could 
> be improved:
> - The version number is defined in three pom.xml. I believe it should only be 
> defined in the parent one and the children should inherit it (under the tag 
> ). This will decrease the number of changes that need to happen when 
> a new version appears
> - There should be a separate parameter for NiFi version vs processor version
> I.e. the final nar would be:
> processor-name...nar



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (NIFI-2231) Refresh Content Viewer UI

[Matt Gilman (JIRA)]

Matt Gilman created NIFI-2231:
-

 Summary: Refresh Content Viewer UI
 Key: NIFI-2231
 URL: https://issues.apache.org/jira/browse/NIFI-2231
 Project: Apache NiFi
  Issue Type: Improvement
  Components: Core UI
Reporter: Matt Gilman
Assignee: Scott Aslan
Priority: Blocker
 Fix For: 1.0.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-1148) Add processor to GetEmail supporting IMAP and POP3

[Andre (JIRA)]

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

Andre commented on NIFI-1148:
-

[~bende], [~joseph witt] 

is anyone working on this?

Happy to do a POP3 + IMAP version of it with an Exchange to follow.

> Add processor to GetEmail supporting IMAP and POP3
> --
>
> Key: NIFI-1148
> URL: https://issues.apache.org/jira/browse/NIFI-1148
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Joseph Witt
>Assignee: Oleg Zhurakousky
> Fix For: 1.0.0
>
>
> It is fairly common that users want to be able to acquire data via email.  
> This means both IMAP and POP3.  POP3 is easier as it is a sort of fire/forget 
> model whereas IMAP involves more state handling.  But in any event both modes 
> are important to support.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-830) For GET requests, InvokeHTTP should set the filename of the 'Response' FlowFile based on the URL

[Joseph Witt (JIRA)]

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

Joseph Witt updated NIFI-830:
-
Fix Version/s: (was: 1.0.0)

> For GET requests, InvokeHTTP should set the filename of the 'Response' 
> FlowFile based on the URL
> 
>
> Key: NIFI-830
> URL: https://issues.apache.org/jira/browse/NIFI-830
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Mark Payne
>Priority: Minor
>  Labels: beginner, newbie
>
> When using InvokeHTTP to fetch the content of a particular URL, I expected 
> that the filename of the 'Response' FlowFile would be set to the filename 
> pulled. I.e., if I pulled http://www.somesite.com/images/1.png, I would have 
> expected the 'Response' FlowFile to have a filename of "1.png" but instead it 
> had the same filename as the incoming FlowFile.
> I don't think this is something that we can change until version 1.0.0 
> because it could potentially break backward compatibility of flows by 
> changing the filename unexpectedly. In the meantime, I have added an 
> UpdateAttribute to set the filename to 
> ${url:substringAfterLast('/'):substringBefore('?')}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-539) Add SCP Processor

[Joseph Witt (JIRA)]

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

Joseph Witt updated NIFI-539:
-
Fix Version/s: (was: 1.0.0)

> Add SCP Processor
> -
>
> Key: NIFI-539
> URL: https://issues.apache.org/jira/browse/NIFI-539
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Edgardo Vega
>Assignee: eran
>  Labels: beginner
>
> A simple and powerful processor would be one that can perform scp file 
> transfers. SCP is generally much faster on file transfers especially on high 
> latency networks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-539) Add SCP Processor

[Joseph Witt (JIRA)]

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

Joseph Witt updated NIFI-539:
-
Status: Open  (was: Patch Available)

removing patch available and version information for now.  Once a PR or Patch 
is supplied we can take next steps.  Please review contrib guidance found here 
https://cwiki.apache.org/confluence/display/NIFI/Contributor+Guide

> Add SCP Processor
> -
>
> Key: NIFI-539
> URL: https://issues.apache.org/jira/browse/NIFI-539
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Edgardo Vega
>Assignee: eran
>  Labels: beginner
> Fix For: 1.0.0
>
>
> A simple and powerful processor would be one that can perform scp file 
> transfers. SCP is generally much faster on file transfers especially on high 
> latency networks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-1644) If unable to write to Content Repository, Process Session should automatically roll itself back

[Joseph Witt (JIRA)]

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

Joseph Witt updated NIFI-1644:
--
Fix Version/s: (was: 1.0.0)

> If unable to write to Content Repository, Process Session should 
> automatically roll itself back
> ---
>
> Key: NIFI-1644
> URL: https://issues.apache.org/jira/browse/NIFI-1644
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Mark Payne
>
> If we write to the Content Repository and get an IOException (for example, 
> out of disk space), the ProcessSession catches this and then removes the 
> temporary content claim and then throws a FlowFileAccessException. However, 
> the entire session really should be rolled back, because the FlowFIle no 
> longer has a valid Content Claim. An example of this is in the 
> StandardProcessSession.write method:
> {code}
> } catch (final FlowFileAccessException ffae) {
> resetWriteClaims(); // need to reset write claim before we can 
> remove the claim
> destroyContent(newClaim);
> throw ffae;
> }
> {code}
> Processors that then catch Throwable or the general Exception and route to 
> failure pass along an invalid FlowFile. We end up seeing the following in the 
> logs:
> {code}
> 2016-03-17 04:21:04,742 WARN [Timer-Driven Process Thread-17] 
> o.a.n.c.r.WriteAheadFlowFileRepository Repository Record 
> StandardRepositoryRecord[UpdateType=CONTENTMISSING,Record=StandardFlowFileRecord[uuid=01efcc28-e28f-45ab-9373-cba8933a010c,claim=StandardContentClaim
>  [resourceClaim=StandardResourceClaim[id=1458188464723-45209, container=pub1, 
> section=153], offset=0, 
> length=1017],offset=0,name=26304456091229115,size=1017]] is marked to be 
> aborted; it will be persisted in the FlowFileRepository as a DELETE record
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-1707) UI - Modernize JS dependency management and build

[Scott Aslan (JIRA)]

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

Scott Aslan updated NIFI-1707:
--
Description: Leverage Bower, Grunt, and mvn plugin for building and 
compression/minification.  (was: Leverage RequireJS, Grunt, and mvn plugin for:

-Dependency management of JS modules
-AMD of JS modules
-Build (mvn) compression/minification (dev and prod))

> UI - Modernize JS dependency management and build
> -
>
> Key: NIFI-1707
> URL: https://issues.apache.org/jira/browse/NIFI-1707
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Scott Aslan
>Assignee: Scott Aslan
>Priority: Minor
> Fix For: 1.0.0
>
>
> Leverage Bower, Grunt, and mvn plugin for building and 
> compression/minification.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-1831) Allow encrypted passwords in configuration files

[Joseph Witt (JIRA)]

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

Joseph Witt commented on NIFI-1831:
---

[~alopresto] still a 1.0 target?  Trying to clear off 1.0 fix version for 
things that don't have active patches in play or considered in progress.

> Allow encrypted passwords in configuration files
> 
>
> Key: NIFI-1831
> URL: https://issues.apache.org/jira/browse/NIFI-1831
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Configuration, Core Framework
>Affects Versions: 0.6.1
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>Priority: Critical
>  Labels: configuration, encryption, password, security
> Fix For: 1.0.0
>
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> Storing passwords in plaintext in configuration files is not a security best 
> practice. While file access can be restricted through OS permissions, these 
> configuration files can be accidentally checked into source control, shared 
> or deployed to multiple instances, etc. 
> NiFi should allow a deployer to provide an encrypted password in the 
> configuration file to minimize exposure of the passwords. On application 
> start-up, NiFi should decrypt the passwords in memory. NiFi should also 
> include a utility to encrypt the raw passwords (and optionally populate the 
> configuration files and provide additional metadata in the configuration 
> files). 
> I am aware this simply shifts the responsibility/delegation of trust from the 
> passwords in the properties file to a new location on the same system, but 
> mitigating the visibility of the raw passwords in the properties file can be 
> one step in a defense in depth approach and is often mandated by security 
> policies within organizations using NiFi. 
> The key used for encryption should not be hard-coded into the application 
> source code, nor should it be universally consistent. The key could be 
> determined by reading static information from the deployed system and feeding 
> it to a key derivation function based on a cryptographically-secure hash 
> function, such as PBKDF2, bcrypt, or scrypt. However, this does introduce 
> upgrade, system migration, and portability issues. These challenges will have 
> to be kept in consideration when determining the key derivation process. 
> Manual key entry is a possibility, and then the master key would only be 
> present in memory, but this prevents automatic reboot on loss of power or 
> other recovery scenario. 
> This must be backward-compatible to allow systems with plaintext passwords to 
> continue operating. Options for achieving this are to only attempt to decrypt 
> passwords when a sibling property is present, or to match a specific format. 
> For these examples, I have used the following default values:
> {code}
> password: thisIsABadPassword
> key: 0123456789ABCDEFFEDCBA98765432100123456789ABCDEFFEDCBA9876543210
> iv:  0123456789ABCDEFFEDCBA9876543210
> algorithm: AES/CBC 256-bit
> {code}
> **Note: These values should not be used in production systems -- the key and 
> IV are common test values, and an AEAD cipher is preferable to provide cipher 
> text integrity assurances, however OpenSSL does not support the use of AEAD 
> ciphers for command-line encryption at this time**
> Example 1: *here the sibling property indicates the password is encrypted and 
> with which implementation; the absence of the property would default to a raw 
> password*
> {code}
> hw12203:/Users/alopresto/Workspace/scratch/encrypted-passwords (master) 
> alopresto
>  0s @ 16:25:56 $ echo "thisIsABadPassword" > password.txt
> hw12203:/Users/alopresto/Workspace/scratch/encrypted-passwords (master) 
> alopresto
>  0s @ 16:26:47 $ ossl aes-256-cbc -e -nosalt -p -K 
> 0123456789ABCDEFFEDCBA98765432100123456789ABCDEFFEDCBA9876543210 -iv 
> 0123456789ABCDEFFEDCBA9876543210 -a -in password.txt -out password.enc
> key=0123456789ABCDEFFEDCBA98765432100123456789ABCDEFFEDCBA9876543210
> iv =0123456789ABCDEFFEDCBA9876543210
> hw12203:/Users/alopresto/Workspace/scratch/encrypted-passwords (master) 
> alopresto
>  0s @ 16:27:09 $ xxd password.enc
> 000: 5643 5856 6146 6250 4158 364f 5743 7646  VCXVaFbPAX6OWCvF
> 010: 6963 6b76 4a63 7744 3854 6b67 3731 4c76  ickvJcwD8Tkg71Lv
> 020: 4d38 6d32 7952 4776 5739 413d 0a M8m2yRGvW9A=.
> hw12203:/Users/alopresto/Workspace/scratch/encrypted-passwords (master) 
> alopresto
>  0s @ 16:27:16 $ more password.enc
> VCXVaFbPAX6OWCvFickvJcwD8Tkg71LvM8m2yRGvW9A=
> hw12203:/Users/alopresto/Workspace/scratch/encrypted-passwords (master) 
> alopresto
>  0s @ 16:27:55 $
> {code}
> In {{nifi.properties}}: 
> {code}
> 

[GitHub] nifi issue #534: Fix for NIFI-1838, NIFI-1152, NIFI-2117

[PuspenduBanerjee]

Github user PuspenduBanerjee commented on the issue:

https://github.com/apache/nifi/pull/534
  
@pvillard31 @mattyb149 @joewitt Any chance to look into 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] [Created] (NIFI-2230) Refresh UpdateAttribute Custom UI

[Matt Gilman (JIRA)]

Matt Gilman created NIFI-2230:
-

 Summary: Refresh UpdateAttribute Custom UI
 Key: NIFI-2230
 URL: https://issues.apache.org/jira/browse/NIFI-2230
 Project: Apache NiFi
  Issue Type: Improvement
  Components: Extensions
Reporter: Matt Gilman
Assignee: Scott Aslan
Priority: Blocker
 Fix For: 1.0.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2201) Seed initial authorizations.xml with proxy policies for nodes in cluster

[Bryan Bende (JIRA)]

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

Bryan Bende updated NIFI-2201:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Seed initial authorizations.xml with proxy policies for nodes in cluster
> 
>
> Key: NIFI-2201
> URL: https://issues.apache.org/jira/browse/NIFI-2201
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Matt Gilman
>Assignee: Bryan Bende
>Priority: Critical
> Fix For: 1.0.0
>
>
> Also update the default contents of the authorizations.xml to refer to the 
> authorizer configuration in authorizers.xml.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-1157) Remove deprecated methods from FlowFile api

[Joseph Witt (JIRA)]

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

Joseph Witt commented on NIFI-1157:
---

good to do for 1.0 as a cleanup effort

> Remove deprecated methods from FlowFile api
> ---
>
> Key: NIFI-1157
> URL: https://issues.apache.org/jira/browse/NIFI-1157
> Project: Apache NiFi
>  Issue Type: Task
>Reporter: Tony Kurc
>Priority: Minor
> Fix For: 1.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-1947) Update Cluster Awareness

[Joseph Witt (JIRA)]

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

Joseph Witt commented on NIFI-1947:
---

[~markap14] still a 1.0 target?

> Update Cluster Awareness
> 
>
> Key: NIFI-1947
> URL: https://issues.apache.org/jira/browse/NIFI-1947
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 1.0.0
>Reporter: Mark Payne
> Fix For: 1.0.0
>
>
> With the NCM removed for version 1.0.0, we now have a situation where a user 
> can navigate to one node in a cluster while the node is disconnected. If the 
> node is then reconnected, the UI does not update to indicate to the user that 
> the node is now part of a cluster.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-1957) Modal dialogs do not handle browser window resize

[Joseph Witt (JIRA)]

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

Joseph Witt commented on NIFI-1957:
---

[~scottyaslan] [~mcgilman] is this obe in 1.0 or duplicative of something else?

> Modal dialogs do not handle browser window resize
> -
>
> Key: NIFI-1957
> URL: https://issues.apache.org/jira/browse/NIFI-1957
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 0.6.1
>Reporter: Andy LoPresto
>Priority: Critical
>  Labels: dialog, ui
> Fix For: 1.0.0
>
> Attachments: Screen Shot 2016-06-02 at 10.31.31 AM.png, Screen Shot 
> 2016-06-02 at 10.34.12 AM.png, Screen Shot 2016-06-02 at 10.42.52 AM.png, 
> Screen Shot 2016-06-02 at 10.47.37 AM.png, Screen Shot 2016-06-02 at 10.47.41 
> AM.png, Screen Shot 2016-06-02 at 10.47.45 AM.png, Screen Shot 2016-06-02 at 
> 10.48.04 AM.png, Screen Shot 2016-06-02 at 10.48.09 AM.png, Screen Shot 
> 2016-06-02 at 10.48.22 AM.png, Screen Shot 2016-06-02 at 10.48.34 AM.png, 
> Screen Shot 2016-06-02 at 10.48.48 AM.png
>
>
> When the processor configuration dialog is open and the browser window is 
> resized, the dialog does not move or resize to fit in the new visible canvas. 
> In master (1.0) branch, the processor component is also truncated after 
> resizing the window, and refreshing the UI does not fix this issue. See 
> screenshots attached. 
> This is reported on Mac OS X 10.11.4 using Google Chrome Version 
> 50.0.2661.102 (64-bit) and Safari Version 9.1 (11601.5.17.1). 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)