[jira] [Commented] (NIFI-2451) Need to update Encryption Configuration content in Admin guide for 1.0 changes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2451:
--

GitHub user andrewmlim opened a pull request:

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

NIFI-2451 Update Admin guide for encrypt-config command utility, new …

…nifi.sensitive.props.additional.keys property, and removal of Java 7 
reference for JCE Unlimited Strength Jurisdiction Policy

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

$ git pull https://github.com/andrewmlim/nifi NIFI-2451

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

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


commit f350ef7c286574b90adeada475b38dbaf256a36a
Author: Andrew Lim 
Date:   2016-08-13T03:54:11Z

NIFI-2451 Update Admin guide for encrypt-config command utility, new 
nifi.sensitive.props.additional.keys property, and removal of Java 7 reference 
for JCE Unlimited Strength Jurisdiction Policy




> Need to update Encryption Configuration content in Admin guide for 1.0 changes
> --
>
> Key: NIFI-2451
> URL: https://issues.apache.org/jira/browse/NIFI-2451
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Documentation & Website
>Affects Versions: 1.0.0
>Reporter: Andrew Lim
>Assignee: Andrew Lim
> Fix For: 1.0.0
>
>
> Will need to document changes in Admin Guide for:
> NIFI-1831 for Encryption Configuration



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

[GitHub] nifi pull request #855: NIFI-2451 Update Admin guide for encrypt-config comm...

[andrewmlim]

GitHub user andrewmlim opened a pull request:

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

NIFI-2451 Update Admin guide for encrypt-config command utility, new …

…nifi.sensitive.props.additional.keys property, and removal of Java 7 
reference for JCE Unlimited Strength Jurisdiction Policy

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

$ git pull https://github.com/andrewmlim/nifi NIFI-2451

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

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


commit f350ef7c286574b90adeada475b38dbaf256a36a
Author: Andrew Lim 
Date:   2016-08-13T03:54:11Z

NIFI-2451 Update Admin guide for encrypt-config command utility, new 
nifi.sensitive.props.additional.keys property, and removal of Java 7 reference 
for JCE Unlimited Strength Jurisdiction Policy




---
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-2451) Need to update Encryption Configuration content in Admin guide for 1.0 changes

[Andrew Lim (JIRA)]

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

Andrew Lim commented on NIFI-2451:
--

Will add the following to Admin Guide after Encryption Configuration:

Encrypted Passwords in Configuration Files

In order to facilitate the secure setup of NiFi, you can use the encrypt-config 
command line utility to encrypt raw configuration values that NiFi decrypts in 
memory on startup. This extensible protection scheme transparently allows NiFi 
to use raw values in operation, while protecting them at rest.  In the future, 
hardware security modules (HSM) and external secure storage mechanisms will be 
integrated, but for now, an AES encryption provider is the default 
implementation.

This is a change in behavior; prior to 1.0, all configuration values were 
stored in plaintext on the file system. POSIX file permissions were recommended 
to limit unauthorized access to these files

If no administrator action is taken, the configuration values remain 
unencrypted.  

Encrypt-Config Tool

The encrypt-config command line tool reads from a nifi.properties file with 
plaintext sensitive configuration values, prompts you  for a master key, and 
encrypts each value. It replaces the plain values with the protected value in 
the same file, or writes to a new nifi.properties file if specified.  

The default encryption algorithm utilized is AES/GCM 128/256-bit. 128-bit is 
used if JCE Unlimited Strength Crypto Policy is not installed, and 256-bit is 
used if it is installed.

You can use the following command line options with the encrypt-config tool:
-b (or --bootstrapConf) Specifies the bootstrap.conf file you want to use to 
persist the master key.
-h (or --help)  Prints this usage message.
-k (or --hexKey)  The raw hexadecimal key to use to encrypt the sensitive 
properties.  Must be a 32 or 64 hexadecimal string.  Some basic error handling 
is performed if the string is not formatted properly.
-n (or --niFiProperties)  The nifi.properties file containing unprotected 
config values.  The input nifi.properties file is overwritten.
-o (or --outputNiFiProperties)  The destination nifi.properties file containing 
protected config values.  The input nifi.properties file is not modified.


As an example of how the tool works, assume that you have installed the tool on 
a machine supporting 256-bit encryption and with following existing values in 
the nifi.properties file:

# security properties #
nifi.sensitive.props.key=thisIsABadSensitiveKeyPassword
nifi.sensitive.props.algorithm=PBEWITHMD5AND256BITAES-CBC-OPENSSL
nifi.sensitive.props.provider=BC
nifi.sensitive.props.additional.keys=

nifi.security.keystore=/path/to/keystore.jks
nifi.security.keystoreType=JKS
nifi.security.keystorePasswd=thisIsABadKeystorePassword
nifi.security.keyPasswd=thisIsABadKeyPassword
nifi.security.truststore=
nifi.security.truststoreType=
nifi.security.truststorePasswd=

Enter the following arguments when using the tool:

encrypt-config.sh 
-b bootstrap.conf 
-k 0123456789ABCDEFFEDCBA98765432100123456789ABCDEFFEDCBA9876543210 
-n nifi.properties

As a result, the nifi.properties file is overwritten with protected properties 
and sibling encryption identifiers (aes/gcm/256, the currently supported 
algorithm):

# security properties #
nifi.sensitive.props.key=n2z+tTTbHuZ4V4V2||uWhdasyDXD4ZG2lMAes/vqh6u4vaz4xgL4aEbF4Y/dXevqk3ulRcOwf1vc4RDQ==
nifi.sensitive.props.key.protected=aes/gcm/256
nifi.sensitive.props.algorithm=PBEWITHMD5AND256BITAES-CBC-OPENSSL
nifi.sensitive.props.provider=BC
nifi.sensitive.props.additional.keys=

nifi.security.keystore=/path/to/keystore.jks
nifi.security.keystoreType=JKS
nifi.security.keystorePasswd=oBjT92hIGRElIGOh||MZ6uYuWNBrOA6usq/Jt3DaD2e4otNirZDytac/w/KFe0HOkrJR03vcbo
nifi.security.keystorePasswd.protected=aes/gcm/256
nifi.security.keyPasswd=ac/BaE35SL/esLiJ||+ULRvRLYdIDA2VqpE0eQXDEMjaLBMG2kbKOdOwBk/hGebDKlVg==
nifi.security.keyPasswd.protected=aes/gcm/256
nifi.security.truststore=
nifi.security.truststoreType=
nifi.security.truststorePasswd=

Additionally, the bootstrap.conf file is updated with the encryption key as 
follows:

# Master key in hexadecimal format for encrypted sensitive configuration values
nifi.bootstrap.sensitive.key=0123456789ABCDEFFEDCBA98765432100123456789ABCDEFFEDCBA9876543210


Sensitive configuration values are encrypted by the tool by default, however 
you can encrypt any additional properties, if desired.  To encrypt additional 
properties, specify them as comma-separated values in the 
nifi.sensitive.props.additional.keys property.  

If the nifi.properties file already has valid protected values, those property 
values are not modified by the tool.

> Need to update Encryption Configuration content in Admin guide for 1.0 changes
> --
>
> Key: NIFI-2451
>  

[jira] [Updated] (NIFI-2563) User Guide Label Image Broken

[Joseph Witt (JIRA)]

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

Joseph Witt updated NIFI-2563:
--
Fix Version/s: 1.0.0

> User Guide Label Image Broken
> -
>
> Key: NIFI-2563
> URL: https://issues.apache.org/jira/browse/NIFI-2563
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Documentation & Website
>Affects Versions: 1.0.0
>Reporter: James Wing
>Assignee: James Wing
>Priority: Trivial
> Fix For: 1.0.0
>
> Attachments: nifi-user-guide-label-image-broken.png
>
>
> The image markup for the Label control is broken in the User Guide 
> (user-guide.asciidoc, line ~410).  See screenshot.
> !nifi-user-guide-label-image-broken.png|thumbnail!



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

[jira] [Commented] (NIFI-2564) Add support for HL7 composite component names

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2564:
--

GitHub user jfrazee opened a pull request:

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

NIFI-2564 Add support for HL7 composite component names

Wanted to start getting some feedback on this.

ExtractHL7Attributes can currently parse composite components, e.g., output 
PID.PatientName.XPN.2, which corresponds to the patient's given name, but it'd 
be more helpful if the attribute was something like PID.PatientName.GivenName 
or PID.PatientName.XPN.GivenName.

Unfortunately, the underlying library doesn't provide a common way or 
interfaces around the composite types that make it possible to get at that, so 
this change gets at them with reflection.

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

$ git pull https://github.com/jfrazee/nifi NIFI-2564

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

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


commit 0a381e91e76976204e3fdd26e81c930575a4278b
Author: Joey Frazee 
Date:   2016-07-18T21:31:41Z

Propagate Use Segment Names property down to HL7 segment components




> Add support for HL7 composite component names
> -
>
> Key: NIFI-2564
> URL: https://issues.apache.org/jira/browse/NIFI-2564
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Joey Frazee
>Priority: Minor
>
> NIFI-2090 added parsing for segments and components but didn't include the 
> "friendly" names for the composite components. For example, 
> ExtractHL7Attributes can currently parse and output PID.PatientName.XPN.2, 
> which corresponds to the patient's given name, but it'd be more helpful if 
> the attribute was something like PID.PatientName.GivenName or 
> PID.PatientName.XPN.GivenName.



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

[GitHub] nifi pull request #854: NIFI-2564 Add support for HL7 composite component na...

[jfrazee]

GitHub user jfrazee opened a pull request:

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

NIFI-2564 Add support for HL7 composite component names

Wanted to start getting some feedback on this.

ExtractHL7Attributes can currently parse composite components, e.g., output 
PID.PatientName.XPN.2, which corresponds to the patient's given name, but it'd 
be more helpful if the attribute was something like PID.PatientName.GivenName 
or PID.PatientName.XPN.GivenName.

Unfortunately, the underlying library doesn't provide a common way or 
interfaces around the composite types that make it possible to get at that, so 
this change gets at them with reflection.

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

$ git pull https://github.com/jfrazee/nifi NIFI-2564

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

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


commit 0a381e91e76976204e3fdd26e81c930575a4278b
Author: Joey Frazee 
Date:   2016-07-18T21:31:41Z

Propagate Use Segment Names property down to HL7 segment components




---
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-2555) NullPointerException in user authentication causes Internal Server Error 500

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2555:
--

Github user asfgit closed the pull request at:

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


> NullPointerException in user authentication causes Internal Server Error 500
> 
>
> Key: NIFI-2555
> URL: https://issues.apache.org/jira/browse/NIFI-2555
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Andy LoPresto
>Assignee: Matt Gilman
>Priority: Minor
>  Labels: authentication, beginner, kerberos, security
>
> In some cases, the {{NiFiUserUtils.getNiFiUser()}} call returns a {{null}} 
> user. In {{AccessDeniedExceptionMapper:46}}, this user object is operated on 
> to determine whether the status is {{UNAUTHORIZED}} or {{FORBIDDEN}} without 
> checking that the reference is null-safe. This throws a NullPointerException 
> which causes an HTTP 500 Internal Server Error response. 
> We should investigate why the user accessor is returning {{null}}, but 
> additionally, the reference should be checked for {{null}} before operating 
> on it and a better response can be displayed. 
> {code}
> 2016-08-11 18:15:02,083 ERROR [NiFi Web Server-208] 
> c.s.j.spi.container.ContainerResponse Mapped exception to response: 500 
> (Internal Server Error)
> java.lang.NullPointerException: null
> at 
> org.apache.nifi.web.api.config.AccessDeniedExceptionMapper.toResponse(AccessDeniedExceptionMapper.java:46)
>  ~[classes/:na]
> at 
> org.apache.nifi.web.api.config.AccessDeniedExceptionMapper.toResponse(AccessDeniedExceptionMapper.java:34)
>  ~[classes/:na]
> at 
> com.sun.jersey.spi.container.ContainerResponse.mapException(ContainerResponse.java:480)
>  [jersey-server-1.19.jar:1.19]
> at 
> com.sun.jersey.spi.container.ContainerResponse.mapMappableContainerException(ContainerResponse.java:417)
>  [jersey-server-1.19.jar:1.19]
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1477)
>  [jersey-server-1.19.jar:1.19]
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1419)
>  [jersey-server-1.19.jar:1.19]
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1409)
>  [jersey-server-1.19.jar:1.19]
> at 
> com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:409)
>  [jersey-servlet-1.19.jar:1.19]
> at 
> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:558)
>  [jersey-servlet-1.19.jar:1.19]
> at 
> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:733)
>  [jersey-servlet-1.19.jar:1.19]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) 
> [javax.servlet-api-3.1.0.jar:3.1.0]
> at 
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845) 
> [jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1689)
>  [jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:51) 
> [jetty-servlets-9.3.9.v20160517.jar:9.3.9.v20160517]
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676)
>  [jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
> at 
> org.apache.nifi.web.filter.RequestLogger.doFilter(RequestLogger.java:66) 
> [classes/:na]
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676)
>  [jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
> at 
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:207)
>  [spring-security-web-4.0.3.RELEASE.jar:4.0.3.RELEASE]
> at 
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:176)
>  [spring-security-web-4.0.3.RELEASE.jar:4.0.3.RELEASE]
> at 
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
>  [spring-web-4.2.4.RELEASE.jar:4.2.4.RELEASE]
> at 
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:262)
>  [spring-web-4.2.4.RELEASE.jar:4.2.4.RELEASE]
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676)
>  [jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
> at 
> org.apache.nifi.web.filter.TimerFilter.doFilter(TimerFilter.java:51) 
> [classes/:na]
> 

[jira] [Updated] (NIFI-2555) NullPointerException in user authentication causes Internal Server Error 500

[Andy LoPresto (JIRA)]

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

Andy LoPresto updated NIFI-2555:

Resolution: Fixed
Status: Resolved  (was: Patch Available)

> NullPointerException in user authentication causes Internal Server Error 500
> 
>
> Key: NIFI-2555
> URL: https://issues.apache.org/jira/browse/NIFI-2555
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Andy LoPresto
>Assignee: Matt Gilman
>Priority: Minor
>  Labels: authentication, beginner, kerberos, security
>
> In some cases, the {{NiFiUserUtils.getNiFiUser()}} call returns a {{null}} 
> user. In {{AccessDeniedExceptionMapper:46}}, this user object is operated on 
> to determine whether the status is {{UNAUTHORIZED}} or {{FORBIDDEN}} without 
> checking that the reference is null-safe. This throws a NullPointerException 
> which causes an HTTP 500 Internal Server Error response. 
> We should investigate why the user accessor is returning {{null}}, but 
> additionally, the reference should be checked for {{null}} before operating 
> on it and a better response can be displayed. 
> {code}
> 2016-08-11 18:15:02,083 ERROR [NiFi Web Server-208] 
> c.s.j.spi.container.ContainerResponse Mapped exception to response: 500 
> (Internal Server Error)
> java.lang.NullPointerException: null
> at 
> org.apache.nifi.web.api.config.AccessDeniedExceptionMapper.toResponse(AccessDeniedExceptionMapper.java:46)
>  ~[classes/:na]
> at 
> org.apache.nifi.web.api.config.AccessDeniedExceptionMapper.toResponse(AccessDeniedExceptionMapper.java:34)
>  ~[classes/:na]
> at 
> com.sun.jersey.spi.container.ContainerResponse.mapException(ContainerResponse.java:480)
>  [jersey-server-1.19.jar:1.19]
> at 
> com.sun.jersey.spi.container.ContainerResponse.mapMappableContainerException(ContainerResponse.java:417)
>  [jersey-server-1.19.jar:1.19]
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1477)
>  [jersey-server-1.19.jar:1.19]
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1419)
>  [jersey-server-1.19.jar:1.19]
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1409)
>  [jersey-server-1.19.jar:1.19]
> at 
> com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:409)
>  [jersey-servlet-1.19.jar:1.19]
> at 
> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:558)
>  [jersey-servlet-1.19.jar:1.19]
> at 
> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:733)
>  [jersey-servlet-1.19.jar:1.19]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) 
> [javax.servlet-api-3.1.0.jar:3.1.0]
> at 
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845) 
> [jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1689)
>  [jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:51) 
> [jetty-servlets-9.3.9.v20160517.jar:9.3.9.v20160517]
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676)
>  [jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
> at 
> org.apache.nifi.web.filter.RequestLogger.doFilter(RequestLogger.java:66) 
> [classes/:na]
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676)
>  [jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
> at 
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:207)
>  [spring-security-web-4.0.3.RELEASE.jar:4.0.3.RELEASE]
> at 
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:176)
>  [spring-security-web-4.0.3.RELEASE.jar:4.0.3.RELEASE]
> at 
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
>  [spring-web-4.2.4.RELEASE.jar:4.2.4.RELEASE]
> at 
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:262)
>  [spring-web-4.2.4.RELEASE.jar:4.2.4.RELEASE]
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676)
>  [jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
> at 
> org.apache.nifi.web.filter.TimerFilter.doFilter(TimerFilter.java:51) 
> [classes/:na]
> at 
> 

[jira] [Commented] (NIFI-2555) NullPointerException in user authentication causes Internal Server Error 500

[ASF subversion and git services (JIRA)]

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

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

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

NIFI-2555:
- Addressing potential NullPointerException when an AccessDeniedException is 
thrown from an endpoint that isn't subject to the security filter chain.

This closes #846.

Signed-off-by: Andy LoPresto 


> NullPointerException in user authentication causes Internal Server Error 500
> 
>
> Key: NIFI-2555
> URL: https://issues.apache.org/jira/browse/NIFI-2555
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Andy LoPresto
>Assignee: Matt Gilman
>Priority: Minor
>  Labels: authentication, beginner, kerberos, security
>
> In some cases, the {{NiFiUserUtils.getNiFiUser()}} call returns a {{null}} 
> user. In {{AccessDeniedExceptionMapper:46}}, this user object is operated on 
> to determine whether the status is {{UNAUTHORIZED}} or {{FORBIDDEN}} without 
> checking that the reference is null-safe. This throws a NullPointerException 
> which causes an HTTP 500 Internal Server Error response. 
> We should investigate why the user accessor is returning {{null}}, but 
> additionally, the reference should be checked for {{null}} before operating 
> on it and a better response can be displayed. 
> {code}
> 2016-08-11 18:15:02,083 ERROR [NiFi Web Server-208] 
> c.s.j.spi.container.ContainerResponse Mapped exception to response: 500 
> (Internal Server Error)
> java.lang.NullPointerException: null
> at 
> org.apache.nifi.web.api.config.AccessDeniedExceptionMapper.toResponse(AccessDeniedExceptionMapper.java:46)
>  ~[classes/:na]
> at 
> org.apache.nifi.web.api.config.AccessDeniedExceptionMapper.toResponse(AccessDeniedExceptionMapper.java:34)
>  ~[classes/:na]
> at 
> com.sun.jersey.spi.container.ContainerResponse.mapException(ContainerResponse.java:480)
>  [jersey-server-1.19.jar:1.19]
> at 
> com.sun.jersey.spi.container.ContainerResponse.mapMappableContainerException(ContainerResponse.java:417)
>  [jersey-server-1.19.jar:1.19]
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1477)
>  [jersey-server-1.19.jar:1.19]
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1419)
>  [jersey-server-1.19.jar:1.19]
> at 
> com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1409)
>  [jersey-server-1.19.jar:1.19]
> at 
> com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:409)
>  [jersey-servlet-1.19.jar:1.19]
> at 
> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:558)
>  [jersey-servlet-1.19.jar:1.19]
> at 
> com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:733)
>  [jersey-servlet-1.19.jar:1.19]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) 
> [javax.servlet-api-3.1.0.jar:3.1.0]
> at 
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845) 
> [jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1689)
>  [jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:51) 
> [jetty-servlets-9.3.9.v20160517.jar:9.3.9.v20160517]
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676)
>  [jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
> at 
> org.apache.nifi.web.filter.RequestLogger.doFilter(RequestLogger.java:66) 
> [classes/:na]
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676)
>  [jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
> at 
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:207)
>  [spring-security-web-4.0.3.RELEASE.jar:4.0.3.RELEASE]
> at 
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:176)
>  [spring-security-web-4.0.3.RELEASE.jar:4.0.3.RELEASE]
> at 
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
>  [spring-web-4.2.4.RELEASE.jar:4.2.4.RELEASE]
> at 
> 

[GitHub] nifi pull request #846: Addressing potential NullPointerException in AccessD...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2564) Add support for HL7 composite component names

[Joey Frazee (JIRA)]

Joey Frazee created NIFI-2564:
-

 Summary: Add support for HL7 composite component names
 Key: NIFI-2564
 URL: https://issues.apache.org/jira/browse/NIFI-2564
 Project: Apache NiFi
  Issue Type: Improvement
Reporter: Joey Frazee
Priority: Minor


NIFI-2090 added parsing for segments and components but didn't include the 
"friendly" names for the composite components. For example, 
ExtractHL7Attributes can currently parse and output PID.PatientName.XPN.2, 
which corresponds to the patient's given name, but it'd be more helpful if the 
attribute was something like PID.PatientName.GivenName or 
PID.PatientName.XPN.GivenName.



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

[GitHub] nifi issue #846: Addressing potential NullPointerException in AccessDeniedEx...

[alopresto]

Github user alopresto commented on the issue:

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


---
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] [Resolved] (NIFI-1876) Clustering - Merge all responses based on authorization

[Joseph Percivall (JIRA)]

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

Joseph Percivall resolved NIFI-1876.

Resolution: Fixed

> Clustering - Merge all responses based on authorization
> ---
>
> Key: NIFI-1876
> URL: https://issues.apache.org/jira/browse/NIFI-1876
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Jeff Storck
> Fix For: 1.0.0
>
>
> Each node in a cluster may have a different view of the authorization access 
> policies simply to in the timing of updates. Because of this, all requests 
> need to be merged accordingly.
> Requests are directed at a specific resource. These would result in some 403 
> responses.
> Some requests are contain a filtered view of a number of resources. These 
> would need to be updated to return the most restrictive set of responses.



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

[jira] [Commented] (NIFI-1876) Clustering - Merge all responses based on authorization

[ASF subversion and git services (JIRA)]

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

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

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

NIFI-1876 fixing counter URI pattern


> Clustering - Merge all responses based on authorization
> ---
>
> Key: NIFI-1876
> URL: https://issues.apache.org/jira/browse/NIFI-1876
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Jeff Storck
> Fix For: 1.0.0
>
>
> Each node in a cluster may have a different view of the authorization access 
> policies simply to in the timing of updates. Because of this, all requests 
> need to be merged accordingly.
> Requests are directed at a specific resource. These would result in some 403 
> responses.
> Some requests are contain a filtered view of a number of resources. These 
> would need to be updated to return the most restrictive set of responses.



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

[jira] [Commented] (NIFI-1876) Clustering - Merge all responses based on authorization

[ASF subversion and git services (JIRA)]

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

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

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

NIFI-1876 Implements merging of responses to successful requests based on 
authorization, returning the most restrictive response - Added 
StandardHttpResponseMergerSpec for testing response merging - Added Permissible 
interface - Added nifi-api/controller/archive to ProcessGroupEndpointMerger - 
Removed AbstractMultiEntityEndpoint.java, not used anymore - Implemented 
reponse merging for GET requests where there are some successful and 
problematic responses, returning most restrictive one. - Updated nf-settings.js 
with ControllerConfigurationEntity property rename from controllerConfiguration 
to component - Implemented merging of status DTOs based on read permission 
NIFI-2264 Implemented merging of status history results based on readability 
permissions - Added StatusHistoryEndpointMergerSpec to test merging of status 
history based on read permission

NIFI-1876 Added merging for labels, funnels, and controller service references.

NIFI-1876 Added Label and Funnel merging to FlowMerger.java

NIFI-1876 Added replication of request for process group controller services
 - Updated merging code for Status and Status History based on read permissions

NIFI-1876 Fixed issue with node status snapshots all looking like they came 
from one node
Updated ProcessGroupStatusSnapshotDTO to contain status snapshot entities to 
retain readability permission
Added entity classes for ConnectionStatusSnapshotDTO, PortStatusSnapshotDTO, 
ProcessGroupStatusSnapshotDTO, ProcessorStatusSnapshotDTO, and 
RemoteProcessGroupStatusSnapshotDTO
Updated PropertyDescriptorDTO to contain AllowableValueEntity to retain 
readability permission
Added entity class for AllowableValueDTO
Moved AllowableValueDTO to its own top-level class
Updated DtoFactory to get permissions for status snapshot entities
Updated StatusMerger to merge status snapshot entities

Signed-off-by: jpercivall 


> Clustering - Merge all responses based on authorization
> ---
>
> Key: NIFI-1876
> URL: https://issues.apache.org/jira/browse/NIFI-1876
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Jeff Storck
> Fix For: 1.0.0
>
>
> Each node in a cluster may have a different view of the authorization access 
> policies simply to in the timing of updates. Because of this, all requests 
> need to be merged accordingly.
> Requests are directed at a specific resource. These would result in some 403 
> responses.
> Some requests are contain a filtered view of a number of resources. These 
> would need to be updated to return the most restrictive set of responses.



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

[jira] [Commented] (NIFI-1876) Clustering - Merge all responses based on authorization

[ASF subversion and git services (JIRA)]

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

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

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

NIFI-1876 Implements merging of responses to successful requests based on 
authorization, returning the most restrictive response - Added 
StandardHttpResponseMergerSpec for testing response merging - Added Permissible 
interface - Added nifi-api/controller/archive to ProcessGroupEndpointMerger - 
Removed AbstractMultiEntityEndpoint.java, not used anymore - Implemented 
reponse merging for GET requests where there are some successful and 
problematic responses, returning most restrictive one. - Updated nf-settings.js 
with ControllerConfigurationEntity property rename from controllerConfiguration 
to component - Implemented merging of status DTOs based on read permission 
NIFI-2264 Implemented merging of status history results based on readability 
permissions - Added StatusHistoryEndpointMergerSpec to test merging of status 
history based on read permission

NIFI-1876 Added merging for labels, funnels, and controller service references.

NIFI-1876 Added Label and Funnel merging to FlowMerger.java

NIFI-1876 Added replication of request for process group controller services
 - Updated merging code for Status and Status History based on read permissions

NIFI-1876 Fixed issue with node status snapshots all looking like they came 
from one node
Updated ProcessGroupStatusSnapshotDTO to contain status snapshot entities to 
retain readability permission
Added entity classes for ConnectionStatusSnapshotDTO, PortStatusSnapshotDTO, 
ProcessGroupStatusSnapshotDTO, ProcessorStatusSnapshotDTO, and 
RemoteProcessGroupStatusSnapshotDTO
Updated PropertyDescriptorDTO to contain AllowableValueEntity to retain 
readability permission
Added entity class for AllowableValueDTO
Moved AllowableValueDTO to its own top-level class
Updated DtoFactory to get permissions for status snapshot entities
Updated StatusMerger to merge status snapshot entities

Signed-off-by: jpercivall 


> Clustering - Merge all responses based on authorization
> ---
>
> Key: NIFI-1876
> URL: https://issues.apache.org/jira/browse/NIFI-1876
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Jeff Storck
> Fix For: 1.0.0
>
>
> Each node in a cluster may have a different view of the authorization access 
> policies simply to in the timing of updates. Because of this, all requests 
> need to be merged accordingly.
> Requests are directed at a specific resource. These would result in some 403 
> responses.
> Some requests are contain a filtered view of a number of resources. These 
> would need to be updated to return the most restrictive set of responses.



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

[jira] [Commented] (NIFI-1876) Clustering - Merge all responses based on authorization

[ASF subversion and git services (JIRA)]

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

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

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

NIFI-1876 Implemented PropertyDescriptorDTO merging

NIFI-1876 Updated PermissionsDTO to use boolean primitives instead of Boolean 
objects for read and write permission
Removed ISE throwing from EntityFactory, it will rely on null checks instead

This closes #694

Signed-off-by: jpercivall 


> Clustering - Merge all responses based on authorization
> ---
>
> Key: NIFI-1876
> URL: https://issues.apache.org/jira/browse/NIFI-1876
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Jeff Storck
> Fix For: 1.0.0
>
>
> Each node in a cluster may have a different view of the authorization access 
> policies simply to in the timing of updates. Because of this, all requests 
> need to be merged accordingly.
> Requests are directed at a specific resource. These would result in some 403 
> responses.
> Some requests are contain a filtered view of a number of resources. These 
> would need to be updated to return the most restrictive set of responses.



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

[jira] [Commented] (NIFI-1876) Clustering - Merge all responses based on authorization

[ASF subversion and git services (JIRA)]

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

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

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

NIFI-1876 Implements merging of responses to successful requests based on 
authorization, returning the most restrictive response - Added 
StandardHttpResponseMergerSpec for testing response merging - Added Permissible 
interface - Added nifi-api/controller/archive to ProcessGroupEndpointMerger - 
Removed AbstractMultiEntityEndpoint.java, not used anymore - Implemented 
reponse merging for GET requests where there are some successful and 
problematic responses, returning most restrictive one. - Updated nf-settings.js 
with ControllerConfigurationEntity property rename from controllerConfiguration 
to component - Implemented merging of status DTOs based on read permission 
NIFI-2264 Implemented merging of status history results based on readability 
permissions - Added StatusHistoryEndpointMergerSpec to test merging of status 
history based on read permission

NIFI-1876 Added merging for labels, funnels, and controller service references.

NIFI-1876 Added Label and Funnel merging to FlowMerger.java

NIFI-1876 Added replication of request for process group controller services
 - Updated merging code for Status and Status History based on read permissions

NIFI-1876 Fixed issue with node status snapshots all looking like they came 
from one node
Updated ProcessGroupStatusSnapshotDTO to contain status snapshot entities to 
retain readability permission
Added entity classes for ConnectionStatusSnapshotDTO, PortStatusSnapshotDTO, 
ProcessGroupStatusSnapshotDTO, ProcessorStatusSnapshotDTO, and 
RemoteProcessGroupStatusSnapshotDTO
Updated PropertyDescriptorDTO to contain AllowableValueEntity to retain 
readability permission
Added entity class for AllowableValueDTO
Moved AllowableValueDTO to its own top-level class
Updated DtoFactory to get permissions for status snapshot entities
Updated StatusMerger to merge status snapshot entities

Signed-off-by: jpercivall 


> Clustering - Merge all responses based on authorization
> ---
>
> Key: NIFI-1876
> URL: https://issues.apache.org/jira/browse/NIFI-1876
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Jeff Storck
> Fix For: 1.0.0
>
>
> Each node in a cluster may have a different view of the authorization access 
> policies simply to in the timing of updates. Because of this, all requests 
> need to be merged accordingly.
> Requests are directed at a specific resource. These would result in some 403 
> responses.
> Some requests are contain a filtered view of a number of resources. These 
> would need to be updated to return the most restrictive set of responses.



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

[jira] [Commented] (NIFI-1876) Clustering - Merge all responses based on authorization

[ASF subversion and git services (JIRA)]

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

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

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

NIFI-1876 Implemented PropertyDescriptorDTO merging

NIFI-1876 Updated PermissionsDTO to use boolean primitives instead of Boolean 
objects for read and write permission
Removed ISE throwing from EntityFactory, it will rely on null checks instead

This closes #694

Signed-off-by: jpercivall 


> Clustering - Merge all responses based on authorization
> ---
>
> Key: NIFI-1876
> URL: https://issues.apache.org/jira/browse/NIFI-1876
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Jeff Storck
> Fix For: 1.0.0
>
>
> Each node in a cluster may have a different view of the authorization access 
> policies simply to in the timing of updates. Because of this, all requests 
> need to be merged accordingly.
> Requests are directed at a specific resource. These would result in some 403 
> responses.
> Some requests are contain a filtered view of a number of resources. These 
> would need to be updated to return the most restrictive set of responses.



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

[jira] [Commented] (NIFI-2264) Cluster - Merge history results

[ASF subversion and git services (JIRA)]

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

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

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

NIFI-1876 Implements merging of responses to successful requests based on 
authorization, returning the most restrictive response - Added 
StandardHttpResponseMergerSpec for testing response merging - Added Permissible 
interface - Added nifi-api/controller/archive to ProcessGroupEndpointMerger - 
Removed AbstractMultiEntityEndpoint.java, not used anymore - Implemented 
reponse merging for GET requests where there are some successful and 
problematic responses, returning most restrictive one. - Updated nf-settings.js 
with ControllerConfigurationEntity property rename from controllerConfiguration 
to component - Implemented merging of status DTOs based on read permission 
NIFI-2264 Implemented merging of status history results based on readability 
permissions - Added StatusHistoryEndpointMergerSpec to test merging of status 
history based on read permission

NIFI-1876 Added merging for labels, funnels, and controller service references.

NIFI-1876 Added Label and Funnel merging to FlowMerger.java

NIFI-1876 Added replication of request for process group controller services
 - Updated merging code for Status and Status History based on read permissions

NIFI-1876 Fixed issue with node status snapshots all looking like they came 
from one node
Updated ProcessGroupStatusSnapshotDTO to contain status snapshot entities to 
retain readability permission
Added entity classes for ConnectionStatusSnapshotDTO, PortStatusSnapshotDTO, 
ProcessGroupStatusSnapshotDTO, ProcessorStatusSnapshotDTO, and 
RemoteProcessGroupStatusSnapshotDTO
Updated PropertyDescriptorDTO to contain AllowableValueEntity to retain 
readability permission
Added entity class for AllowableValueDTO
Moved AllowableValueDTO to its own top-level class
Updated DtoFactory to get permissions for status snapshot entities
Updated StatusMerger to merge status snapshot entities

Signed-off-by: jpercivall 


> Cluster - Merge history results
> ---
>
> Key: NIFI-2264
> URL: https://issues.apache.org/jira/browse/NIFI-2264
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Jeff Storck
>Priority: Blocker
> Fix For: 1.0.0
>
>
> History results need to be rolled up according to which node(s) contain the 
> history of the actions.



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

[jira] [Commented] (NIFI-1876) Clustering - Merge all responses based on authorization

[ASF subversion and git services (JIRA)]

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

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

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

NIFI-1876: - Introducing entities for allowable values and process group status.

Signed-off-by: Jeff Storck 
Signed-off-by: jpercivall 


> Clustering - Merge all responses based on authorization
> ---
>
> Key: NIFI-1876
> URL: https://issues.apache.org/jira/browse/NIFI-1876
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Jeff Storck
> Fix For: 1.0.0
>
>
> Each node in a cluster may have a different view of the authorization access 
> policies simply to in the timing of updates. Because of this, all requests 
> need to be merged accordingly.
> Requests are directed at a specific resource. These would result in some 403 
> responses.
> Some requests are contain a filtered view of a number of resources. These 
> would need to be updated to return the most restrictive set of responses.



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

[jira] [Commented] (NIFI-1876) Clustering - Merge all responses based on authorization

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-1876:
--

Github user asfgit closed the pull request at:

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


> Clustering - Merge all responses based on authorization
> ---
>
> Key: NIFI-1876
> URL: https://issues.apache.org/jira/browse/NIFI-1876
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Jeff Storck
> Fix For: 1.0.0
>
>
> Each node in a cluster may have a different view of the authorization access 
> policies simply to in the timing of updates. Because of this, all requests 
> need to be merged accordingly.
> Requests are directed at a specific resource. These would result in some 403 
> responses.
> Some requests are contain a filtered view of a number of resources. These 
> would need to be updated to return the most restrictive set of responses.



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

[jira] [Commented] (NIFI-1876) Clustering - Merge all responses based on authorization

[ASF subversion and git services (JIRA)]

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

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

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

NIFI-1876 Implements merging of responses to successful requests based on 
authorization, returning the most restrictive response - Added 
StandardHttpResponseMergerSpec for testing response merging - Added Permissible 
interface - Added nifi-api/controller/archive to ProcessGroupEndpointMerger - 
Removed AbstractMultiEntityEndpoint.java, not used anymore - Implemented 
reponse merging for GET requests where there are some successful and 
problematic responses, returning most restrictive one. - Updated nf-settings.js 
with ControllerConfigurationEntity property rename from controllerConfiguration 
to component - Implemented merging of status DTOs based on read permission 
NIFI-2264 Implemented merging of status history results based on readability 
permissions - Added StatusHistoryEndpointMergerSpec to test merging of status 
history based on read permission

NIFI-1876 Added merging for labels, funnels, and controller service references.

NIFI-1876 Added Label and Funnel merging to FlowMerger.java

NIFI-1876 Added replication of request for process group controller services
 - Updated merging code for Status and Status History based on read permissions

NIFI-1876 Fixed issue with node status snapshots all looking like they came 
from one node
Updated ProcessGroupStatusSnapshotDTO to contain status snapshot entities to 
retain readability permission
Added entity classes for ConnectionStatusSnapshotDTO, PortStatusSnapshotDTO, 
ProcessGroupStatusSnapshotDTO, ProcessorStatusSnapshotDTO, and 
RemoteProcessGroupStatusSnapshotDTO
Updated PropertyDescriptorDTO to contain AllowableValueEntity to retain 
readability permission
Added entity class for AllowableValueDTO
Moved AllowableValueDTO to its own top-level class
Updated DtoFactory to get permissions for status snapshot entities
Updated StatusMerger to merge status snapshot entities

Signed-off-by: jpercivall 


> Clustering - Merge all responses based on authorization
> ---
>
> Key: NIFI-1876
> URL: https://issues.apache.org/jira/browse/NIFI-1876
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Jeff Storck
> Fix For: 1.0.0
>
>
> Each node in a cluster may have a different view of the authorization access 
> policies simply to in the timing of updates. Because of this, all requests 
> need to be merged accordingly.
> Requests are directed at a specific resource. These would result in some 403 
> responses.
> Some requests are contain a filtered view of a number of resources. These 
> would need to be updated to return the most restrictive set of responses.



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

[jira] [Commented] (NIFI-1876) Clustering - Merge all responses based on authorization

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-1876:
--

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/694
  
+1

Visually verified code, did a contrib check build. In a 3 node secure 
cluster I modified 2 of the nodes to always return accept and the third to use 
policies like normal. I then went through every possible way I could think of 
that would interact with policies to be sure they worked as expected. Looks 
good @jtstorck, I will merge it in.

Also I put in a fix to the URI pattern of counters here: 
https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-cluster/src/main/java/org/apache/nifi/cluster/coordination/node/NodeClusterCoordinator.java#L86-L86


> Clustering - Merge all responses based on authorization
> ---
>
> Key: NIFI-1876
> URL: https://issues.apache.org/jira/browse/NIFI-1876
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Jeff Storck
> Fix For: 1.0.0
>
>
> Each node in a cluster may have a different view of the authorization access 
> policies simply to in the timing of updates. Because of this, all requests 
> need to be merged accordingly.
> Requests are directed at a specific resource. These would result in some 403 
> responses.
> Some requests are contain a filtered view of a number of resources. These 
> would need to be updated to return the most restrictive set of responses.



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

[GitHub] nifi pull request #853: NIFI-2563 Fixing User Guide Label Icon

[jvwing]

GitHub user jvwing opened a pull request:

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

NIFI-2563 Fixing User Guide Label Icon

Fix to the image in the User Guide section for the toolbar's Label control.

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

$ git pull https://github.com/jvwing/nifi 
NIFI-2563-fix-user-guide-label-image-1

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

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


commit 64910774ac5593d4932414cc77cd26be07024a47
Author: James Wing 
Date:   2016-08-12T21:38:47Z

NIFI-2563 Fixing User Guide Label Icon




---
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 #694: NIFI-1876 Implements merging of responses to success...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 #694: NIFI-1876 Implements merging of responses to successful req...

[JPercivall]

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/694
  
+1

Visually verified code, did a contrib check build. In a 3 node secure 
cluster I modified 2 of the nodes to always return accept and the third to use 
policies like normal. I then went through every possible way I could think of 
that would interact with policies to be sure they worked as expected. Looks 
good @jtstorck, I will merge it in.

Also I put in a fix to the URI pattern of counters here: 
https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-cluster/src/main/java/org/apache/nifi/cluster/coordination/node/NodeClusterCoordinator.java#L86-L86


---
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-2563) User Guide Label Image Broken

[James Wing (JIRA)]

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

James Wing updated NIFI-2563:
-
Description: 
The image markup for the Label control is broken in the User Guide 
(user-guide.asciidoc, line ~410).  See screenshot.

!nifi-user-guide-label-image-broken.png|thumbnail!


  was:The image markup for the Label control is broken in the User Guide 
(user-guide.asciidoc, line ~410).  See screenshot.


> User Guide Label Image Broken
> -
>
> Key: NIFI-2563
> URL: https://issues.apache.org/jira/browse/NIFI-2563
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Documentation & Website
>Affects Versions: 1.0.0
>Reporter: James Wing
>Assignee: James Wing
>Priority: Trivial
> Attachments: nifi-user-guide-label-image-broken.png
>
>
> The image markup for the Label control is broken in the User Guide 
> (user-guide.asciidoc, line ~410).  See screenshot.
> !nifi-user-guide-label-image-broken.png|thumbnail!



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

[jira] [Updated] (NIFI-2563) User Guide Label Image Broken

[James Wing (JIRA)]

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

James Wing updated NIFI-2563:
-
Attachment: nifi-user-guide-label-image-broken.png

> User Guide Label Image Broken
> -
>
> Key: NIFI-2563
> URL: https://issues.apache.org/jira/browse/NIFI-2563
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Documentation & Website
>Affects Versions: 1.0.0
>Reporter: James Wing
>Assignee: James Wing
>Priority: Trivial
> Attachments: nifi-user-guide-label-image-broken.png
>
>
> The image markup for the Label control is broken in the User Guide 
> (user-guide.asciidoc, line ~410).  See screenshot.



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

[jira] [Commented] (NIFI-2519) TestListenSMTP ValidEmail fails during parallel build

[Joseph Witt (JIRA)]

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

Joseph Witt commented on NIFI-2519:
---

the source of the livelock is clear and I believe resolved. Will have a patch 
for that soon.  Basically the 'data' method was checking if stopped but then in 
an offer call forever so if stopped after the initial check but while waiting 
for space to be available (which it never would be since consumers were 
stopped) it will just sit there.  The solution appears as simple as stop 
indefinite offer but rather offer in a loop and check if we should give up in 
the loop due to stoppage.

> TestListenSMTP ValidEmail fails during parallel build
> -
>
> Key: NIFI-2519
> URL: https://issues.apache.org/jira/browse/NIFI-2519
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Joseph Witt
>Assignee: Oleg Zhurakousky
> Fix For: 1.0.0
>
> Attachments: 
> 0001-NIFI-2519-fixed-max-connections-and-max-size-enforce.patch
>
>
> While running a full NiFi parallel build received the following. So there is 
> some test issue at least that is impacting build stability.
> [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
> nifi-email-processors ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 4 source files to 
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/test-classes
> [WARNING] 
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[122,24]
>  [deprecation] stop() in Thread has been deprecated
> [WARNING] 
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[186,24]
>  [deprecation] stop() in Thread has been deprecated
> [WARNING] 
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[307,24]
>  [deprecation] stop() in Thread has been deprecated
> [INFO] 
> [INFO] --- maven-compiler-plugin:3.2:testCompile (groovy-tests) @ 
> nifi-email-processors ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Nothing to compile - all classes are up to date
> [INFO] 
> [INFO] --- maven-surefire-plugin:2.18:test (default-test) @ 
> nifi-email-processors ---
> [INFO] Surefire report directory: 
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/surefire-reports
> [INFO] Using configured provider 
> org.apache.maven.surefire.junit4.JUnit4Provider
> ---
>  T E S T S
> ---
> Running org.apache.nifi.processors.email.TestListenSMTP
> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.473 sec <<< 
> FAILURE! - in org.apache.nifi.processors.email.TestListenSMTP
> ValidEmail(org.apache.nifi.processors.email.TestListenSMTP)  Time elapsed: 
> 0.038 sec  <<< FAILURE!
> java.lang.AssertionError: Sending email failed
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertFalse(Assert.java:64)
>   at 
> org.apache.nifi.processors.email.TestListenSMTP.ValidEmail(TestListenSMTP.java:188)
> Running org.apache.nifi.processors.email.TestExtractEmailAttachments
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.1 sec - in 
> org.apache.nifi.processors.email.TestExtractEmailAttachments
> Running org.apache.nifi.processors.email.TestExtractEmailHeaders
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 sec - 
> in org.apache.nifi.processors.email.TestExtractEmailHeaders
> Results :
> Failed tests: 
>   TestListenSMTP.ValidEmail:188 Sending email failed



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

[jira] [Updated] (NIFI-2536) Update Documentation for Templates

[James Wing (JIRA)]

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

James Wing updated NIFI-2536:
-
Status: Patch Available  (was: Open)

> Update Documentation for Templates
> --
>
> Key: NIFI-2536
> URL: https://issues.apache.org/jira/browse/NIFI-2536
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Documentation & Website
>Affects Versions: 1.0.0
>Reporter: James Wing
>Assignee: James Wing
>Priority: Minor
>
> The documentation for importing a template does not reflect recent UI changes 
> for 1.0.  Required updates include:
> * Template features moved to the Operate Palette (create, upload)
> ** Association between template actions and current process group permissions
> * Template features still in the Templates dialog (list, filter, export, 
> delete)



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

[jira] [Commented] (NIFI-2519) TestListenSMTP ValidEmail fails during parallel build

[Joseph Witt (JIRA)]

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

Joseph Witt commented on NIFI-2519:
---

Deadlock still there...

{quote}
"StandardProcessScheduler Thread-5" Id=156 TIMED_WAITING  on 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@3cd8b9a6
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at 
java.util.concurrent.ThreadPoolExecutor.awaitTermination(ThreadPoolExecutor.java:1465)
at 
org.subethamail.smtp.server.ServerThread.shutdownSessions(ServerThread.java:239)
at 
org.subethamail.smtp.server.ServerThread.shutdown(ServerThread.java:190)
at org.subethamail.smtp.server.SMTPServer.stop(SMTPServer.java:310)
- waiting on 
org.apache.nifi.processors.email.ListenSMTP$ConsumerAwareSmtpServer@1c3fa4a6
at 
org.apache.nifi.processors.email.ListenSMTP$ConsumerAwareSmtpServer.stop(ListenSMTP.java:376)
- waiting on 
org.apache.nifi.processors.email.ListenSMTP$ConsumerAwareSmtpServer@1c3fa4a6
at org.apache.nifi.processors.email.ListenSMTP.stop(ListenSMTP.java:230)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:137)
at 
org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:125)
at 
org.apache.nifi.util.ReflectionUtils.quietlyInvokeMethodsWithAnnotations(ReflectionUtils.java:233)
at 
org.apache.nifi.util.ReflectionUtils.quietlyInvokeMethodsWithAnnotation(ReflectionUtils.java:85)
at 
org.apache.nifi.controller.StandardProcessorNode$2.run(StandardProcessorNode.java:1326)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Number of Locked Synchronizers: 1
- java.util.concurrent.ThreadPoolExecutor$Worker@246d3a7b



"org.subethamail.smtp.server.Session-/127.0.0.1:62163" Id=207 TIMED_WAITING  on 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject@3d3d0835
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at 
java.util.concurrent.ArrayBlockingQueue.offer(ArrayBlockingQueue.java:379)
at 
org.apache.nifi.processors.email.SmtpConsumer.data(SmtpConsumer.java:147)
at org.subethamail.smtp.command.DataCommand.execute(DataCommand.java:64)
at 
org.subethamail.smtp.server.RequireTLSCommandWrapper.execute(RequireTLSCommandWrapper.java:30)
at 
org.subethamail.smtp.server.CommandHandler.handleCommand(CommandHandler.java:99)
at org.subethamail.smtp.server.Session.runCommandLoop(Session.java:244)
at org.subethamail.smtp.server.Session.run(Session.java:145)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Number of Locked Synchronizers: 1
- java.util.concurrent.ThreadPoolExecutor$Worker@6151d941
{quote}


Also, got corrupted emails through this.  Started up multiple threads on 
PutEmail and on ListenSMTP.  Noticed it was slower than single threaded and 
then it started having corrupt messages on occassion.


> TestListenSMTP ValidEmail fails during parallel build
> -
>
> Key: NIFI-2519
> URL: https://issues.apache.org/jira/browse/NIFI-2519
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Joseph Witt
>Assignee: Oleg Zhurakousky
> Fix For: 1.0.0

[GitHub] nifi issue #843: NIFI-2553 Fixing handling of Paths in HDFS processors

[YolandaMDavis]

Github user YolandaMDavis commented on the issue:

https://github.com/apache/nifi/pull/843
  
@bbende  ran several tests on 3 node HDFS cluster doing file movement from 
and to HDFS. Forced EL syntax errors on all changed processors and they 
reported as expected. Please let me let me know about comments provided above, 
otherwise all looks good.


---
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-2553) HDFS processors throwing exception from OnSchedule when directory is an invalid URI

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2553:
--

Github user YolandaMDavis commented on the issue:

https://github.com/apache/nifi/pull/843
  
@bbende  ran several tests on 3 node HDFS cluster doing file movement from 
and to HDFS. Forced EL syntax errors on all changed processors and they 
reported as expected. Please let me let me know about comments provided above, 
otherwise all looks good.


> HDFS processors throwing exception from OnSchedule when directory is an 
> invalid URI
> ---
>
> Key: NIFI-2553
> URL: https://issues.apache.org/jira/browse/NIFI-2553
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Minor
> Fix For: 1.0.0
>
>
> If you enter a directory string that results in an invalid URI, the HDFS 
> processors will throw an unexpected exception from OnScheduled because of a 
> logging statement on in AbstractHadoopProcessor:
> {code}
> getLogger().info("Initialized a new HDFS File System with working dir: {} 
> default block size: {} default replication: {} config: {}",
> new Object[] { fs.getWorkingDirectory(), 
> fs.getDefaultBlockSize(new Path(dir)), fs.getDefaultReplication(new 
> Path(dir)), config.toString() });
> {code}
> An example input for the directory that can produce this problem:
> data_${literal('testing'):substring(0,4)%7D
> In addition to this, FetchHDFS, ListHDFS, GetHDFS, and PutHDFS all create new 
> Path instances in their onTrigger methods from the same directory, outside of 
> a try/catch which would result in throwing a ProcessException (if it got past 
> the logging issue above).



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

[jira] [Commented] (NIFI-2560) Tune POP3/IMAP processors

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2560:
--

GitHub user olegz opened a pull request:

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

NIFI-2560 added connection timeout to IMAP/POP3



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

$ git pull https://github.com/olegz/nifi NIFI-2560

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

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


commit b9a5076367723b7bc7fad1c13d92dda000607d78
Author: Oleg Zhurakousky 
Date:   2016-08-12T20:20:03Z

NIFI-2560 added connection timeout to IMAP/POP3




> Tune POP3/IMAP processors 
> --
>
> Key: NIFI-2560
> URL: https://issues.apache.org/jira/browse/NIFI-2560
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Oleg Zhurakousky
>Assignee: Oleg Zhurakousky
> Fix For: 1.0.0
>
>
> Couple of things needs a bit of tuning since people started to use it.
> 1. Expose connection timeout. This is primarily due to various providers 
> acting differently (Gmail vs Yahoo etc)
> 2. Fix how yield() is invoked 



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

[GitHub] nifi pull request #851: NIFI-2560 added connection timeout to IMAP/POP3

[olegz]

GitHub user olegz opened a pull request:

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

NIFI-2560 added connection timeout to IMAP/POP3



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

$ git pull https://github.com/olegz/nifi NIFI-2560

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

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


commit b9a5076367723b7bc7fad1c13d92dda000607d78
Author: Oleg Zhurakousky 
Date:   2016-08-12T20:20:03Z

NIFI-2560 added connection timeout to IMAP/POP3




---
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-2496) UI - Zoom Fit does not account for an open palette

[Joseph Percivall (JIRA)]

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

Joseph Percivall commented on NIFI-2496:


In addition to the open palette, the zoom fit doesn't take into account the 
bottom breadcrumb bar so it will fit and things are partially covered by the 
bottom bar.

> UI - Zoom Fit does not account for an open palette
> --
>
> Key: NIFI-2496
> URL: https://issues.apache.org/jira/browse/NIFI-2496
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Matt Gilman
>Priority: Minor
> Fix For: 1.1.0
>
>
> When using zoom fit, the viewport calculation does not account for whether 
> the palette(s) are open. This is also true for entering a Process Group for 
> the first time (which simply calls the zoom fit method).



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

[jira] [Created] (NIFI-2562) PutHDFS writes corrupted data in the transparent disk encryption zone

[Vik (JIRA)]

Vik created NIFI-2562:
-

 Summary: PutHDFS writes corrupted data in the transparent disk 
encryption zone
 Key: NIFI-2562
 URL: https://issues.apache.org/jira/browse/NIFI-2562
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework
Affects Versions: 0.6.0
Reporter: Vik
Priority: Blocker


Problem 1: UnknownHostExcepion
When NiFi is trying to ingest files into HDFS encryption zone, it was throwing 
UnknownHostException

Reason: In hadoop Configuration files, like core-site.xml and hdfs-site.xml, 
kms hosts were mentioned in the following format "h...@xxx1.int..com; 
xxx2.int..com:16000". 
Since NiFi was using old hadoop libraries (2.6.2), It could not resolve two 
hosts. So instead it considered two hosts as a single host and started throwing 
UnknownHostExcepion.

We tried a couple different fixes for this. 

Fix 1: Changing configuration files from having property like:

   hadoop.security.key.provider.path 
kms://h...@.int..com; 
.int..com:16000/kms   

to:

   hadoop.security.key.provider.path 
kms://h...@.int..com:16000/kms   
 
Fix 2: Building NiFi nar files with hadoop version, as installed in our system. 
(2.6.0-cdh5.7.0).

Steps followed:

a) Changed NiFi pom file hadoop version from 2.6.2 to 2.6.0-cdh5.7.0.
b) Run mvn clean package -DskipTests
c) Copy following nar files to /opt/nifi-dev/lib
./nifi-nar-bundles/nifi-hadoop-bundle/nifi-hadoop-nar/target/nifi-hadoop-nar-1.0.0-SNAPSHOT.nar
./nifi-nar-bundles/nifi-hadoop-libraries-bundle/nifi-hadoop-libraries-nar/target/nifi-hadoop-libraries-nar-1.0.0-SNAPSHOT.nar
./nifi-nar-bundles/nifi-hbase-bundle/nifi-hbase-nar/target/nifi-hbase-nar-1.0.0-SNAPSHOT.nar
./nifi-nar-bundles/nifi-standard-services/nifi-http-context-map-bundle/nifi-http-context-map-nar/target/nifi-http-context-map-nar-1.0.0-SNAPSHOT.nar
d)  Restart NiFi with bin/nifi.sh restart

This fixes resolved the Unknown Host Exception for us but we ran into Problem 2 
mentioned below.

Problem 2: Ingesting Corrupted data into HDFS encryption zone
After resolving the UnknownHostException, NiFi was able to ingest files into 
encryption zone but content of the file is corrupted. 

Approaches:
Tried to simulate error with sample Java program which uses similar logic and 
same library, but it was ingesting files into encryption zone without any 
problem.
Checked NiFi log files to find the cause, found NiFi is making HTTP requests to 
kms to decrypt keys but could not proceed  further as there is no error.
 



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

[jira] [Updated] (NIFI-2547) Add DeleteHDFS Processor

[Ricky Saltzer (JIRA)]

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

Ricky Saltzer updated NIFI-2547:

Flags: Patch

> Add DeleteHDFS Processor 
> -
>
> Key: NIFI-2547
> URL: https://issues.apache.org/jira/browse/NIFI-2547
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Ricky Saltzer
>Assignee: Ricky Saltzer
>
> There are times where a user may want to remove a file or directory from 
> HDFS. The reasons for this vary, but to provide some context, I currently 
> have a pipeline where I need to periodically delete files that my NiFi 
> pipeline is producing. In my case, it's a "Delete files after they are 7 days 
> old". 
> Currently, I have to use the {{ExecuteStreamCommand}} processor and manually 
> call {{hdfs dfs -rm}}, which is awful when dealing with a large amount of 
> files. For one, an entire JVM is spun up for each delete, and two, when 
> deleting directories with thousands of files, it can sometimes cause the 
> command to hang indefinitely. 
> With that being said, I am proposing we add a {{DeleteHDFS}} processor which 
> meets the following criteria. 
> * Can delete both directories and files
> * Can delete directories recursively
> * Supports the dynamic expression language 
> * Supports using glob paths (e.g. /data/for/2017/08/*)
> * Capable of being a downstream processor as well as a standalone processor



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

[jira] [Updated] (NIFI-2547) Add DeleteHDFS Processor

[Ricky Saltzer (JIRA)]

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

Ricky Saltzer updated NIFI-2547:

Flags:   (was: Patch)

> Add DeleteHDFS Processor 
> -
>
> Key: NIFI-2547
> URL: https://issues.apache.org/jira/browse/NIFI-2547
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Ricky Saltzer
>Assignee: Ricky Saltzer
>
> There are times where a user may want to remove a file or directory from 
> HDFS. The reasons for this vary, but to provide some context, I currently 
> have a pipeline where I need to periodically delete files that my NiFi 
> pipeline is producing. In my case, it's a "Delete files after they are 7 days 
> old". 
> Currently, I have to use the {{ExecuteStreamCommand}} processor and manually 
> call {{hdfs dfs -rm}}, which is awful when dealing with a large amount of 
> files. For one, an entire JVM is spun up for each delete, and two, when 
> deleting directories with thousands of files, it can sometimes cause the 
> command to hang indefinitely. 
> With that being said, I am proposing we add a {{DeleteHDFS}} processor which 
> meets the following criteria. 
> * Can delete both directories and files
> * Can delete directories recursively
> * Supports the dynamic expression language 
> * Supports using glob paths (e.g. /data/for/2017/08/*)
> * Capable of being a downstream processor as well as a standalone processor



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

[GitHub] nifi pull request #850: NIFI-2547: Add DeleteHDFS Processor

[rickysaltzer]

GitHub user rickysaltzer opened a pull request:

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

NIFI-2547: Add DeleteHDFS Processor

This processor adds the capability to delete files or
directories inside of HDFS.

Paths supports both static and expression language values,
as well as glob support (e.g. /data/for/2016/07/*).

This processor may be used standalone, as well as part of a
downstream connection.

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

$ git pull https://github.com/rickysaltzer/nifi NIFI-2547

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

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


commit d42fe48779eefbdfe936f2b3745b7eed1fe31d6e
Author: ricky 
Date:   2016-08-10T23:14:39Z

NIFI-2547: Add DeleteHDFS Processor

This processor adds the capability to delete files or
directories inside of HDFS.

Paths supports both static and expression language values,
as well as glob support (e.g. /data/for/2016/07/*).

This processor may be used standalone, as well as part of a
downstream connection.




---
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-2547) Add DeleteHDFS Processor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2547:
--

GitHub user rickysaltzer opened a pull request:

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

NIFI-2547: Add DeleteHDFS Processor

This processor adds the capability to delete files or
directories inside of HDFS.

Paths supports both static and expression language values,
as well as glob support (e.g. /data/for/2016/07/*).

This processor may be used standalone, as well as part of a
downstream connection.

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

$ git pull https://github.com/rickysaltzer/nifi NIFI-2547

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

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


commit d42fe48779eefbdfe936f2b3745b7eed1fe31d6e
Author: ricky 
Date:   2016-08-10T23:14:39Z

NIFI-2547: Add DeleteHDFS Processor

This processor adds the capability to delete files or
directories inside of HDFS.

Paths supports both static and expression language values,
as well as glob support (e.g. /data/for/2016/07/*).

This processor may be used standalone, as well as part of a
downstream connection.




> Add DeleteHDFS Processor 
> -
>
> Key: NIFI-2547
> URL: https://issues.apache.org/jira/browse/NIFI-2547
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Ricky Saltzer
>Assignee: Ricky Saltzer
>
> There are times where a user may want to remove a file or directory from 
> HDFS. The reasons for this vary, but to provide some context, I currently 
> have a pipeline where I need to periodically delete files that my NiFi 
> pipeline is producing. In my case, it's a "Delete files after they are 7 days 
> old". 
> Currently, I have to use the {{ExecuteStreamCommand}} processor and manually 
> call {{hdfs dfs -rm}}, which is awful when dealing with a large amount of 
> files. For one, an entire JVM is spun up for each delete, and two, when 
> deleting directories with thousands of files, it can sometimes cause the 
> command to hang indefinitely. 
> With that being said, I am proposing we add a {{DeleteHDFS}} processor which 
> meets the following criteria. 
> * Can delete both directories and files
> * Can delete directories recursively
> * Supports the dynamic expression language 
> * Supports using glob paths (e.g. /data/for/2017/08/*)
> * Capable of being a downstream processor as well as a standalone processor



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

[jira] [Commented] (NIFI-2477) Document tls-toolkit

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2477:
--

GitHub user andrewmlim opened a pull request:

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

NIFI-2477 Document TLS generation tool in Admin and Developer Guides



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

$ git pull https://github.com/andrewmlim/nifi NIFI-2477

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

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


commit 8c72a5a208d418ba35c26b31b430315c517d3c32
Author: Andrew Lim 
Date:   2016-08-12T18:44:38Z

NIFI-2477 Document TLS generation tool in Admin and Developer Guides




> Document tls-toolkit
> 
>
> Key: NIFI-2477
> URL: https://issues.apache.org/jira/browse/NIFI-2477
> Project: Apache NiFi
>  Issue Type: Task
>Reporter: Bryan Rosander
>Assignee: Andrew Lim
> Fix For: 1.0.0
>
>
> tls-toolkit created as part of NIFI-2193 needs to be documented in order to 
> be a useful utility to ease the burden of configuring tls for one or more 
> NiFi instances.



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

[jira] [Commented] (NIFI-1876) Clustering - Merge all responses based on authorization

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-1876:
--

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/694
  
@jtstorck I think we also need a CounterEndpointMerger.


> Clustering - Merge all responses based on authorization
> ---
>
> Key: NIFI-1876
> URL: https://issues.apache.org/jira/browse/NIFI-1876
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Jeff Storck
> Fix For: 1.0.0
>
>
> Each node in a cluster may have a different view of the authorization access 
> policies simply to in the timing of updates. Because of this, all requests 
> need to be merged accordingly.
> Requests are directed at a specific resource. These would result in some 403 
> responses.
> Some requests are contain a filtered view of a number of resources. These 
> would need to be updated to return the most restrictive set of responses.



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

[GitHub] nifi issue #694: NIFI-1876 Implements merging of responses to successful req...

[mcgilman]

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/694
  
@jtstorck I think we also need a CounterEndpointMerger.


---
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-2561) Need to separate SPNEGO and service principals for Kerberos

[Joseph Witt (JIRA)]

Joseph Witt created NIFI-2561:
-

 Summary: Need to separate SPNEGO and service principals for 
Kerberos
 Key: NIFI-2561
 URL: https://issues.apache.org/jira/browse/NIFI-2561
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework
Affects Versions: 1.0.0
Reporter: Joseph Witt


Today we have a single principal used for interacting with NiFi via SPNEGO and 
when operating as a service.  We should offer a way to specify/establish these 
principals separately such as

nifi.kerberos.service.principal=nifi/hostname@REALM
nifi.kerberos.service.keytab=path
nifi.kerberos.spnego.principal=HTTP/hostname@REALM
nifi.kerberos.spnego.keytab=path



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

[jira] [Commented] (NIFI-2551) Rare condition causes FileSystemRepository NPE

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2551:
--

GitHub user markap14 opened a pull request:

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

NIFI-2551: Addressed a threading issue in the StandardResourceClaimManager…

… and performed some refactoring so that we can ensure thread-safety across 
different components of the application, such as ProcessSession and 
WriteAheadFlowFile Repository when interacting with the 
StandardResourceClaimManager. Update DebugFlow to allow it to write to a 
FlowFile multiple times, which exposes the concurrency bug. Also avoided 
calling ContentRepository.remove() from ProcessSession whenever the content is 
no longer needed, as that can cause problems now that the Resource Claim is 
backing the content claim.

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

$ git pull https://github.com/markap14/nifi NIFI-2551-1.x

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

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


commit 2c2b4e9a5ddf030b60631f8ef24fca3b8b5324d6
Author: Mark Payne 
Date:   2016-08-12T17:56:03Z

NIFI-2551: Addressed a threading issue in the StandardResourceClaimManager 
and performed some refactoring so that we can ensure thread-safety across 
different components of the application, such as ProcessSession and 
WriteAheadFlowFile Repository when interacting with the 
StandardResourceClaimManager. Update DebugFlow to allow it to write to a 
FlowFile multiple times, which exposes the concurrency bug. Also avoided 
calling ContentRepository.remove() from ProcessSession whenever the content is 
no longer needed, as that can cause problems now that the Resource Claim is 
backing the content claim.




> Rare condition causes FileSystemRepository NPE
> --
>
> Key: NIFI-2551
> URL: https://issues.apache.org/jira/browse/NIFI-2551
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Michael Moser
>Assignee: Michael Moser
>Priority: Blocker
> Fix For: 1.0.0, 0.8.0
>
>
> In rare unpredictable cases when NiFi is processing a heavy load, we see 
> FileSystemRepository throw a NullPointerException
> {noformat}
> java.lang.NullPointerException
> at o.a.n.c.r.FileSystemRepository$2.write(FileSystemRepository.java:918) 
> [nifi-framework-core-0.7.0.jar]
> at 
> o.a.n.c.r.io.DisableOnCloseOutputStream.write(DisableOnCloseOutputStream.java:49)
> 
> Suppressed: java.lang.NullPointerException
> at 
> o.a.n.c.r.FileSystemRepository$2.flush(FileSystemRepository.java:934) 
> [nifi-framework-core-0.7.0.jar]
> at 
> o.a.n.c.r.io.DisableOnCloseOutputStream.close(DisableOnCloseOutputStream.java:68)
> {noformat}



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

[GitHub] nifi pull request #848: NIFI-2551: Addressed a threading issue in the Standa...

[markap14]

GitHub user markap14 opened a pull request:

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

NIFI-2551: Addressed a threading issue in the 
StandardResourceClaimManager…

… and performed some refactoring so that we can ensure thread-safety 
across different components of the application, such as ProcessSession and 
WriteAheadFlowFile Repository when interacting with the 
StandardResourceClaimManager. Update DebugFlow to allow it to write to a 
FlowFile multiple times, which exposes the concurrency bug. Also avoided 
calling ContentRepository.remove() from ProcessSession whenever the content is 
no longer needed, as that can cause problems now that the Resource Claim is 
backing the content claim.

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

$ git pull https://github.com/markap14/nifi NIFI-2551-1.x

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

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


commit 2c2b4e9a5ddf030b60631f8ef24fca3b8b5324d6
Author: Mark Payne 
Date:   2016-08-12T17:56:03Z

NIFI-2551: Addressed a threading issue in the StandardResourceClaimManager 
and performed some refactoring so that we can ensure thread-safety across 
different components of the application, such as ProcessSession and 
WriteAheadFlowFile Repository when interacting with the 
StandardResourceClaimManager. Update DebugFlow to allow it to write to a 
FlowFile multiple times, which exposes the concurrency bug. Also avoided 
calling ContentRepository.remove() from ProcessSession whenever the content is 
no longer needed, as that can cause problems now that the Resource Claim is 
backing the content claim.




---
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-2551) Rare condition causes FileSystemRepository NPE

[Michael Moser (JIRA)]

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

Michael Moser commented on NIFI-2551:
-

I will put this patch on our 0.7.0 system that had this issue and let it run, I 
guess over the weekend.

> Rare condition causes FileSystemRepository NPE
> --
>
> Key: NIFI-2551
> URL: https://issues.apache.org/jira/browse/NIFI-2551
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Michael Moser
>Assignee: Michael Moser
>Priority: Blocker
> Fix For: 1.0.0, 0.8.0
>
>
> In rare unpredictable cases when NiFi is processing a heavy load, we see 
> FileSystemRepository throw a NullPointerException
> {noformat}
> java.lang.NullPointerException
> at o.a.n.c.r.FileSystemRepository$2.write(FileSystemRepository.java:918) 
> [nifi-framework-core-0.7.0.jar]
> at 
> o.a.n.c.r.io.DisableOnCloseOutputStream.write(DisableOnCloseOutputStream.java:49)
> 
> Suppressed: java.lang.NullPointerException
> at 
> o.a.n.c.r.FileSystemRepository$2.flush(FileSystemRepository.java:934) 
> [nifi-framework-core-0.7.0.jar]
> at 
> o.a.n.c.r.io.DisableOnCloseOutputStream.close(DisableOnCloseOutputStream.java:68)
> {noformat}



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

[jira] [Updated] (NIFI-2560) Tune POP3/IMAP processors

[Oleg Zhurakousky (JIRA)]

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

Oleg Zhurakousky updated NIFI-2560:
---
Description: 
Couple of things needs a bit of tuning since people started to use it.
1. Expose connection timeout. This is primarily due to various providers acting 
differently (Gmail vs Yahoo etc)
2. Fix how yield() is invoked 

  was:
Couple of things needs a bit of tuning since people started to use it.
1. Expose connection timeout. This is primarily due to various providers acting 
differently (Gmail vs Yahoo etc)
2. Remove internal message queueing since after discussing its usage in 
ListenSMTP we've determined that it can lead to data-loss. Basically for each 
poll, get a single message.
3. Fix how yield() is invoked 


> Tune POP3/IMAP processors 
> --
>
> Key: NIFI-2560
> URL: https://issues.apache.org/jira/browse/NIFI-2560
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Oleg Zhurakousky
>Assignee: Oleg Zhurakousky
> Fix For: 1.0.0
>
>
> Couple of things needs a bit of tuning since people started to use it.
> 1. Expose connection timeout. This is primarily due to various providers 
> acting differently (Gmail vs Yahoo etc)
> 2. Fix how yield() is invoked 



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

[GitHub] nifi issue #827: NIFI-2519 Fixed and refactored ListenSMTP processor

[joewitt]

Github user joewitt commented on the issue:

https://github.com/apache/nifi/pull/827
  
the new PR uses instance array for buffer.  This will be a problem under 
multiple threads.

the references in LICENSE to JOpt Simple and JLines..is this copy and paste 
or are those really in the build?


---
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-2519) TestListenSMTP ValidEmail fails during parallel build

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2519:
--

Github user joewitt commented on the issue:

https://github.com/apache/nifi/pull/827
  
the new PR uses instance array for buffer.  This will be a problem under 
multiple threads.

the references in LICENSE to JOpt Simple and JLines..is this copy and paste 
or are those really in the build?


> TestListenSMTP ValidEmail fails during parallel build
> -
>
> Key: NIFI-2519
> URL: https://issues.apache.org/jira/browse/NIFI-2519
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Joseph Witt
>Assignee: Oleg Zhurakousky
> Fix For: 1.0.0
>
> Attachments: 
> 0001-NIFI-2519-fixed-max-connections-and-max-size-enforce.patch
>
>
> While running a full NiFi parallel build received the following. So there is 
> some test issue at least that is impacting build stability.
> [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
> nifi-email-processors ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 4 source files to 
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/test-classes
> [WARNING] 
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[122,24]
>  [deprecation] stop() in Thread has been deprecated
> [WARNING] 
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[186,24]
>  [deprecation] stop() in Thread has been deprecated
> [WARNING] 
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/test/java/org/apache/nifi/processors/email/TestListenSMTP.java:[307,24]
>  [deprecation] stop() in Thread has been deprecated
> [INFO] 
> [INFO] --- maven-compiler-plugin:3.2:testCompile (groovy-tests) @ 
> nifi-email-processors ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Nothing to compile - all classes are up to date
> [INFO] 
> [INFO] --- maven-surefire-plugin:2.18:test (default-test) @ 
> nifi-email-processors ---
> [INFO] Surefire report directory: 
> /home/travis/build/apache/nifi/nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/target/surefire-reports
> [INFO] Using configured provider 
> org.apache.maven.surefire.junit4.JUnit4Provider
> ---
>  T E S T S
> ---
> Running org.apache.nifi.processors.email.TestListenSMTP
> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.473 sec <<< 
> FAILURE! - in org.apache.nifi.processors.email.TestListenSMTP
> ValidEmail(org.apache.nifi.processors.email.TestListenSMTP)  Time elapsed: 
> 0.038 sec  <<< FAILURE!
> java.lang.AssertionError: Sending email failed
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertFalse(Assert.java:64)
>   at 
> org.apache.nifi.processors.email.TestListenSMTP.ValidEmail(TestListenSMTP.java:188)
> Running org.apache.nifi.processors.email.TestExtractEmailAttachments
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.1 sec - in 
> org.apache.nifi.processors.email.TestExtractEmailAttachments
> Running org.apache.nifi.processors.email.TestExtractEmailHeaders
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 sec - 
> in org.apache.nifi.processors.email.TestExtractEmailHeaders
> Results :
> Failed tests: 
>   TestListenSMTP.ValidEmail:188 Sending email failed



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

[jira] [Commented] (NIFI-2558) Content Viewer combo mis-aligned

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2558:
--

Github user scottyaslan closed the pull request at:

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


> Content Viewer combo mis-aligned
> 
>
> Key: NIFI-2558
> URL: https://issues.apache.org/jira/browse/NIFI-2558
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Scott Aslan
>Assignee: Scott Aslan
> Fix For: 1.0.0
>
>




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

[GitHub] nifi pull request #841: [NIFI-2558] adjust content viewer combo alignment

[scottyaslan]

Github user scottyaslan closed the pull request at:

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


---
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-2560) Tune POP3/IMAP processors

[Oleg Zhurakousky (JIRA)]

Oleg Zhurakousky created NIFI-2560:
--

 Summary: Tune POP3/IMAP processors 
 Key: NIFI-2560
 URL: https://issues.apache.org/jira/browse/NIFI-2560
 Project: Apache NiFi
  Issue Type: Improvement
Reporter: Oleg Zhurakousky
Assignee: Oleg Zhurakousky
 Fix For: 1.0.0


Couple of things needs a bit of tuning since people started to use it.
1. Expose connection timeout. This is primarily due to various providers acting 
differently (Gmail vs Yahoo etc)
2. Remove internal message queueing since after discussing its usage in 
ListenSMTP we've determined that it can lead to data-loss. Basically for each 
poll, get a single message.
3. Fix how yield() is invoked 



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

[jira] [Updated] (NIFI-2551) Rare condition causes FileSystemRepository NPE

[Mark Payne (JIRA)]

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

Mark Payne updated NIFI-2551:
-
Fix Version/s: 0.8.0
   1.0.0

> Rare condition causes FileSystemRepository NPE
> --
>
> Key: NIFI-2551
> URL: https://issues.apache.org/jira/browse/NIFI-2551
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Michael Moser
>Assignee: Michael Moser
>Priority: Blocker
> Fix For: 1.0.0, 0.8.0
>
>
> In rare unpredictable cases when NiFi is processing a heavy load, we see 
> FileSystemRepository throw a NullPointerException
> {noformat}
> java.lang.NullPointerException
> at o.a.n.c.r.FileSystemRepository$2.write(FileSystemRepository.java:918) 
> [nifi-framework-core-0.7.0.jar]
> at 
> o.a.n.c.r.io.DisableOnCloseOutputStream.write(DisableOnCloseOutputStream.java:49)
> 
> Suppressed: java.lang.NullPointerException
> at 
> o.a.n.c.r.FileSystemRepository$2.flush(FileSystemRepository.java:934) 
> [nifi-framework-core-0.7.0.jar]
> at 
> o.a.n.c.r.io.DisableOnCloseOutputStream.close(DisableOnCloseOutputStream.java:68)
> {noformat}



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

[jira] [Commented] (NIFI-2551) Rare condition causes FileSystemRepository NPE

[Mark Payne (JIRA)]

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

Mark Payne commented on NIFI-2551:
--

[~mosermw] i have posted a path. Please check it out when you get a chance.

> Rare condition causes FileSystemRepository NPE
> --
>
> Key: NIFI-2551
> URL: https://issues.apache.org/jira/browse/NIFI-2551
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Michael Moser
>Assignee: Michael Moser
>Priority: Blocker
> Fix For: 1.0.0, 0.8.0
>
>
> In rare unpredictable cases when NiFi is processing a heavy load, we see 
> FileSystemRepository throw a NullPointerException
> {noformat}
> java.lang.NullPointerException
> at o.a.n.c.r.FileSystemRepository$2.write(FileSystemRepository.java:918) 
> [nifi-framework-core-0.7.0.jar]
> at 
> o.a.n.c.r.io.DisableOnCloseOutputStream.write(DisableOnCloseOutputStream.java:49)
> 
> Suppressed: java.lang.NullPointerException
> at 
> o.a.n.c.r.FileSystemRepository$2.flush(FileSystemRepository.java:934) 
> [nifi-framework-core-0.7.0.jar]
> at 
> o.a.n.c.r.io.DisableOnCloseOutputStream.close(DisableOnCloseOutputStream.java:68)
> {noformat}



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

[GitHub] nifi pull request #847: NIFI-2551: Addressed a threading issue in the Standa...

[markap14]

GitHub user markap14 opened a pull request:

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

NIFI-2551: Addressed a threading issue in the 
StandardResourceClaimManager…

… and performed some refactoring so that we can ensure thread-safety 
across different components of the application, such as ProcessSession and 
WriteAheadFlowFile Repository when interacting with the 
StandardResourceClaimManager. Update DebugFlow to allow it to write to a 
FlowFile multiple times, which exposes the concurrency bug. Also avoided 
calling ContentRepository.remove() from ProcessSession whenever the content is 
no longer needed, as that can cause problems now that the Resource Claim is 
backing the content claim.

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

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

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

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


commit ec79ff0d6a595a969cf65ca9cd65d51caab08620
Author: Mark Payne 
Date:   2016-08-12T17:56:03Z

NIFI-2551: Addressed a threading issue in the StandardResourceClaimManager 
and performed some refactoring so that we can ensure thread-safety across 
different components of the application, such as ProcessSession and 
WriteAheadFlowFile Repository when interacting with the 
StandardResourceClaimManager. Update DebugFlow to allow it to write to a 
FlowFile multiple times, which exposes the concurrency bug. Also avoided 
calling ContentRepository.remove() from ProcessSession whenever the content is 
no longer needed, as that can cause problems now that the Resource Claim is 
backing the content claim.




---
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-2551) Rare condition causes FileSystemRepository NPE

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2551:
--

GitHub user markap14 opened a pull request:

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

NIFI-2551: Addressed a threading issue in the StandardResourceClaimManager…

… and performed some refactoring so that we can ensure thread-safety across 
different components of the application, such as ProcessSession and 
WriteAheadFlowFile Repository when interacting with the 
StandardResourceClaimManager. Update DebugFlow to allow it to write to a 
FlowFile multiple times, which exposes the concurrency bug. Also avoided 
calling ContentRepository.remove() from ProcessSession whenever the content is 
no longer needed, as that can cause problems now that the Resource Claim is 
backing the content claim.

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

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

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

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


commit ec79ff0d6a595a969cf65ca9cd65d51caab08620
Author: Mark Payne 
Date:   2016-08-12T17:56:03Z

NIFI-2551: Addressed a threading issue in the StandardResourceClaimManager 
and performed some refactoring so that we can ensure thread-safety across 
different components of the application, such as ProcessSession and 
WriteAheadFlowFile Repository when interacting with the 
StandardResourceClaimManager. Update DebugFlow to allow it to write to a 
FlowFile multiple times, which exposes the concurrency bug. Also avoided 
calling ContentRepository.remove() from ProcessSession whenever the content is 
no longer needed, as that can cause problems now that the Resource Claim is 
backing the content claim.




> Rare condition causes FileSystemRepository NPE
> --
>
> Key: NIFI-2551
> URL: https://issues.apache.org/jira/browse/NIFI-2551
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Michael Moser
>Assignee: Michael Moser
>Priority: Blocker
>
> In rare unpredictable cases when NiFi is processing a heavy load, we see 
> FileSystemRepository throw a NullPointerException
> {noformat}
> java.lang.NullPointerException
> at o.a.n.c.r.FileSystemRepository$2.write(FileSystemRepository.java:918) 
> [nifi-framework-core-0.7.0.jar]
> at 
> o.a.n.c.r.io.DisableOnCloseOutputStream.write(DisableOnCloseOutputStream.java:49)
> 
> Suppressed: java.lang.NullPointerException
> at 
> o.a.n.c.r.FileSystemRepository$2.flush(FileSystemRepository.java:934) 
> [nifi-framework-core-0.7.0.jar]
> at 
> o.a.n.c.r.io.DisableOnCloseOutputStream.close(DisableOnCloseOutputStream.java:68)
> {noformat}



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

[GitHub] nifi issue #655: DataDog support added

[JPercivall]

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/655
  
Also you can do "git clean -i -d" in order to clean your repo of things 
that aren't tracked and may have snuck in.


---
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 #655: DataDog support added

[JPercivall]

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/655
  
@Ramizjon awesome! Now you can try resetting back 9 commits, committing 
just your changes, resetting to HEAD --hard. Then rebasing to github/master 
(may need to do the ref/ thing again). 


---
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 #655: DataDog support added

[Ramizjon]

Github user Ramizjon commented on the issue:

https://github.com/apache/nifi/pull/655
  
@JPercivall Yes, it finally works. I received following message (when `git 
status`)

> 
> On branch master
> Your branch and 'remotes/github/master' have diverged,
> and have 9 and 34 different commits each, respectively.



---
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 #655: DataDog support added

[JPercivall]

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/655
  
Hey @Ramizjon, I'm actually multi-tasking on a couple of different things 
so can't jump on a call with you. Looking at this SO[1] try this:

`git branch master --set-upstream-to refs/remotes/github/master 

If that doesn't work I'll just work on squashing everything my self on my 
machine when I get a chance.

[1] 
http://stackoverflow.com/questions/3782893/git-fatal-ambiguous-object-name-origin-release-2-6


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

[GitHub] nifi issue #655: DataDog support added

[Ramizjon]

Github user Ramizjon commented on the issue:

https://github.com/apache/nifi/pull/655
  
@JPercivall still getting the same error. I've sent you an email, let me 
know about your decision, please


---
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 #655: DataDog support added

[JPercivall]

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/655
  
Ah ok, going off of this SO question[1] try:

`git branch master --set-upstream-to github/master`

[1] 
http://stackoverflow.com/questions/4878249/how-do-i-change-the-remote-a-git-branch-is-tracking


---
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 #655: DataDog support added

[Ramizjon]

Github user Ramizjon commented on the issue:

https://github.com/apache/nifi/pull/655
  
@JPercivall doing this steps causes following error (used 
`--set-upstream-to` as `--set-upstream` is deprecated:

> warning: refname 'github/master' is ambiguous.
> fatal: Ambiguous object name: 'github/master'. 




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

[GitHub] nifi issue #655: DataDog support added

[JPercivall]

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/655
  
Aha, let's first renaming the remote:

`git remote rename upstream github`

Then try setting it as the upstream again (added "/master" from before)

`git branch --set-upstream github/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-1876) Clustering - Merge all responses based on authorization

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-1876:
--

Github user JPercivall commented on the issue:

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


> Clustering - Merge all responses based on authorization
> ---
>
> Key: NIFI-1876
> URL: https://issues.apache.org/jira/browse/NIFI-1876
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Jeff Storck
> Fix For: 1.0.0
>
>
> Each node in a cluster may have a different view of the authorization access 
> policies simply to in the timing of updates. Because of this, all requests 
> need to be merged accordingly.
> Requests are directed at a specific resource. These would result in some 403 
> responses.
> Some requests are contain a filtered view of a number of resources. These 
> would need to be updated to return the most restrictive set of responses.



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

[GitHub] nifi issue #694: NIFI-1876 Implements merging of responses to successful req...

[JPercivall]

Github user JPercivall commented on the issue:

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


---
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 #655: DataDog support added

[JPercivall]

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/655
  
Hmmm the only odd difference between your "git status" and mine is that 
mine explictly states that it is up to date with the branch of the remote.

![screen shot 2016-08-12 at 12 28 38 
pm](https://cloud.githubusercontent.com/assets/11302527/17629454/6d8aa41a-6088-11e6-82cf-94356cbc1609.png)

If you do "git branch -v" do you have a branch named "upstream"?

Ah, lol that would be it.


---
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 #655: DataDog support added

[Ramizjon]

Github user Ramizjon commented on the issue:

https://github.com/apache/nifi/pull/655
  
@JPercivall Yes, as you can see, git status output changes, depending on my 
modifications.


![image](https://cloud.githubusercontent.com/assets/3027035/17629234/105775ea-60c2-11e6-8cf5-158116ac551c.png)

Btw, when i was trying to squash commits i tried all approaches described 
here, and neither of them seemed to work..

http://stackoverflow.com/questions/5189560/squash-my-last-x-commits-together-using-git

Ah, that's probably because my terminal window is set up transparent x)


---
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-2553) HDFS processors throwing exception from OnSchedule when directory is an invalid URI

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2553:
--

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

https://github.com/apache/nifi/pull/843#discussion_r74617540
  
--- Diff: 
nifi-nar-bundles/nifi-hadoop-bundle/nifi-hdfs-processors/src/main/java/org/apache/nifi/processors/hadoop/AbstractHadoopProcessor.java
 ---
@@ -90,20 +90,55 @@ public String toString() {
 }
 }
 
+// validator to ensure that valid EL expressions are used in the 
directory property
+static final Validator PATH_WITH_EL_VALIDATOR = new Validator() {
--- End diff --

Wondering if this could be in the standard validators class instead?  
There's an  ATTRIBUTE_EXPRESSION_LANGUAGE_VALIDATOR  that's unused but looks 
very similar, just doesn't have the non empty requirement. Seems like a few 
tweaks could make it more generic with broad application. Thoughts?


> HDFS processors throwing exception from OnSchedule when directory is an 
> invalid URI
> ---
>
> Key: NIFI-2553
> URL: https://issues.apache.org/jira/browse/NIFI-2553
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Minor
> Fix For: 1.0.0
>
>
> If you enter a directory string that results in an invalid URI, the HDFS 
> processors will throw an unexpected exception from OnScheduled because of a 
> logging statement on in AbstractHadoopProcessor:
> {code}
> getLogger().info("Initialized a new HDFS File System with working dir: {} 
> default block size: {} default replication: {} config: {}",
> new Object[] { fs.getWorkingDirectory(), 
> fs.getDefaultBlockSize(new Path(dir)), fs.getDefaultReplication(new 
> Path(dir)), config.toString() });
> {code}
> An example input for the directory that can produce this problem:
> data_${literal('testing'):substring(0,4)%7D
> In addition to this, FetchHDFS, ListHDFS, GetHDFS, and PutHDFS all create new 
> Path instances in their onTrigger methods from the same directory, outside of 
> a try/catch which would result in throwing a ProcessException (if it got past 
> the logging issue above).



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

[GitHub] nifi pull request #843: NIFI-2553 Fixing handling of Paths in HDFS processor...

[YolandaMDavis]

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

https://github.com/apache/nifi/pull/843#discussion_r74617540
  
--- Diff: 
nifi-nar-bundles/nifi-hadoop-bundle/nifi-hdfs-processors/src/main/java/org/apache/nifi/processors/hadoop/AbstractHadoopProcessor.java
 ---
@@ -90,20 +90,55 @@ public String toString() {
 }
 }
 
+// validator to ensure that valid EL expressions are used in the 
directory property
+static final Validator PATH_WITH_EL_VALIDATOR = new Validator() {
--- End diff --

Wondering if this could be in the standard validators class instead?  
There's an  ATTRIBUTE_EXPRESSION_LANGUAGE_VALIDATOR  that's unused but looks 
very similar, just doesn't have the non empty requirement. Seems like a few 
tweaks could make it more generic with broad application. Thoughts?


---
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 #655: DataDog support added

[JPercivall]

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/655
  
This is very odd. If you try modifying anything does the "git status" 
output change? I ask because, I tried searching for a possible solution and 
came across this SO question: 
http://stackoverflow.com/questions/22067873/git-nothing-to-commit-working-directory-clean

Does it sound like what is going on (up to date but have changes committed)?

Oh ok, from your pictures it looks like there are shadows so thought I'd 
offer the tip.


---
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 #655: DataDog support added

[Ramizjon]

Github user Ramizjon commented on the issue:

https://github.com/apache/nifi/pull/655
  
@JPercivall Yes, surely. So here is the output 

![image](https://cloud.githubusercontent.com/assets/3027035/17628584/bda927ba-60be-11e6-822f-24e80e62e752.png)

Yes, i know about that, thanks. I use Lightshot screenshot, it allows to 
copy to clipboard, save or instantly upload to server and retrieve a link.


---
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-2460) Add StringEscapeUtils function to Nifi Expression Language

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2460:
--

Github user devin-fisher closed the pull request at:

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


> Add StringEscapeUtils function to Nifi Expression Language
> --
>
> Key: NIFI-2460
> URL: https://issues.apache.org/jira/browse/NIFI-2460
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Devin Fisher
> Fix For: 1.0.0
>
>
> When using Nifi Expression Language to build up a transport format (like JSON 
> or XML) there is no go way to make sure that it has been properly escaped.  
> Example Use Case:
> When using PutHTTP to a Web Service that requires JSON input.  If the 
> incoming data could contain String with quotes or other disallow character in 
> JSON there is no reliable way to Escape the inputs as you put them into a 
> larger JSON object.
> Proposed Change: 
> StringEscapeUtils is part of apache commons-lang which is already a 
> dependency for nifi base POM. The functions in StringEscapeUtils can easily 
> be mapped into functions in nifi expression language.
> Work Done:
> I have the work done on a fork and am ready to submit a PR. That PR should 
> get good review since it is my first contribution (outside of a fixed typo) 



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

[GitHub] nifi pull request #777: Add String Escape Utils to Nifi Expression Language

[devin-fisher]

Github user devin-fisher closed the pull request at:

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


---
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-2557) Enhance Modal Plugin

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2557:
--

Github user mcgilman commented on the issue:

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


> Enhance Modal Plugin
> 
>
> Key: NIFI-2557
> URL: https://issues.apache.org/jira/browse/NIFI-2557
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Scott Aslan
>Assignee: Scott Aslan
> Fix For: 1.0.0
>
>
> Update the modal plugin to have all options be configurable through JS during 
> init. Options defined by HTML5 data attr (data-nf-dialog) will still be 
> supported but any options set with JS will have precedent leaving the 
> data-nf-dialog to persist the options for the modal.



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

[jira] [Updated] (NIFI-2557) Enhance Modal Plugin

[Matt Gilman (JIRA)]

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

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

> Enhance Modal Plugin
> 
>
> Key: NIFI-2557
> URL: https://issues.apache.org/jira/browse/NIFI-2557
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Scott Aslan
>Assignee: Scott Aslan
> Fix For: 1.0.0
>
>
> Update the modal plugin to have all options be configurable through JS during 
> init. Options defined by HTML5 data attr (data-nf-dialog) will still be 
> supported but any options set with JS will have precedent leaving the 
> data-nf-dialog to persist the options for the modal.



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

[jira] [Commented] (NIFI-2557) Enhance Modal Plugin

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2557:
--

Github user asfgit closed the pull request at:

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


> Enhance Modal Plugin
> 
>
> Key: NIFI-2557
> URL: https://issues.apache.org/jira/browse/NIFI-2557
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Scott Aslan
>Assignee: Scott Aslan
> Fix For: 1.0.0
>
>
> Update the modal plugin to have all options be configurable through JS during 
> init. Options defined by HTML5 data attr (data-nf-dialog) will still be 
> supported but any options set with JS will have precedent leaving the 
> data-nf-dialog to persist the options for the modal.



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

[jira] [Commented] (NIFI-2558) Content Viewer combo mis-aligned

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2558:
--

Github user mcgilman commented on the issue:

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


> Content Viewer combo mis-aligned
> 
>
> Key: NIFI-2558
> URL: https://issues.apache.org/jira/browse/NIFI-2558
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Scott Aslan
>Assignee: Scott Aslan
> Fix For: 1.0.0
>
>




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

[GitHub] nifi issue #841: [NIFI-2558] adjust content viewer combo alignment

[mcgilman]

Github user mcgilman commented on the issue:

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


---
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 #842: [NIFI-2557] Enhance Modal Plugin

[mcgilman]

Github user mcgilman commented on the issue:

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

[GitHub] nifi pull request #842: [NIFI-2557] Enhance Modal Plugin

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2557) Enhance Modal Plugin

[ASF subversion and git services (JIRA)]

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

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

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

[NIFI-2557] Enhance Modal Plugin. This closes #842


> Enhance Modal Plugin
> 
>
> Key: NIFI-2557
> URL: https://issues.apache.org/jira/browse/NIFI-2557
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Scott Aslan
>Assignee: Scott Aslan
> Fix For: 1.0.0
>
>
> Update the modal plugin to have all options be configurable through JS during 
> init. Options defined by HTML5 data attr (data-nf-dialog) will still be 
> supported but any options set with JS will have precedent leaving the 
> data-nf-dialog to persist the options for the modal.



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

[GitHub] nifi pull request #843: NIFI-2553 Fixing handling of Paths in HDFS processor...

[YolandaMDavis]

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

https://github.com/apache/nifi/pull/843#discussion_r74612515
  
--- Diff: 
nifi-nar-bundles/nifi-hadoop-bundle/nifi-hdfs-processors/src/main/java/org/apache/nifi/processors/hadoop/AbstractHadoopProcessor.java
 ---
@@ -286,8 +310,10 @@ HdfsResources resetHDFSResources(String 
configResources, String dir, ProcessCont
 }
 }
 
+final Path workingDir = fs.getWorkingDirectory();
 getLogger().info("Initialized a new HDFS File System with 
working dir: {} default block size: {} default replication: {} config: {}",
-new Object[] { fs.getWorkingDirectory(), 
fs.getDefaultBlockSize(new Path(dir)), fs.getDefaultReplication(new Path(dir)), 
config.toString() });
+new Object[]{workingDir, 
fs.getDefaultBlockSize(workingDir), fs.getDefaultReplication(workingDir), 
config.toString()});
--- End diff --

Noted this on the Jira 
([NIFI-2553](https://issues.apache.org/jira/browse/NIFI-2553)) but wanted to 
mention here as well.  Understood on the use of working directory for block 
size, curiously intrigued why path is even required,given the 
getDefulatBlockSize's implementation (noted in Jira comments). I think very 
small risk of implementation change on hadoop size causing a real relevance for 
the path (such as block size settings on directory level). So something to keep 
back of mind perhaps is a need to check if dir exists first and if not then use 
default?


---
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-2553) HDFS processors throwing exception from OnSchedule when directory is an invalid URI

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2553:
--

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

https://github.com/apache/nifi/pull/843#discussion_r74612515
  
--- Diff: 
nifi-nar-bundles/nifi-hadoop-bundle/nifi-hdfs-processors/src/main/java/org/apache/nifi/processors/hadoop/AbstractHadoopProcessor.java
 ---
@@ -286,8 +310,10 @@ HdfsResources resetHDFSResources(String 
configResources, String dir, ProcessCont
 }
 }
 
+final Path workingDir = fs.getWorkingDirectory();
 getLogger().info("Initialized a new HDFS File System with 
working dir: {} default block size: {} default replication: {} config: {}",
-new Object[] { fs.getWorkingDirectory(), 
fs.getDefaultBlockSize(new Path(dir)), fs.getDefaultReplication(new Path(dir)), 
config.toString() });
+new Object[]{workingDir, 
fs.getDefaultBlockSize(workingDir), fs.getDefaultReplication(workingDir), 
config.toString()});
--- End diff --

Noted this on the Jira 
([NIFI-2553](https://issues.apache.org/jira/browse/NIFI-2553)) but wanted to 
mention here as well.  Understood on the use of working directory for block 
size, curiously intrigued why path is even required,given the 
getDefulatBlockSize's implementation (noted in Jira comments). I think very 
small risk of implementation change on hadoop size causing a real relevance for 
the path (such as block size settings on directory level). So something to keep 
back of mind perhaps is a need to check if dir exists first and if not then use 
default?


> HDFS processors throwing exception from OnSchedule when directory is an 
> invalid URI
> ---
>
> Key: NIFI-2553
> URL: https://issues.apache.org/jira/browse/NIFI-2553
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Minor
> Fix For: 1.0.0
>
>
> If you enter a directory string that results in an invalid URI, the HDFS 
> processors will throw an unexpected exception from OnScheduled because of a 
> logging statement on in AbstractHadoopProcessor:
> {code}
> getLogger().info("Initialized a new HDFS File System with working dir: {} 
> default block size: {} default replication: {} config: {}",
> new Object[] { fs.getWorkingDirectory(), 
> fs.getDefaultBlockSize(new Path(dir)), fs.getDefaultReplication(new 
> Path(dir)), config.toString() });
> {code}
> An example input for the directory that can produce this problem:
> data_${literal('testing'):substring(0,4)%7D
> In addition to this, FetchHDFS, ListHDFS, GetHDFS, and PutHDFS all create new 
> Path instances in their onTrigger methods from the same directory, outside of 
> a try/catch which would result in throwing a ProcessException (if it got past 
> the logging issue above).



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

[GitHub] nifi issue #777: Add String Escape Utils to Nifi Expression Language

[mattyb149]

Github user mattyb149 commented on the issue:

https://github.com/apache/nifi/pull/777
  
#833 has been merged (thanks again!) Would you mind closing this 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-2460) Add StringEscapeUtils function to Nifi Expression Language

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2460:
--

Github user asfgit closed the pull request at:

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


> Add StringEscapeUtils function to Nifi Expression Language
> --
>
> Key: NIFI-2460
> URL: https://issues.apache.org/jira/browse/NIFI-2460
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Devin Fisher
> Fix For: 1.0.0
>
>
> When using Nifi Expression Language to build up a transport format (like JSON 
> or XML) there is no go way to make sure that it has been properly escaped.  
> Example Use Case:
> When using PutHTTP to a Web Service that requires JSON input.  If the 
> incoming data could contain String with quotes or other disallow character in 
> JSON there is no reliable way to Escape the inputs as you put them into a 
> larger JSON object.
> Proposed Change: 
> StringEscapeUtils is part of apache commons-lang which is already a 
> dependency for nifi base POM. The functions in StringEscapeUtils can easily 
> be mapped into functions in nifi expression language.
> Work Done:
> I have the work done on a fork and am ready to submit a PR. That PR should 
> get good review since it is my first contribution (outside of a fixed typo) 



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

[jira] [Updated] (NIFI-2460) Add StringEscapeUtils function to Nifi Expression Language

[Matt Burgess (JIRA)]

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

Matt Burgess updated NIFI-2460:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Add StringEscapeUtils function to Nifi Expression Language
> --
>
> Key: NIFI-2460
> URL: https://issues.apache.org/jira/browse/NIFI-2460
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Devin Fisher
>
> When using Nifi Expression Language to build up a transport format (like JSON 
> or XML) there is no go way to make sure that it has been properly escaped.  
> Example Use Case:
> When using PutHTTP to a Web Service that requires JSON input.  If the 
> incoming data could contain String with quotes or other disallow character in 
> JSON there is no reliable way to Escape the inputs as you put them into a 
> larger JSON object.
> Proposed Change: 
> StringEscapeUtils is part of apache commons-lang which is already a 
> dependency for nifi base POM. The functions in StringEscapeUtils can easily 
> be mapped into functions in nifi expression language.
> Work Done:
> I have the work done on a fork and am ready to submit a PR. That PR should 
> get good review since it is my first contribution (outside of a fixed typo) 



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

[GitHub] nifi pull request #833: Add String Escape Utils to Nifi Expression Language ...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2460) Add StringEscapeUtils function to Nifi Expression Language

[Matt Burgess (JIRA)]

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

Matt Burgess updated NIFI-2460:
---
Fix Version/s: 1.0.0

> Add StringEscapeUtils function to Nifi Expression Language
> --
>
> Key: NIFI-2460
> URL: https://issues.apache.org/jira/browse/NIFI-2460
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Devin Fisher
> Fix For: 1.0.0
>
>
> When using Nifi Expression Language to build up a transport format (like JSON 
> or XML) there is no go way to make sure that it has been properly escaped.  
> Example Use Case:
> When using PutHTTP to a Web Service that requires JSON input.  If the 
> incoming data could contain String with quotes or other disallow character in 
> JSON there is no reliable way to Escape the inputs as you put them into a 
> larger JSON object.
> Proposed Change: 
> StringEscapeUtils is part of apache commons-lang which is already a 
> dependency for nifi base POM. The functions in StringEscapeUtils can easily 
> be mapped into functions in nifi expression language.
> Work Done:
> I have the work done on a fork and am ready to submit a PR. That PR should 
> get good review since it is my first contribution (outside of a fixed typo) 



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

[GitHub] nifi issue #833: Add String Escape Utils to Nifi Expression Language (redo)

[mattyb149]

Github user mattyb149 commented on the issue:

https://github.com/apache/nifi/pull/833
  
+1 Great job! I built, ran, and tested the functions with escaped/unescaped 
inputs and empty strings, everything works well.  Thanks again for the 
contribution! Will merge 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-2551) Rare condition causes FileSystemRepository NPE

[Mark Payne (JIRA)]

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

Mark Payne commented on NIFI-2551:
--

[~mosermw] - I hear ya - this part of the code base is far from trivial! On the 
up side, the patch that I am putting together does make it a little easier to 
understand, I believe (in addition to making it more correct :)). The only 
thing left I think is to figure out how exactly to handle the case where 
ProcessSession is calling remove(). That is no longer necessary or correct. We 
could simply replace it with an 'archive or remove, depending on whether or not 
archive is enabled' type of feature. But I think we can be smarter about how to 
handle it.

> Rare condition causes FileSystemRepository NPE
> --
>
> Key: NIFI-2551
> URL: https://issues.apache.org/jira/browse/NIFI-2551
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Michael Moser
>Assignee: Michael Moser
>Priority: Blocker
>
> In rare unpredictable cases when NiFi is processing a heavy load, we see 
> FileSystemRepository throw a NullPointerException
> {noformat}
> java.lang.NullPointerException
> at o.a.n.c.r.FileSystemRepository$2.write(FileSystemRepository.java:918) 
> [nifi-framework-core-0.7.0.jar]
> at 
> o.a.n.c.r.io.DisableOnCloseOutputStream.write(DisableOnCloseOutputStream.java:49)
> 
> Suppressed: java.lang.NullPointerException
> at 
> o.a.n.c.r.FileSystemRepository$2.flush(FileSystemRepository.java:934) 
> [nifi-framework-core-0.7.0.jar]
> at 
> o.a.n.c.r.io.DisableOnCloseOutputStream.close(DisableOnCloseOutputStream.java:68)
> {noformat}



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

[GitHub] nifi issue #655: DataDog support added

[JPercivall]

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/655
  
Well that is very weird. Could you do a "get fetch --all" and then "git 
status" and take a screenshot of the output?

Also Mac is super easy to take screen shots on, just hit `command` `shift` 
`4`, then you can click and drag to select what to screenshot (hitting 3 takes 
the entire screen). It saves it as a file to the desktop.


---
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 #655: DataDog support added

[Ramizjon]

Github user Ramizjon commented on the issue:

https://github.com/apache/nifi/pull/655
  
@JPercivall actually not. I see my commit first in the git log(screenshot 
attached)


![image](https://cloud.githubusercontent.com/assets/3027035/17626331/875b5722-60b5-11e6-9ce7-3ac42723911b.png)



---
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-1876) Clustering - Merge all responses based on authorization

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-1876:
--

Github user jtstorck commented on the issue:

https://github.com/apache/nifi/pull/694
  
PropertyDescriptor merging has been added, and the Summary view now shows 
components property based on permissions.  Ready for review.


> Clustering - Merge all responses based on authorization
> ---
>
> Key: NIFI-1876
> URL: https://issues.apache.org/jira/browse/NIFI-1876
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Jeff Storck
> Fix For: 1.0.0
>
>
> Each node in a cluster may have a different view of the authorization access 
> policies simply to in the timing of updates. Because of this, all requests 
> need to be merged accordingly.
> Requests are directed at a specific resource. These would result in some 403 
> responses.
> Some requests are contain a filtered view of a number of resources. These 
> would need to be updated to return the most restrictive set of responses.



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

[jira] [Commented] (NIFI-2542) Revisions for Controller Service Referencing Components

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2542:
--

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/655
  
@Ramizjon Hmmm, that is unexpected. When you do `git log` do you see 
"commit fa639e2596cc125af80615066f500cc908d4db6a" as the first (Matt Gilman's 
commit for NIFI-2542)? Sorry I thought master still had the changes you made


> Revisions for Controller Service Referencing Components
> ---
>
> Key: NIFI-2542
> URL: https://issues.apache.org/jira/browse/NIFI-2542
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework, Core UI
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>Priority: Critical
> Fix For: 1.0.0
>
>
> The revisions for components that reference controller services transitively 
> are not available when generating the response DTOs.
> Additionally, it doesn't appear that the transitive references are being 
> returned or rendered correctly. It is unclear which is the case due to the 
> issue described above.



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

[GitHub] nifi issue #655: DataDog support added

[JPercivall]

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/655
  
@Ramizjon Hmmm, that is unexpected. When you do `git log` do you see 
"commit fa639e2596cc125af80615066f500cc908d4db6a" as the first (Matt Gilman's 
commit for NIFI-2542)? Sorry I thought master still had the changes you made


---
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-2551) Rare condition causes FileSystemRepository NPE

[Michael Moser (JIRA)]

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

Michael Moser commented on NIFI-2551:
-

[~markap14] This really is great news and I'm happy someone who understands 
that code better than I do could jump in.  There are lots of moving parts in 
there, and I had a bad feeling the patch I provided just wasn't going to be the 
best solution.  Looking forward to trying your patch instead.

> Rare condition causes FileSystemRepository NPE
> --
>
> Key: NIFI-2551
> URL: https://issues.apache.org/jira/browse/NIFI-2551
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Michael Moser
>Assignee: Michael Moser
>Priority: Blocker
>
> In rare unpredictable cases when NiFi is processing a heavy load, we see 
> FileSystemRepository throw a NullPointerException
> {noformat}
> java.lang.NullPointerException
> at o.a.n.c.r.FileSystemRepository$2.write(FileSystemRepository.java:918) 
> [nifi-framework-core-0.7.0.jar]
> at 
> o.a.n.c.r.io.DisableOnCloseOutputStream.write(DisableOnCloseOutputStream.java:49)
> 
> Suppressed: java.lang.NullPointerException
> at 
> o.a.n.c.r.FileSystemRepository$2.flush(FileSystemRepository.java:934) 
> [nifi-framework-core-0.7.0.jar]
> at 
> o.a.n.c.r.io.DisableOnCloseOutputStream.close(DisableOnCloseOutputStream.java:68)
> {noformat}



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