[jira] [Commented] (NIFIREG-76) Improve error messages from server for constraint violations

[ASF GitHub Bot (JIRA)]

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

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

Github user kevdoran commented on the issue:

https://github.com/apache/nifi-registry/pull/67
  
https://user-images.githubusercontent.com/5102332/34287087-ec5bdb04-e6b2-11e7-8be6-c55d95dac115.png;>

Nice work!


> Improve error messages from server for constraint violations
> 
>
> Key: NIFIREG-76
> URL: https://issues.apache.org/jira/browse/NIFIREG-76
> Project: NiFi Registry
>  Issue Type: Improvement
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Minor
> Fix For: 0.0.1
>
>
> Currently the java validation framework is producing a response with a json 
> array of violations, but we should change this to the appropriate text-based 
> response like our other exception mappers.



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

[GitHub] nifi-registry issue #67: NIFIREG-76 Adding exception mapper for ConstraintVi...

[kevdoran]

Github user kevdoran commented on the issue:

https://github.com/apache/nifi-registry/pull/67
  
https://user-images.githubusercontent.com/5102332/34287087-ec5bdb04-e6b2-11e7-8be6-c55d95dac115.png;>

Nice work!


---

[jira] [Commented] (NIFIREG-75) Composite and CompositeConfigurable UserGroupProviders don't consider all providers when looking up users and groups

[ASF GitHub Bot (JIRA)]

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

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

Github user kevdoran commented on the issue:

https://github.com/apache/nifi-registry/pull/64
  
This has been updated with the latest approach


> Composite and CompositeConfigurable UserGroupProviders don't consider all 
> providers when looking up users and groups
> 
>
> Key: NIFIREG-75
> URL: https://issues.apache.org/jira/browse/NIFIREG-75
> Project: NiFi Registry
>  Issue Type: Bug
>Reporter: Kevin Doran
>Assignee: Kevin Doran
> Fix For: 0.0.1
>
>
> In FileUserGroupProvider, when a new group is created, all the users in the 
> group are checked to ensure they are known to the FileUserGroupProvider prior 
> to creating the group.
> This check should be removed, and an integrity check should be placed in the 
> entity managing all user group providers (eg, CompositeUserGroupProvider and 
> CompositeConfigurableUserGroupProvider).
> Also, when loading a user identity, all UserGroupProviders should be 
> considered for finding groups the user to which the user belongs.



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

[GitHub] nifi-registry issue #64: NIFIREG-75 Fix User Group Data Integrity Checks

[kevdoran]

Github user kevdoran commented on the issue:

https://github.com/apache/nifi-registry/pull/64
  
This has been updated with the latest approach


---

[jira] [Created] (NIFIREG-82) Properly handle when someone goes to registry but without the "/nifi-registry/" path

[Joseph Percivall (JIRA)]

Joseph Percivall created NIFIREG-82:
---

 Summary: Properly handle when someone goes to registry but without 
the "/nifi-registry/" path
 Key: NIFIREG-82
 URL: https://issues.apache.org/jira/browse/NIFIREG-82
 Project: NiFi Registry
  Issue Type: Improvement
Reporter: Joseph Percivall
Priority: Trivial


Currently, Registry goes to the Jetty 404 page. We should have something 
similar to NiFi with the page that says "Did you mean: /nifiYou may have 
mistyped"



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

[GitHub] nifi issue #2219: NiFi-4436: Add UI controls for starting/stopping/reverting...

[JPercivall]

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/2219
  
Small bug with the visuals on nested flows:

- Start with a versioned flow that contains a nested versioned flow. Both 
are up to date.
- Make a change to the nested flow.
- Notice that it correctly has the "*" saying it has local uncommitted 
changes.
- Go to the top versioned flow, notice that it says that it is still up to 
date.

This is different than if the nested flow wasn't versioned. In that case, 
the top level properly shows the "*".

Fortunately, if I go to commit the top level versioned flow it correctly 
tells me I can't because I have a nested versioned flow with uncommitted 
changes.



---

[jira] [Updated] (NIFIREG-77) Allow a user to see the changes created by the currently loaded version

[Joseph Percivall (JIRA)]

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

Joseph Percivall updated NIFIREG-77:

Priority: Critical  (was: Major)

> Allow a user to see the changes created by the currently loaded version
> ---
>
> Key: NIFIREG-77
> URL: https://issues.apache.org/jira/browse/NIFIREG-77
> Project: NiFi Registry
>  Issue Type: Improvement
>Reporter: Joseph Percivall
>Priority: Critical
>
> As a user, I would like to see the changes that are included in a particular 
> version. More specifically, if I'm on an old version and I upgrade to a 
> version written by someone else, I have no way to know what changes occurred 
> during that version upgrade.
> A simple solution would be to utilize the same logic which displays the 
> current differences between local and stored in the registry and use that to 
> show the differences between the current version N and version N-1. The user 
> could then change between versions to see the changes that happened as part 
> of that version.
> An even better solution (from a DFM perspective) would be to be able to see 
> the changes within any version (not just the most recent). That way a DFM 
> wouldn't have to stop the flow for an extended period of time to view the 
> changes/differences in different versions but I think that'd be more work.



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

[jira] [Created] (NIFIREG-81) Variable Registry properties that are expected for a versioned Flow should be tracked

[Joseph Percivall (JIRA)]

Joseph Percivall created NIFIREG-81:
---

 Summary: Variable Registry properties that are expected for a 
versioned Flow should be tracked 
 Key: NIFIREG-81
 URL: https://issues.apache.org/jira/browse/NIFIREG-81
 Project: NiFi Registry
  Issue Type: Improvement
Reporter: Joseph Percivall


As a user, pulling down a new versioned flow, I'd like to know which properties 
are expected in my NiFi's Variable Registry to run the flow. By explicitly 
calling these out I can more easily configure and understand the flow on 
deployment. Also, would facilitate maintainability. 

An easy example of a typical flow that would utilize this is one that relies on 
an external source which is configured per environment (SSL file paths, Web 
service URL, etc.).

This could also pave the way to set "default" variables within a Registry 
instance and elsewhere.



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

[jira] [Created] (NIFIREG-80) Flows and their versions should be exportable & importable from the UI

[Joseph Percivall (JIRA)]

Joseph Percivall created NIFIREG-80:
---

 Summary: Flows and their versions should be exportable & 
importable from the UI
 Key: NIFIREG-80
 URL: https://issues.apache.org/jira/browse/NIFIREG-80
 Project: NiFi Registry
  Issue Type: Improvement
Reporter: Joseph Percivall


As a user, I would like to be able to develop a flow in one place using one 
registry then deploy and continually update that versioned flow to another 
location (no network connectivity between the two). This could be done by 
exporting flow and the different versions and allowing them to be uploaded to 
the UI.

This is similar to how you can create patches in git to be applied in other 
repos. 

If my understanding is correct, this should be able to be done by using the 
same REST endpoints that NiFi uses.



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

[GitHub] nifi issue #2219: NiFi-4436: Add UI controls for starting/stopping/reverting...

[JPercivall]

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/2219
  
Not sure if I should comment here or capture in a new ticket since this PR 
is so big but from the Registry Clients page, it would be nice to have an icon 
to click to open the Registry in a new tab.


---

[jira] [Created] (NIFIREG-79) Explorer Grid-list should better convey when there are no items

[Joseph Percivall (JIRA)]

Joseph Percivall created NIFIREG-79:
---

 Summary: Explorer Grid-list should better convey when there are no 
items
 Key: NIFIREG-79
 URL: https://issues.apache.org/jira/browse/NIFIREG-79
 Project: NiFi Registry
  Issue Type: Improvement
Reporter: Joseph Percivall
Priority: Minor


Currently, the explorer page (under grid-list) says "No results match this 
query." when there are no items within the current view. As a new user, I was 
confused why, after I had just created a bucket, there was nothing populated 
here. A message better tailored to what is not being shown would be preferred. 

For example, at the base level, the message could be: "You have X buckets but 
there are no items currently loaded into those buckets". For a specific bucket 
"You currently have no items loaded into the XYZ bucket".



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

[jira] [Created] (NIFIREG-78) Bucket policies should be unavailable when running unsecured

[Joseph Percivall (JIRA)]

Joseph Percivall created NIFIREG-78:
---

 Summary: Bucket policies should be unavailable when running 
unsecured
 Key: NIFIREG-78
 URL: https://issues.apache.org/jira/browse/NIFIREG-78
 Project: NiFi Registry
  Issue Type: Bug
Reporter: Joseph Percivall
Priority: Minor


As far as I'm aware, bucket policies are only used when the security settings 
are enabled (same as the Users). If so, the UI should more clearly convey this 
and the "NEW POLICY" button should be disabled.



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

[jira] [Updated] (NIFI-4721) Single quotes within a process group name causes the characters within the Variables menu

[Joseph Percivall (JIRA)]

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

Joseph Percivall updated NIFI-4721:
---
Attachment: Screen Shot 2017-12-21 at 8.50.37 PM.png

> Single quotes within a process group name causes the characters  within 
> the Variables menu
> ---
>
> Key: NIFI-4721
> URL: https://issues.apache.org/jira/browse/NIFI-4721
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Joseph Percivall
>Priority: Minor
> Attachments: Screen Shot 2017-12-21 at 8.50.37 PM.png
>
>
> Found while testing NiFi-4436:
> I set the process group name to "Developer's_first versioned process group"
> Within the Variables configuration window I see "Developers_first 
> versioned process group" as the name under "Process Group".



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

[jira] [Commented] (NIFI-4721) Single quotes within a process group name causes the characters within the Variables menu

[Joseph Percivall (JIRA)]

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

Joseph Percivall commented on NIFI-4721:


[~mcgilman] I found this while testing NIFI-4436. I didn't think it was related 
so I created a new ticket.

> Single quotes within a process group name causes the characters  within 
> the Variables menu
> ---
>
> Key: NIFI-4721
> URL: https://issues.apache.org/jira/browse/NIFI-4721
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Joseph Percivall
>Priority: Minor
>
> Found while testing NiFi-4436:
> I set the process group name to "Developer's_first versioned process group"
> Within the Variables configuration window I see "Developers_first 
> versioned process group" as the name under "Process Group".



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

[jira] [Created] (NIFI-4721) Single quotes within a process group name causes the characters within the Variables menu

[Joseph Percivall (JIRA)]

Joseph Percivall created NIFI-4721:
--

 Summary: Single quotes within a process group name causes the 
characters  within the Variables menu
 Key: NIFI-4721
 URL: https://issues.apache.org/jira/browse/NIFI-4721
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core UI
Reporter: Joseph Percivall
Priority: Minor


Found while testing NiFi-4436:

I set the process group name to "Developer's_first versioned process group"

Within the Variables configuration window I see "Developers_first 
versioned process group" as the name under "Process Group".




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

[jira] [Created] (NIFIREG-77) Allow a user to see the changes created by the currently loaded version

[Joseph Percivall (JIRA)]

Joseph Percivall created NIFIREG-77:
---

 Summary: Allow a user to see the changes created by the currently 
loaded version
 Key: NIFIREG-77
 URL: https://issues.apache.org/jira/browse/NIFIREG-77
 Project: NiFi Registry
  Issue Type: Improvement
Reporter: Joseph Percivall


As a user, I would like to see the changes that are included in a particular 
version. More specifically, if I'm on an old version and I upgrade to a version 
written by someone else, I have no way to know what changes occurred during 
that version upgrade.

A simple solution would be to utilize the same logic which displays the current 
differences between local and stored in the registry and use that to show the 
differences between the current version N and version N-1. The user could then 
change between versions to see the changes that happened as part of that 
version.

An even better solution (from a DFM perspective) would be to be able to see the 
changes within any version (not just the most recent). That way a DFM wouldn't 
have to stop the flow for an extended period of time to view the 
changes/differences in different versions but I think that'd be more work.



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

[jira] [Created] (NIFI-4720) Expression Language guide explanation of order of evaluating an attribute is out of date

[Joseph Percivall (JIRA)]

Joseph Percivall created NIFI-4720:
--

 Summary: Expression Language guide explanation of order of 
evaluating an attribute is out of date
 Key: NIFI-4720
 URL: https://issues.apache.org/jira/browse/NIFI-4720
 Project: Apache NiFi
  Issue Type: Bug
  Components: Documentation & Website
Reporter: Joseph Percivall
Priority: Minor


In the Expression Language guide, under "Structure of a NiFi Expression"[1], it 
explains the order in which the different sources of attribute values are 
processed but doesn't include recent updates to EL. Essentially, this should 
summarize the resolution precedence stated in the User Guide[2].

{quote}In this example, the value to be returned is the value of the "my 
attribute" value, if it exists. If that attribute does not exist, the 
Expression Language will then look for a System Environment Variable named "my 
attribute." If unable to find this, it will look for a JVM System Property 
named "my attribute." Finally, if none of these exists, the Expression Language 
will return a null value.{quote}

[1] 
https://nifi.apache.org/docs/nifi-docs/html/expression-language-guide.html#structure
[2] 
https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#Using_Custom_Properties





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

[jira] [Commented] (MINIFICPP-355) Starting minifi on arm fails quietly

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MINIFICPP-355:
--

GitHub user phrocker opened a pull request:

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

MINIFICPP-355: Resolve issue with 32-bit systems using strtol convert…

…ing to long long.

Change log to INFO by default

Disable C2 services to we don't consume unnecessary threads.

Reduce logging verbosity in cases where we are printing debug messages to 
info.

Resolve spurious test failure because of port collision

Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced
 in the commit message?

- [ ] Does your PR title start with MINIFI- where  is the JIRA 
number you are trying to resolve? Pay particular attention to the hyphen "-" 
character.

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [ ] Is your initial contribution a single, squashed commit?

### For code changes:
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] If applicable, have you updated the LICENSE file?
- [ ] If applicable, have you updated the NOTICE file?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


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

$ git pull https://github.com/phrocker/nifi-minifi-cpp MINIFICPP-355

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

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


commit b4da2d74ab620813d2f3b04120577fef45cc0005
Author: Marc Parisi 
Date:   2017-12-22T00:59:29Z

MINIFICPP-355: Resolve issue with 32-bit systems using strtol converting to 
long long.

Change log to INFO by default

Disable C2 services to we don't consume unnecessary threads.

Reduce logging verbosity in cases where we are printing debug messages to 
info.

Resolve spurious test failure because of port collision




> Starting minifi on arm fails quietly
> 
>
> Key: MINIFICPP-355
> URL: https://issues.apache.org/jira/browse/MINIFICPP-355
> Project: NiFi MiNiFi C++
>  Issue Type: Bug
>Affects Versions: 0.3.0
> Environment: raspberry pi zero w - arm
>Reporter: Joseph Witt
> Attachments: config.yml, minifi-app.log
>
>
> During startup the process quietly dies.  Aldrin showed me the cool process 
> to gather more data
> gdb bin/minifi
> -> run
> -> backtrace
> which yields 
> {quote}
> [Thread 0xb0eff160 (LWP 24133) exited]
> [Thread 0xb2eff160 (LWP 24138) exited]
> Thread 1 "minifi" received signal SIGSEGV, Segmentation fault.
> strlen () at ../sysdeps/arm/armv6/strlen.S:26
> 26../sysdeps/arm/armv6/strlen.S: No such file or directory.
> (gdb) backtrace
> #0  strlen () at ../sysdeps/arm/armv6/strlen.S:26
> #1  0xb64f0690 in _IO_vfprintf_internal (s=s@entry=0xbeffc3c0, 
> format=format@entry=0x609884 "Setting %d as the max queue size for %s", 
> ap=..., ap@entry=...)
> at vfprintf.c:1637
> #2  0xb6513d2c in _IO_vsnprintf (string=0xbeffc4f0 "Setting 0 as the max 
> queue size for p => [success]", maxlen=,
> format=0x609884 "Setting %d as the max queue size for %s", 
> format@entry=0xbeffcac8 "\330\033\207", args=..., args@entry=...) at 
> vsnprintf.c:114
> #3  0xb64f5b18 in __snprintf (s=, maxlen=, 
> format=0x609884 "Setting %d as the max queue size for %s") at snprintf.c:33
> #4  0x00284a4c in std::__cxx11::basic_string std::allocator > 
> org::apache::nifi::minifi::core::logging::format_string const*>(char const*, long long&&, char const*&&) [clone .isra.369] ()
> #5  0x00285dec in void 
> org::apache::nifi::minifi::core::logging::Logger::log std::__cxx11::basic_string > >(spdlog::level::level_enum, char const*, long long const&, 
> std::__cxx11::basic_string > const&) ()
> 

[GitHub] nifi-minifi-cpp pull request #227: MINIFICPP-355: Resolve issue with 32-bit ...

[phrocker]

GitHub user phrocker opened a pull request:

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

MINIFICPP-355: Resolve issue with 32-bit systems using strtol convert…

…ing to long long.

Change log to INFO by default

Disable C2 services to we don't consume unnecessary threads.

Reduce logging verbosity in cases where we are printing debug messages to 
info.

Resolve spurious test failure because of port collision

Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced
 in the commit message?

- [ ] Does your PR title start with MINIFI- where  is the JIRA 
number you are trying to resolve? Pay particular attention to the hyphen "-" 
character.

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [ ] Is your initial contribution a single, squashed commit?

### For code changes:
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] If applicable, have you updated the LICENSE file?
- [ ] If applicable, have you updated the NOTICE file?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


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

$ git pull https://github.com/phrocker/nifi-minifi-cpp MINIFICPP-355

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

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


commit b4da2d74ab620813d2f3b04120577fef45cc0005
Author: Marc Parisi 
Date:   2017-12-22T00:59:29Z

MINIFICPP-355: Resolve issue with 32-bit systems using strtol converting to 
long long.

Change log to INFO by default

Disable C2 services to we don't consume unnecessary threads.

Reduce logging verbosity in cases where we are printing debug messages to 
info.

Resolve spurious test failure because of port collision




---

[jira] [Commented] (NIFIREG-76) Improve error messages from server for constraint violations

[ASF GitHub Bot (JIRA)]

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

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

GitHub user bbende opened a pull request:

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

NIFIREG-76 Adding exception mapper for ConstraintViolationException, …

…and validating blank names on updates

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

$ git pull https://github.com/bbende/nifi-registry NIFIREG-76

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

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


commit 193484f64b15c264fc3fd6ebead71cc0ff230863
Author: Bryan Bende 
Date:   2017-12-21T22:08:31Z

NIFIREG-76 Adding exception mapper for ConstraintViolationException, and 
validating blank names on updates




> Improve error messages from server for constraint violations
> 
>
> Key: NIFIREG-76
> URL: https://issues.apache.org/jira/browse/NIFIREG-76
> Project: NiFi Registry
>  Issue Type: Improvement
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Minor
> Fix For: 0.0.1
>
>
> Currently the java validation framework is producing a response with a json 
> array of violations, but we should change this to the appropriate text-based 
> response like our other exception mappers.



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

[GitHub] nifi-registry pull request #67: NIFIREG-76 Adding exception mapper for Const...

[bbende]

GitHub user bbende opened a pull request:

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

NIFIREG-76 Adding exception mapper for ConstraintViolationException, …

…and validating blank names on updates

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

$ git pull https://github.com/bbende/nifi-registry NIFIREG-76

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

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


commit 193484f64b15c264fc3fd6ebead71cc0ff230863
Author: Bryan Bende 
Date:   2017-12-21T22:08:31Z

NIFIREG-76 Adding exception mapper for ConstraintViolationException, and 
validating blank names on updates




---

[jira] [Commented] (NIFIREG-14) Remove the FDS demo from the registry app

[ASF GitHub Bot (JIRA)]

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

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

GitHub user scottyaslan opened a pull request:

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

[NIFIREG-14] remove fds demo



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

$ git pull https://github.com/scottyaslan/nifi-registry NIFIREG-14

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

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


commit d9b15ce9dc382bcf9906135025d040fe635b444c
Author: Scott Aslan 
Date:   2017-12-21T22:07:57Z

[NIFIREG-14] remove fds demo




> Remove the FDS demo from the registry app
> -
>
> Key: NIFIREG-14
> URL: https://issues.apache.org/jira/browse/NIFIREG-14
> Project: NiFi Registry
>  Issue Type: Sub-task
>Reporter: Scott Aslan
>Assignee: Scott Aslan
>Priority: Minor
>
> -Add ASLv2 LICENSE and NOTICE
> -Remove fds demo from registry app (move demo to gh-pages branch)



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

[GitHub] nifi-registry pull request #66: [NIFIREG-14] remove fds demo

[scottyaslan]

GitHub user scottyaslan opened a pull request:

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

[NIFIREG-14] remove fds demo



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

$ git pull https://github.com/scottyaslan/nifi-registry NIFIREG-14

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

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


commit d9b15ce9dc382bcf9906135025d040fe635b444c
Author: Scott Aslan 
Date:   2017-12-21T22:07:57Z

[NIFIREG-14] remove fds demo




---

[jira] [Resolved] (NIFIREG-66) Create LICENSE/NOTICE for assembly

[Joseph Witt (JIRA)]

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

Joseph Witt resolved NIFIREG-66.

Resolution: Fixed

+1 merged to master.

Validated and added some fixes to source licensing to cover a few JS files that 
were not listed.
Validated binary dependencies are documented/covered in the  L of the binary 
artifact assembly as well as the WARs.

Great job on this!

> Create LICENSE/NOTICE for assembly
> --
>
> Key: NIFIREG-66
> URL: https://issues.apache.org/jira/browse/NIFIREG-66
> Project: NiFi Registry
>  Issue Type: Improvement
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Blocker
> Fix For: 0.0.1
>
>
> Need to correctly populate the LICENSE and NOTICE in the assembly before we 
> can make a release.



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

[jira] [Commented] (NIFIREG-66) Create LICENSE/NOTICE for assembly

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Create LICENSE/NOTICE for assembly
> --
>
> Key: NIFIREG-66
> URL: https://issues.apache.org/jira/browse/NIFIREG-66
> Project: NiFi Registry
>  Issue Type: Improvement
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Blocker
> Fix For: 0.0.1
>
>
> Need to correctly populate the LICENSE and NOTICE in the assembly before we 
> can make a release.



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

[GitHub] nifi-registry pull request #62: NIFIREG-66 Initial LICENSE/NOTICE for assemb...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Created] (NIFIREG-76) Improve error messages from server for constraint violations

[Bryan Bende (JIRA)]

Bryan Bende created NIFIREG-76:
--

 Summary: Improve error messages from server for constraint 
violations
 Key: NIFIREG-76
 URL: https://issues.apache.org/jira/browse/NIFIREG-76
 Project: NiFi Registry
  Issue Type: Improvement
Reporter: Bryan Bende
Assignee: Bryan Bende
Priority: Minor
 Fix For: 0.0.1


Currently the java validation framework is producing a response with a json 
array of violations, but we should change this to the appropriate text-based 
response like our other exception mappers.



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

[jira] [Assigned] (NIFIREG-14) Remove the FDS demo from the registry app

[Scott Aslan (JIRA)]

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

Scott Aslan reassigned NIFIREG-14:
--

Assignee: Scott Aslan

> Remove the FDS demo from the registry app
> -
>
> Key: NIFIREG-14
> URL: https://issues.apache.org/jira/browse/NIFIREG-14
> Project: NiFi Registry
>  Issue Type: Sub-task
>Reporter: Scott Aslan
>Assignee: Scott Aslan
>Priority: Minor
>
> -Add ASLv2 LICENSE and NOTICE
> -Remove fds demo from registry app (move demo to gh-pages branch)



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

[jira] [Commented] (NIFI-4428) Implement PutDruid Processor and Controller

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4428:
--

Github user vakshorton commented on the issue:

https://github.com/apache/nifi/pull/2310
  
@pvillard31 You are likely seeing a lot of dropped events because the 
timestamps in the events are out of synch with the server clock. If your 
segment granularity is set to 10 minutes, late window set to 1 minute and the 
event timestamp is more than 11 minutes out of synch with the server time, that 
data is considered "late" (since the target index task will have closed). What 
kind of ingestion rates on what input volume? Are you seeing a lot of queuing? 
Can you check your middle manager configuration/resource allocation?


> Implement PutDruid Processor and Controller
> ---
>
> Key: NIFI-4428
> URL: https://issues.apache.org/jira/browse/NIFI-4428
> Project: Apache NiFi
>  Issue Type: New Feature
>Affects Versions: 1.3.0
>Reporter: Vadim Vaks
>Assignee: Matt Burgess
>
> Implement a PutDruid Processor and Controller using Tranquility API. This 
> will enable Nifi to index contents of flow files in Druid. The implementation 
> should also be able to handle late arriving data (event timestamp points to 
> Druid indexing task that has closed, segment granularity and grace window 
> period expired). Late arriving data is typically dropped. Nifi should allow 
> late arriving data to be diverted to FAILED or DROPPED relationship. That 
> would allow late arriving data to be stored on HDFS or S3 until a re-indexing 
> task can merge it into the correct segment in deep storage.



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

[GitHub] nifi issue #2310: NIFI-4428: Add PutDruidRecord processor and DruidTranquili...

[vakshorton]

Github user vakshorton commented on the issue:

https://github.com/apache/nifi/pull/2310
  
@pvillard31 You are likely seeing a lot of dropped events because the 
timestamps in the events are out of synch with the server clock. If your 
segment granularity is set to 10 minutes, late window set to 1 minute and the 
event timestamp is more than 11 minutes out of synch with the server time, that 
data is considered "late" (since the target index task will have closed). What 
kind of ingestion rates on what input volume? Are you seeing a lot of queuing? 
Can you check your middle manager configuration/resource allocation?


---

[jira] [Commented] (NIFIREG-66) Create LICENSE/NOTICE for assembly

[ASF GitHub Bot (JIRA)]

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

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

Github user joewitt commented on the issue:

https://github.com/apache/nifi-registry/pull/62
  
update

Source NOTICE
- Copied Apache NiFi code (bootstrap/runtime, client, process/model 
classes, security/authorization)
- nifi-registry-web-ui
 - karma.conf.js: 
 - karma-test-shim.js: systemjs
 - protractor.config.js: angular
https://github.com/angular/quickstart


 - fds-demo.js:
- scotty will delete this therefore...no issue.
 - systemjs-angular-loader.js: angular loader
 - systemjs.builder.config.js: angular builder
 - systemjs.spec.config.js: angular spec


> Create LICENSE/NOTICE for assembly
> --
>
> Key: NIFIREG-66
> URL: https://issues.apache.org/jira/browse/NIFIREG-66
> Project: NiFi Registry
>  Issue Type: Improvement
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Blocker
> Fix For: 0.0.1
>
>
> Need to correctly populate the LICENSE and NOTICE in the assembly before we 
> can make a release.



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

[GitHub] nifi-registry issue #62: NIFIREG-66 Initial LICENSE/NOTICE for assembly & WA...

[joewitt]

Github user joewitt commented on the issue:

https://github.com/apache/nifi-registry/pull/62
  
update

Source NOTICE
- Copied Apache NiFi code (bootstrap/runtime, client, process/model 
classes, security/authorization)
- nifi-registry-web-ui
 - karma.conf.js: 
 - karma-test-shim.js: systemjs
 - protractor.config.js: angular
https://github.com/angular/quickstart


 - fds-demo.js:
- scotty will delete this therefore...no issue.
 - systemjs-angular-loader.js: angular loader
 - systemjs.builder.config.js: angular builder
 - systemjs.spec.config.js: angular spec


---

[jira] [Commented] (NIFI-4444) Upgrade Jersey Versions

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-:
--

GitHub user mcgilman opened a pull request:

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

NIFI-: Ensuring the /nifi-api/controller redirection filter runs

NIFI-:
- Ensure the /nifi-api/controller redirection filter executes before 
matching.

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

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

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

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


commit 230420507a2403d62c15c623762e92d95194ec7a
Author: Matt Gilman 
Date:   2017-12-21T19:54:09Z

NIFI-:
- Ensure the /nifi-api/controller redirection filter executes before 
matching.




> Upgrade Jersey Versions
> ---
>
> Key: NIFI-
> URL: https://issues.apache.org/jira/browse/NIFI-
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.4.0
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.5.0
>
> Attachments: NIFI-.xml
>
>
> Need to upgrade to a newer version of Jersey. The primary motivation is to 
> upgrade the version used within NiFi itself. However, there are a number of 
> extensions that also leverage it. Of those extensions, some utilize the older 
> version defined in dependencyManagement while others override explicitly 
> within their own bundle dependencyManagement. For this JIRA I propose 
> removing the Jersey artifacts from the root pom and allow the version to be 
> specified on a bundle by bundle basis.



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

[jira] [Updated] (NIFI-4444) Upgrade Jersey Versions

[Matt Gilman (JIRA)]

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

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

> Upgrade Jersey Versions
> ---
>
> Key: NIFI-
> URL: https://issues.apache.org/jira/browse/NIFI-
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.4.0
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.5.0
>
> Attachments: NIFI-.xml
>
>
> Need to upgrade to a newer version of Jersey. The primary motivation is to 
> upgrade the version used within NiFi itself. However, there are a number of 
> extensions that also leverage it. Of those extensions, some utilize the older 
> version defined in dependencyManagement while others override explicitly 
> within their own bundle dependencyManagement. For this JIRA I propose 
> removing the Jersey artifacts from the root pom and allow the version to be 
> specified on a bundle by bundle basis.



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

[GitHub] nifi pull request #2358: NIFI-4444: Ensuring the /nifi-api/controller redire...

[mcgilman]

GitHub user mcgilman opened a pull request:

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

NIFI-: Ensuring the /nifi-api/controller redirection filter runs

NIFI-:
- Ensure the /nifi-api/controller redirection filter executes before 
matching.

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

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

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

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


commit 230420507a2403d62c15c623762e92d95194ec7a
Author: Matt Gilman 
Date:   2017-12-21T19:54:09Z

NIFI-:
- Ensure the /nifi-api/controller redirection filter executes before 
matching.




---

[jira] [Updated] (MINIFICPP-357) Upgrade YAML parsing to support version 3 of the config schema and work with later toolkits

[Andrew Christianson (JIRA)]

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

Andrew Christianson updated MINIFICPP-357:
--
Description: 
Currently minificpp makes use of what is effectively YAML, v1 and requires the 
usage of the 0.0.1 toolkit to perform transformations.  We should get these in 
sync across agent implementations and allow users to make use of one toolkit 
for performing transformations.

Scope involves mapping v3 config to what is currently supported. Not all 
features in reference config files (e.g. dynamic properties) are yet supported 
in MiNiFi. Support of those features is out of scope.

  was:Currently minificpp makes use of what is effectively YAML, v1 and 
requires the usage of the 0.0.1 toolkit to perform transformations.  We should 
get these in sync across agent implementations and allow users to make use of 
one toolkit for performing transformations.


> Upgrade YAML parsing to support version 3 of the config schema and work with 
> later toolkits
> ---
>
> Key: MINIFICPP-357
> URL: https://issues.apache.org/jira/browse/MINIFICPP-357
> Project: NiFi MiNiFi C++
>  Issue Type: Improvement
>Reporter: Aldrin Piri
>Assignee: Andrew Christianson
>
> Currently minificpp makes use of what is effectively YAML, v1 and requires 
> the usage of the 0.0.1 toolkit to perform transformations.  We should get 
> these in sync across agent implementations and allow users to make use of one 
> toolkit for performing transformations.
> Scope involves mapping v3 config to what is currently supported. Not all 
> features in reference config files (e.g. dynamic properties) are yet 
> supported in MiNiFi. Support of those features is out of scope.



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

[jira] [Assigned] (MINIFICPP-357) Upgrade YAML parsing to support version 3 of the config schema and work with later toolkits

[Andrew Christianson (JIRA)]

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

Andrew Christianson reassigned MINIFICPP-357:
-

Assignee: Andrew Christianson

> Upgrade YAML parsing to support version 3 of the config schema and work with 
> later toolkits
> ---
>
> Key: MINIFICPP-357
> URL: https://issues.apache.org/jira/browse/MINIFICPP-357
> Project: NiFi MiNiFi C++
>  Issue Type: Improvement
>Reporter: Aldrin Piri
>Assignee: Andrew Christianson
>
> Currently minificpp makes use of what is effectively YAML, v1 and requires 
> the usage of the 0.0.1 toolkit to perform transformations.  We should get 
> these in sync across agent implementations and allow users to make use of one 
> toolkit for performing transformations.



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

[jira] [Commented] (MINIFICPP-357) Upgrade YAML parsing to support version 3 of the config schema and work with later toolkits

[Andrew Christianson (JIRA)]

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

Andrew Christianson commented on MINIFICPP-357:
---

Example v3: 
https://github.com/apache/nifi-minifi/blob/master/minifi-toolkit/minifi-toolkit-configuration/src/test/resources/InvokeHttpMiNiFiTemplateTest.yml

> Upgrade YAML parsing to support version 3 of the config schema and work with 
> later toolkits
> ---
>
> Key: MINIFICPP-357
> URL: https://issues.apache.org/jira/browse/MINIFICPP-357
> Project: NiFi MiNiFi C++
>  Issue Type: Improvement
>Reporter: Aldrin Piri
>
> Currently minificpp makes use of what is effectively YAML, v1 and requires 
> the usage of the 0.0.1 toolkit to perform transformations.  We should get 
> these in sync across agent implementations and allow users to make use of one 
> toolkit for performing transformations.



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

[jira] [Commented] (MINIFICPP-357) Upgrade YAML parsing to support version 3 of the config schema and work with later toolkits

[Andrew Christianson (JIRA)]

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

Andrew Christianson commented on MINIFICPP-357:
---

Associated links:

* 
https://github.com/apache/nifi-minifi/blob/master/minifi-docs/src/main/markdown/System_Admin_Guide.md#config-file
* 
https://github.com/apache/nifi-minifi/tree/master/minifi-toolkit/minifi-toolkit-configuration
 is where everything lives
* 
https://github.com/apache/nifi-minifi/tree/master/minifi-toolkit/minifi-toolkit-configuration/src/test/resources
 has several test files template and back

> Upgrade YAML parsing to support version 3 of the config schema and work with 
> later toolkits
> ---
>
> Key: MINIFICPP-357
> URL: https://issues.apache.org/jira/browse/MINIFICPP-357
> Project: NiFi MiNiFi C++
>  Issue Type: Improvement
>Reporter: Aldrin Piri
>
> Currently minificpp makes use of what is effectively YAML, v1 and requires 
> the usage of the 0.0.1 toolkit to perform transformations.  We should get 
> these in sync across agent implementations and allow users to make use of one 
> toolkit for performing transformations.



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

[jira] [Resolved] (MINIFICPP-303) Upgrade civetweb and rocksdb

[Aldrin Piri (JIRA)]

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

Aldrin Piri resolved MINIFICPP-303.
---
   Resolution: Fixed
Fix Version/s: 0.4.0

> Upgrade civetweb and rocksdb
> 
>
> Key: MINIFICPP-303
> URL: https://issues.apache.org/jira/browse/MINIFICPP-303
> Project: NiFi MiNiFi C++
>  Issue Type: Improvement
>Reporter: Caleb Johnson
>Assignee: Caleb Johnson
> Fix For: 0.4.0
>
>
> These upgrades to the latest stable releases of civetweb 
> ([v1.10|https://github.com/civetweb/civetweb/releases/tag/v1.10]) and RocksDB 
> ([v5.8|https://github.com/facebook/rocksdb/releases/tag/v5.8]) bring numerous 
> improvements. They might solve any issues similar to those in MINIFICPP-262.
> For civet, the most notable is OpenSSL v1.1 support. It was partially 
> backported to the version in the minifi tree (1.9.1), but still had issues 
> matching some OpenSSL v1.1 interface changes. Civetweb release v1.10 has 
> complete and official support.
> RocksDB v5.8 comes with the following bugfixes:
> * Fix wrong latencies in rocksdb.db.get.micros, rocksdb.db.write.micros, and 
> rocksdb.sst.read.micros.
> * Fix incorrect dropping of deletions during intra-L0 compaction.
> * Fix transient reappearance of keys covered by range deletions when memtable 
> prefix bloom filter is enabled.
> * Fix potentially wrong file smallest key when range deletions separated by 
> snapshot are written together.



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

[jira] [Assigned] (MINIFICPP-303) Upgrade civetweb and rocksdb

[Aldrin Piri (JIRA)]

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

Aldrin Piri reassigned MINIFICPP-303:
-

Assignee: Caleb Johnson

> Upgrade civetweb and rocksdb
> 
>
> Key: MINIFICPP-303
> URL: https://issues.apache.org/jira/browse/MINIFICPP-303
> Project: NiFi MiNiFi C++
>  Issue Type: Improvement
>Reporter: Caleb Johnson
>Assignee: Caleb Johnson
> Fix For: 0.4.0
>
>
> These upgrades to the latest stable releases of civetweb 
> ([v1.10|https://github.com/civetweb/civetweb/releases/tag/v1.10]) and RocksDB 
> ([v5.8|https://github.com/facebook/rocksdb/releases/tag/v5.8]) bring numerous 
> improvements. They might solve any issues similar to those in MINIFICPP-262.
> For civet, the most notable is OpenSSL v1.1 support. It was partially 
> backported to the version in the minifi tree (1.9.1), but still had issues 
> matching some OpenSSL v1.1 interface changes. Civetweb release v1.10 has 
> complete and official support.
> RocksDB v5.8 comes with the following bugfixes:
> * Fix wrong latencies in rocksdb.db.get.micros, rocksdb.db.write.micros, and 
> rocksdb.sst.read.micros.
> * Fix incorrect dropping of deletions during intra-L0 compaction.
> * Fix transient reappearance of keys covered by range deletions when memtable 
> prefix bloom filter is enabled.
> * Fix potentially wrong file smallest key when range deletions separated by 
> snapshot are written together.



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

[jira] [Created] (MINIFICPP-359) Support anonymous connections in config.yml

[Andrew Christianson (JIRA)]

Andrew Christianson created MINIFICPP-359:
-

 Summary: Support anonymous connections in config.yml
 Key: MINIFICPP-359
 URL: https://issues.apache.org/jira/browse/MINIFICPP-359
 Project: NiFi MiNiFi C++
  Issue Type: Improvement
Reporter: Andrew Christianson
Priority: Minor


Since connections are rarely, if ever, referenced by name or ID in a typical 
config.yml, allow for anonymous (no ID and no name) connections. MiNiFi will 
generate IDs for anonymous connections. This will make writing config.yml a 
little simpler.



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

[jira] [Commented] (NIFI-4179) Enabling existing Processor to support more features (GetFTP/GetSFTP) and FetchFTP/FetchSFTO

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4179:
--

GitHub user apiri opened a pull request:

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

NIFI-4179 Incrementing Template encoding version to 1.2

NIFI-4179 Incrementing Template encoding version to 1.2 to reflect changes 
incorporated in NIFI-3155

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

$ git pull https://github.com/apiri/incubator-nifi NIFI-4179

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

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


commit 76f32c8b346e7c8d428626be4b12622b80186366
Author: Aldrin Piri 
Date:   2017-12-21T17:54:11Z

NIFI-4179 Incrementing Template encoding version to 1.2 to reflect changes 
incorporated in NIFI-3155




> Enabling existing Processor to support more features (GetFTP/GetSFTP) and 
> FetchFTP/FetchSFTO
> 
>
> Key: NIFI-4179
> URL: https://issues.apache.org/jira/browse/NIFI-4179
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 1.3.0
> Environment: Windows/Unix
>Reporter: Vijaya Kumar Reddy Maddela
>  Labels: features
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Hi All,
> We are looking to have dynamic behavior for FTP/SFTP processors.
> 1)GETFTP processor should be used only as starting point in a flow (Not 
> supported to use it in middle of the flow)
> 2)FetchFTP: This supports using in middle of the flow, but doesnot 
> support to pass Dynamic properties
> When we look into code we identified reasons for not supporting
> In
> GetFTP/GetSFTP:
> @InputRequirement(Requirement.INPUT_FORBIDDEN) instead of 
> @InputRequirement(Requirement.INPUT_REQUIRED)
> FetchFTP/FetchSFTO:
> Doesn’t contain @DynamicProperties() in the code
> Can you please some help someone how can we build the code and deploy by our 
> self. Appreciate a link or tutorial for building code after modification



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

[GitHub] nifi pull request #2357: NIFI-4179 Incrementing Template encoding version to...

[apiri]

GitHub user apiri opened a pull request:

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

NIFI-4179 Incrementing Template encoding version to 1.2

NIFI-4179 Incrementing Template encoding version to 1.2 to reflect changes 
incorporated in NIFI-3155

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

$ git pull https://github.com/apiri/incubator-nifi NIFI-4179

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

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


commit 76f32c8b346e7c8d428626be4b12622b80186366
Author: Aldrin Piri 
Date:   2017-12-21T17:54:11Z

NIFI-4179 Incrementing Template encoding version to 1.2 to reflect changes 
incorporated in NIFI-3155




---

[jira] [Updated] (MINIFICPP-358) Implement TFExtractTopLabels

[Andrew Christianson (JIRA)]

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

Andrew Christianson updated MINIFICPP-358:
--
Description: Add support for interpreting output tensors which represent 
labels with scores. A list of labels in index order is passed in with attribute 
tf.type == "labels". The top N labels are extracted into attributes 
tf.label. and tf.score.. The tf.label.0 attribute represents the 
highest-scoring label and can be used, for example, to route FlowFiles based on 
model inferences.  (was: Add support for interpreting output tensors which 
represent labels with scores. A list of labels in index order is passed in with 
attribute tf.type == "labels". The top N labels are extracted into attributes 
tf.label. and tf.score.. the tf.label.0 attribute represents the 
highest-scoring label and can be used, for example, to route FlowFiles based on 
model inferences.)

> Implement TFExtractTopLabels
> 
>
> Key: MINIFICPP-358
> URL: https://issues.apache.org/jira/browse/MINIFICPP-358
> Project: NiFi MiNiFi C++
>  Issue Type: Improvement
>Reporter: Andrew Christianson
>
> Add support for interpreting output tensors which represent labels with 
> scores. A list of labels in index order is passed in with attribute tf.type 
> == "labels". The top N labels are extracted into attributes tf.label. and 
> tf.score.. The tf.label.0 attribute represents the highest-scoring label 
> and can be used, for example, to route FlowFiles based on model inferences.



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

[jira] [Created] (MINIFICPP-358) Implement TFExtractTopLabels

[Andrew Christianson (JIRA)]

Andrew Christianson created MINIFICPP-358:
-

 Summary: Implement TFExtractTopLabels
 Key: MINIFICPP-358
 URL: https://issues.apache.org/jira/browse/MINIFICPP-358
 Project: NiFi MiNiFi C++
  Issue Type: Improvement
Reporter: Andrew Christianson


Add support for interpreting output tensors which represent labels with scores. 
A list of labels in index order is passed in with attribute tf.type == 
"labels". The top N labels are extracted into attributes tf.label. and 
tf.score.. the tf.label.0 attribute represents the highest-scoring label and 
can be used, for example, to route FlowFiles based on model inferences.



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

[jira] [Commented] (MINIFICPP-331) Implement string replacement functions in Expression Language

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MINIFICPP-331:
--

GitHub user achristianson opened a pull request:

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

MINIFICPP-331 Implemented string replacement functions

Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced
 in the commit message?

- [x] Does your PR title start with MINIFI- where  is the JIRA 
number you are trying to resolve? Pay particular attention to the hyphen "-" 
character.

- [x] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [x] Is your initial contribution a single, squashed commit?

### For code changes:
- [x] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [x] If applicable, have you updated the LICENSE file?
- [x] If applicable, have you updated the NOTICE file?

### For documentation related changes:
- [x] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


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

$ git pull https://github.com/achristianson/nifi-minifi-cpp MINIFICPP-331

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

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


commit 1cfa0181c7a1ad4f26fb06cc554e76b57c91039c
Author: Andy I. Christianson 
Date:   2017-12-21T17:46:36Z

MINIFICPP-331 Implemented string replacement functions




> Implement string replacement functions in Expression Language
> -
>
> Key: MINIFICPP-331
> URL: https://issues.apache.org/jira/browse/MINIFICPP-331
> Project: NiFi MiNiFi C++
>  Issue Type: Improvement
>Reporter: Andrew Christianson
>Assignee: Andrew Christianson
>
> Implement these in EL:
> replace
> replaceFirst
> replaceAll
> replaceNull
> replaceEmpty



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

[GitHub] nifi-minifi-cpp pull request #226: MINIFICPP-331 Implemented string replacem...

[achristianson]

GitHub user achristianson opened a pull request:

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

MINIFICPP-331 Implemented string replacement functions

Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced
 in the commit message?

- [x] Does your PR title start with MINIFI- where  is the JIRA 
number you are trying to resolve? Pay particular attention to the hyphen "-" 
character.

- [x] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [x] Is your initial contribution a single, squashed commit?

### For code changes:
- [x] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [x] If applicable, have you updated the LICENSE file?
- [x] If applicable, have you updated the NOTICE file?

### For documentation related changes:
- [x] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


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

$ git pull https://github.com/achristianson/nifi-minifi-cpp MINIFICPP-331

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

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


commit 1cfa0181c7a1ad4f26fb06cc554e76b57c91039c
Author: Andy I. Christianson 
Date:   2017-12-21T17:46:36Z

MINIFICPP-331 Implemented string replacement functions




---

[jira] [Updated] (NIFI-4719) Increment template encoding version for post 1.4 changes

[Aldrin Piri (JIRA)]

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

Aldrin Piri updated NIFI-4719:
--
Fix Version/s: 1.5.0

> Increment template encoding version for post 1.4 changes
> 
>
> Key: NIFI-4719
> URL: https://issues.apache.org/jira/browse/NIFI-4719
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Aldrin Piri
>Assignee: Aldrin Piri
> Fix For: 1.5.0
>
>
> Work to facilitate more robust connections on startup to RPG hosts.  The 
> associated encoding version was not bumped to reflect this change and should 
> be incremented to 1.2



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

[jira] [Created] (NIFI-4719) Increment template encoding version for post 1.4 changes

[Aldrin Piri (JIRA)]

Aldrin Piri created NIFI-4719:
-

 Summary: Increment template encoding version for post 1.4 changes
 Key: NIFI-4719
 URL: https://issues.apache.org/jira/browse/NIFI-4719
 Project: Apache NiFi
  Issue Type: Bug
  Components: Configuration
Reporter: Aldrin Piri
Assignee: Aldrin Piri


Work to facilitate more robust connections on startup to RPG hosts.  The 
associated encoding version was not bumped to reflect this change and should be 
incremented to 1.2



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

[jira] [Updated] (NIFIREG-75) Composite and CompositeConfigurable UserGroupProviders don't consider all providers when looking up users and groups

[Kevin Doran (JIRA)]

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

Kevin Doran updated NIFIREG-75:
---
Description: 
In FileUserGroupProvider, when a new group is created, all the users in the 
group are checked to ensure they are known to the FileUserGroupProvider prior 
to creating the group.

This check should be removed, and an integrity check should be placed in the 
entity managing all user group providers (eg, CompositeUserGroupProvider and 
CompositeConfigurableUserGroupProvider).

Also, when loading a user identity, all UserGroupProviders should be considered 
for finding groups the user to which the user belongs.

  was:
In FileUserGroupProvider, when a new group is created, all the users in the 
group are checked to ensure they are known to the FileUserGroupProvider prior 
to creating the group.

However, when a group is updated, a similar check does not exist, allowing one 
to add invalid users to a group. This gets the server in a bad state with 
unexpected behavior surrounding authorization actions.

Note that this logic was ported from NiFi, so NiFi should probably be updated 
with the same fix after verifying this is the intended behavior (having the 
check on update).


> Composite and CompositeConfigurable UserGroupProviders don't consider all 
> providers when looking up users and groups
> 
>
> Key: NIFIREG-75
> URL: https://issues.apache.org/jira/browse/NIFIREG-75
> Project: NiFi Registry
>  Issue Type: Bug
>Reporter: Kevin Doran
>Assignee: Kevin Doran
> Fix For: 0.0.1
>
>
> In FileUserGroupProvider, when a new group is created, all the users in the 
> group are checked to ensure they are known to the FileUserGroupProvider prior 
> to creating the group.
> This check should be removed, and an integrity check should be placed in the 
> entity managing all user group providers (eg, CompositeUserGroupProvider and 
> CompositeConfigurableUserGroupProvider).
> Also, when loading a user identity, all UserGroupProviders should be 
> considered for finding groups the user to which the user belongs.



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

[jira] [Updated] (NIFIREG-75) Composite and Composite UserGroupProviders don't consider all providers when looking up users and groups

[Kevin Doran (JIRA)]

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

Kevin Doran updated NIFIREG-75:
---
Summary: Composite and Composite UserGroupProviders don't consider all 
providers when looking up users and groups  (was: FileUserGroupProvider allows 
updating a group to contain unknown users)

> Composite and Composite UserGroupProviders don't consider all providers when 
> looking up users and groups
> 
>
> Key: NIFIREG-75
> URL: https://issues.apache.org/jira/browse/NIFIREG-75
> Project: NiFi Registry
>  Issue Type: Bug
>Reporter: Kevin Doran
>Assignee: Kevin Doran
> Fix For: 0.0.1
>
>
> In FileUserGroupProvider, when a new group is created, all the users in the 
> group are checked to ensure they are known to the FileUserGroupProvider prior 
> to creating the group.
> However, when a group is updated, a similar check does not exist, allowing 
> one to add invalid users to a group. This gets the server in a bad state with 
> unexpected behavior surrounding authorization actions.
> Note that this logic was ported from NiFi, so NiFi should probably be updated 
> with the same fix after verifying this is the intended behavior (having the 
> check on update).



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

[jira] [Updated] (NIFIREG-75) Composite and CompositeConfigurable UserGroupProviders don't consider all providers when looking up users and groups

[Kevin Doran (JIRA)]

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

Kevin Doran updated NIFIREG-75:
---
Summary: Composite and CompositeConfigurable UserGroupProviders don't 
consider all providers when looking up users and groups  (was: Composite and 
Composite UserGroupProviders don't consider all providers when looking up users 
and groups)

> Composite and CompositeConfigurable UserGroupProviders don't consider all 
> providers when looking up users and groups
> 
>
> Key: NIFIREG-75
> URL: https://issues.apache.org/jira/browse/NIFIREG-75
> Project: NiFi Registry
>  Issue Type: Bug
>Reporter: Kevin Doran
>Assignee: Kevin Doran
> Fix For: 0.0.1
>
>
> In FileUserGroupProvider, when a new group is created, all the users in the 
> group are checked to ensure they are known to the FileUserGroupProvider prior 
> to creating the group.
> However, when a group is updated, a similar check does not exist, allowing 
> one to add invalid users to a group. This gets the server in a bad state with 
> unexpected behavior surrounding authorization actions.
> Note that this logic was ported from NiFi, so NiFi should probably be updated 
> with the same fix after verifying this is the intended behavior (having the 
> check on update).



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

[jira] [Updated] (NIFI-4718) IdentifyMimeType: increase priority for FFv3

[Brandon DeVries (JIRA)]

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

Brandon DeVries updated NIFI-4718:
--
Description: 
IdentifyMimeType uses tika configured with a custom-mimetypes.xml\[1] to 
specify (among others) the flowfile-v* mime types.  However, these do not 
include priorities.  Therefore, a NiFi FlowFile V3 package with a payload 
containing, for example, html including the string:
{code}
https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/resources/org/apache/tika/mime/custom-mimetypes.xml#L26-L31
\[2] 
https://gitbox.apache.org/repos/asf?p=tika.git;a=blob;f=tika-core/src/main/resources/org/apache/tika/mime/tika-mimetypes.xml;hb=refs/heads/master

  was:
IdentifyMimeType uses tika configured with a custom-mimetypes.xml\[1] to 
specify (among others) the flowfile-v* mime types.  However, these do not 
include priorities.  Therefore, a NiFi FlowFile V3 package with a payload 
containing, for example, html including the string:
{code}
https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/resources/org/apache/tika/mime/custom-mimetypes.xml#L26-L31
\2] 
https://gitbox.apache.org/repos/asf?p=tika.git;a=blob;f=tika-core/src/main/resources/org/apache/tika/mime/tika-mimetypes.xml;hb=refs/heads/master


> IdentifyMimeType: increase priority for FFv3
> 
>
> Key: NIFI-4718
> URL: https://issues.apache.org/jira/browse/NIFI-4718
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Brandon DeVries
>Priority: Minor
>
> IdentifyMimeType uses tika configured with a custom-mimetypes.xml\[1] to 
> specify (among others) the flowfile-v* mime types.  However, these do not 
> include priorities.  Therefore, a NiFi FlowFile V3 package with a payload 
> containing, for example, html including the string:
> {code}
>  {code}
> will be identified as "application/xhtml+xml" \[2] which, while matching the 
> pattern, is not as correct as identifying it as application/flowfile-v3.  To 
> fix this, I believe we need to specify a higher priority for the FlowFile V3 
> "magic"...
> \[1] 
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/resources/org/apache/tika/mime/custom-mimetypes.xml#L26-L31
> \[2] 
> https://gitbox.apache.org/repos/asf?p=tika.git;a=blob;f=tika-core/src/main/resources/org/apache/tika/mime/tika-mimetypes.xml;hb=refs/heads/master



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

[jira] [Commented] (NIFI-4428) Implement PutDruid Processor and Controller

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4428:
--

Github user pvillard31 commented on the issue:

https://github.com/apache/nifi/pull/2310
  
OK... So I've been doing some tests and it's working as I'd expect. The 
only remark I have is in terms of performances: ingestion rate is very low (and 
creating a lot of "dropped") but it might be explained because I'm running 
everything locally (?).

For anyone interested to try this PR. I've been following the quick start 
[here](http://druid.io/docs/0.11.0/tutorials/quickstart.html). And I've been 
using this 
[workflow](https://gist.github.com/pvillard31/29956e9d7292551f9e8328bb62cbeb6c).
 (you'd need to update the ExecuteProcess processor to use the correct path 
pointing to the quickstart script generating data)

Once data is ingested into Druid, I'm issuing requests to get top 25 
servers from the metrics we are ingesting:

json
{
  "queryType" : "topN",
  "dataSource" : "metrics",
  "intervals" : ["2017-01-01/2017-12-31"],
  "granularity" : "all",
  "dimension" : "server",
  "metric" : "count",
  "threshold" : 25,
  "aggregations" : [
{
  "type" : "longSum",
  "name" : "count",
  "fieldName" : "count"
}
  ]
}


Result:

shell
$ curl -L -H'Content-Type: application/json' -XPOST --data-binary 
@quickstart/metrics.json http://localhost:8082/druid/v2/?pretty
[ {
  "timestamp" : "2017-12-21T16:28:00.000Z",
  "result" : [ {
"count" : 2518,
"server" : "www5.example.com"
  }, {
"count" : 2505,
"server" : "www1.example.com"
  }, {
"count" : 2494,
"server" : "www2.example.com"
  }, {
"count" : 2467,
"server" : "www4.example.com"
  }, {
"count" : 2466,
"server" : "www3.example.com"
  } ]
} ]




> Implement PutDruid Processor and Controller
> ---
>
> Key: NIFI-4428
> URL: https://issues.apache.org/jira/browse/NIFI-4428
> Project: Apache NiFi
>  Issue Type: New Feature
>Affects Versions: 1.3.0
>Reporter: Vadim Vaks
>Assignee: Matt Burgess
>
> Implement a PutDruid Processor and Controller using Tranquility API. This 
> will enable Nifi to index contents of flow files in Druid. The implementation 
> should also be able to handle late arriving data (event timestamp points to 
> Druid indexing task that has closed, segment granularity and grace window 
> period expired). Late arriving data is typically dropped. Nifi should allow 
> late arriving data to be diverted to FAILED or DROPPED relationship. That 
> would allow late arriving data to be stored on HDFS or S3 until a re-indexing 
> task can merge it into the correct segment in deep storage.



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

[GitHub] nifi issue #2310: NIFI-4428: Add PutDruidRecord processor and DruidTranquili...

[pvillard31]

Github user pvillard31 commented on the issue:

https://github.com/apache/nifi/pull/2310
  
OK... So I've been doing some tests and it's working as I'd expect. The 
only remark I have is in terms of performances: ingestion rate is very low (and 
creating a lot of "dropped") but it might be explained because I'm running 
everything locally (?).

For anyone interested to try this PR. I've been following the quick start 
[here](http://druid.io/docs/0.11.0/tutorials/quickstart.html). And I've been 
using this 
[workflow](https://gist.github.com/pvillard31/29956e9d7292551f9e8328bb62cbeb6c).
 (you'd need to update the ExecuteProcess processor to use the correct path 
pointing to the quickstart script generating data)

Once data is ingested into Druid, I'm issuing requests to get top 25 
servers from the metrics we are ingesting:

json
{
  "queryType" : "topN",
  "dataSource" : "metrics",
  "intervals" : ["2017-01-01/2017-12-31"],
  "granularity" : "all",
  "dimension" : "server",
  "metric" : "count",
  "threshold" : 25,
  "aggregations" : [
{
  "type" : "longSum",
  "name" : "count",
  "fieldName" : "count"
}
  ]
}


Result:

shell
$ curl -L -H'Content-Type: application/json' -XPOST --data-binary 
@quickstart/metrics.json http://localhost:8082/druid/v2/?pretty
[ {
  "timestamp" : "2017-12-21T16:28:00.000Z",
  "result" : [ {
"count" : 2518,
"server" : "www5.example.com"
  }, {
"count" : 2505,
"server" : "www1.example.com"
  }, {
"count" : 2494,
"server" : "www2.example.com"
  }, {
"count" : 2467,
"server" : "www4.example.com"
  }, {
"count" : 2466,
"server" : "www3.example.com"
  } ]
} ]




---

[jira] [Resolved] (NIFIREG-62) Minor updates to flow diff module

[Bryan Bende (JIRA)]

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

Bryan Bende resolved NIFIREG-62.

Resolution: Fixed

> Minor updates to flow diff module
> -
>
> Key: NIFIREG-62
> URL: https://issues.apache.org/jira/browse/NIFIREG-62
> Project: NiFi Registry
>  Issue Type: Bug
>Reporter: Mark Payne
>Assignee: Mark Payne
> Fix For: 0.0.1
>
>




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

[jira] [Resolved] (NIFIREG-74) Change the REST API login endpoint to use HTTP Basic Auth

[Bryan Bende (JIRA)]

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

Bryan Bende resolved NIFIREG-74.

Resolution: Fixed

> Change the REST API login endpoint to use HTTP Basic Auth
> -
>
> Key: NIFIREG-74
> URL: https://issues.apache.org/jira/browse/NIFIREG-74
> Project: NiFi Registry
>  Issue Type: Improvement
>Reporter: Kevin Doran
>Assignee: Kevin Doran
> Fix For: 0.0.1
>
>
> Currently, the REST API endpoint for logging in using a username & password 
> (with a configured identity provider) is a POST that accepts Content-Type 
> application/x-www-form-urlencoded, with form parameters in the body. 
> Specifically, requests should be formed as: 
> {noformat}
> POST /nifi-registry-api/access/token/login HTTP/1.1
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 32
> username=nobel=password
> {noformat}
> However, the Jersey resource we are using for the REST API in the server will 
> also respond to username and password passed in URL parameters, eg:
> {noformat}
> POST /nifi-registry-api/access/token/login?username=nobel=password 
> HTTP/1.1
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 0
> {noformat}
> This is incorrect, but it will work (actually, the current implementation of 
> the javascript client is logging in this way). As there does not appear to be 
> an easy way to prevent the server  from mapping url parameters to form 
> parameters, a client could mistakenly send url parameters to the server and 
> get a token back. The issue is that the URL is not generally considered a 
> protected element of the request, even when using a secure connection, so 
> libraries might log the full URL with parameters, thus leaking client 
> credentials. For example: 
> {noformat}
> DEBUG o.s.security.web.FilterChainProxy 
> /access/token/login?username=nobel=password has an empty filter list
> WARN o.glassfish.jersey.servlet.WebComponent A servlet request to the URI 
> https://localhost:8443/nifi-registry-api/access/token/login?username=nobel=password
>  contains form parameters in the request body but the request body has been 
> consumed by the servlet or a servlet filter accessing the request parameters. 
> Only resource methods using @FormParam will work as expected. Resource 
> methods consuming the request body by other means will not work as expected.
> {noformat}
> After looking into options, the best approach for now seems to be to migrate 
> the login endpoint and the JS client to use HTTP Basic Auth instead of form 
> encoded parameters. This will prevent a client from inadvertently sending 
> form params in the URL to the server in the HTTP POST.



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

[jira] [Commented] (NIFIREG-74) Change the REST API login endpoint to use HTTP Basic Auth

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Change the REST API login endpoint to use HTTP Basic Auth
> -
>
> Key: NIFIREG-74
> URL: https://issues.apache.org/jira/browse/NIFIREG-74
> Project: NiFi Registry
>  Issue Type: Improvement
>Reporter: Kevin Doran
>Assignee: Kevin Doran
> Fix For: 0.0.1
>
>
> Currently, the REST API endpoint for logging in using a username & password 
> (with a configured identity provider) is a POST that accepts Content-Type 
> application/x-www-form-urlencoded, with form parameters in the body. 
> Specifically, requests should be formed as: 
> {noformat}
> POST /nifi-registry-api/access/token/login HTTP/1.1
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 32
> username=nobel=password
> {noformat}
> However, the Jersey resource we are using for the REST API in the server will 
> also respond to username and password passed in URL parameters, eg:
> {noformat}
> POST /nifi-registry-api/access/token/login?username=nobel=password 
> HTTP/1.1
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 0
> {noformat}
> This is incorrect, but it will work (actually, the current implementation of 
> the javascript client is logging in this way). As there does not appear to be 
> an easy way to prevent the server  from mapping url parameters to form 
> parameters, a client could mistakenly send url parameters to the server and 
> get a token back. The issue is that the URL is not generally considered a 
> protected element of the request, even when using a secure connection, so 
> libraries might log the full URL with parameters, thus leaking client 
> credentials. For example: 
> {noformat}
> DEBUG o.s.security.web.FilterChainProxy 
> /access/token/login?username=nobel=password has an empty filter list
> WARN o.glassfish.jersey.servlet.WebComponent A servlet request to the URI 
> https://localhost:8443/nifi-registry-api/access/token/login?username=nobel=password
>  contains form parameters in the request body but the request body has been 
> consumed by the servlet or a servlet filter accessing the request parameters. 
> Only resource methods using @FormParam will work as expected. Resource 
> methods consuming the request body by other means will not work as expected.
> {noformat}
> After looking into options, the best approach for now seems to be to migrate 
> the login endpoint and the JS client to use HTTP Basic Auth instead of form 
> encoded parameters. This will prevent a client from inadvertently sending 
> form params in the URL to the server in the HTTP POST.



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

[jira] [Commented] (NIFIREG-74) Change the REST API login endpoint to use HTTP Basic Auth

[ASF GitHub Bot (JIRA)]

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

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

Github user bbende commented on the issue:

https://github.com/apache/nifi-registry/pull/63
  
+1 I was able to resolve the merge conflict locally and test this out, 
works nicely... was able to login/logout with multiple users against LDAP and 
verified that basic auth was being used, going to merge, thanks!


> Change the REST API login endpoint to use HTTP Basic Auth
> -
>
> Key: NIFIREG-74
> URL: https://issues.apache.org/jira/browse/NIFIREG-74
> Project: NiFi Registry
>  Issue Type: Improvement
>Reporter: Kevin Doran
>Assignee: Kevin Doran
> Fix For: 0.0.1
>
>
> Currently, the REST API endpoint for logging in using a username & password 
> (with a configured identity provider) is a POST that accepts Content-Type 
> application/x-www-form-urlencoded, with form parameters in the body. 
> Specifically, requests should be formed as: 
> {noformat}
> POST /nifi-registry-api/access/token/login HTTP/1.1
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 32
> username=nobel=password
> {noformat}
> However, the Jersey resource we are using for the REST API in the server will 
> also respond to username and password passed in URL parameters, eg:
> {noformat}
> POST /nifi-registry-api/access/token/login?username=nobel=password 
> HTTP/1.1
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 0
> {noformat}
> This is incorrect, but it will work (actually, the current implementation of 
> the javascript client is logging in this way). As there does not appear to be 
> an easy way to prevent the server  from mapping url parameters to form 
> parameters, a client could mistakenly send url parameters to the server and 
> get a token back. The issue is that the URL is not generally considered a 
> protected element of the request, even when using a secure connection, so 
> libraries might log the full URL with parameters, thus leaking client 
> credentials. For example: 
> {noformat}
> DEBUG o.s.security.web.FilterChainProxy 
> /access/token/login?username=nobel=password has an empty filter list
> WARN o.glassfish.jersey.servlet.WebComponent A servlet request to the URI 
> https://localhost:8443/nifi-registry-api/access/token/login?username=nobel=password
>  contains form parameters in the request body but the request body has been 
> consumed by the servlet or a servlet filter accessing the request parameters. 
> Only resource methods using @FormParam will work as expected. Resource 
> methods consuming the request body by other means will not work as expected.
> {noformat}
> After looking into options, the best approach for now seems to be to migrate 
> the login endpoint and the JS client to use HTTP Basic Auth instead of form 
> encoded parameters. This will prevent a client from inadvertently sending 
> form params in the URL to the server in the HTTP POST.



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

[GitHub] nifi-registry pull request #63: NIFIREG-74 Change login to use HTTP Basic Au...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] nifi-registry issue #63: NIFIREG-74 Change login to use HTTP Basic Auth

[bbende]

Github user bbende commented on the issue:

https://github.com/apache/nifi-registry/pull/63
  
+1 I was able to resolve the merge conflict locally and test this out, 
works nicely... was able to login/logout with multiple users against LDAP and 
verified that basic auth was being used, going to merge, thanks!


---

[jira] [Commented] (NIFIREG-75) FileUserGroupProvider allows updating a group to contain unknown users

[ASF GitHub Bot (JIRA)]

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

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

Github user kevdoran commented on the issue:

https://github.com/apache/nifi-registry/pull/64
  
Upon further discussion, may go with a different approach here. please hold 
off on merging this for now


> FileUserGroupProvider allows updating a group to contain unknown users
> --
>
> Key: NIFIREG-75
> URL: https://issues.apache.org/jira/browse/NIFIREG-75
> Project: NiFi Registry
>  Issue Type: Bug
>Reporter: Kevin Doran
>Assignee: Kevin Doran
> Fix For: 0.0.1
>
>
> In FileUserGroupProvider, when a new group is created, all the users in the 
> group are checked to ensure they are known to the FileUserGroupProvider prior 
> to creating the group.
> However, when a group is updated, a similar check does not exist, allowing 
> one to add invalid users to a group. This gets the server in a bad state with 
> unexpected behavior surrounding authorization actions.
> Note that this logic was ported from NiFi, so NiFi should probably be updated 
> with the same fix after verifying this is the intended behavior (having the 
> check on update).



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

[GitHub] nifi-registry issue #64: NIFIREG-75 Add check for user when updating group

[kevdoran]

Github user kevdoran commented on the issue:

https://github.com/apache/nifi-registry/pull/64
  
Upon further discussion, may go with a different approach here. please hold 
off on merging this for now


---

[jira] [Reopened] (NIFI-4444) Upgrade Jersey Versions

[Matt Gilman (JIRA)]

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

Matt Gilman reopened NIFI-:
---

Reopening issue to address a regression when invoking /nifi-api/controller 
which should map to /nifi-api/site-to-site.

> Upgrade Jersey Versions
> ---
>
> Key: NIFI-
> URL: https://issues.apache.org/jira/browse/NIFI-
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.4.0
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.5.0
>
> Attachments: NIFI-.xml
>
>
> Need to upgrade to a newer version of Jersey. The primary motivation is to 
> upgrade the version used within NiFi itself. However, there are a number of 
> extensions that also leverage it. Of those extensions, some utilize the older 
> version defined in dependencyManagement while others override explicitly 
> within their own bundle dependencyManagement. For this JIRA I propose 
> removing the Jersey artifacts from the root pom and allow the version to be 
> specified on a bundle by bundle basis.



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

[jira] [Commented] (NIFI-4701) Support encrypted properties in authorizers.xml

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4701:
--

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

https://github.com/apache/nifi/pull/2350#discussion_r158322844
  
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -1455,25 +1455,27 @@ The default encryption algorithm utilized is 
AES/GCM 128/256-bit. 128-bit is use
 
 You can use the following command line options with the `encrypt-config` 
tool:
 
--- End diff --

The ordering is changed here (to match to ordering of the usage output when 
running the tool), so it looks like a larger change. There are only two new 
options:

* `-a`,`--authorizers `  The authorizers.xml file containing 
unprotected config values (will be overwritten)
* `-u`,`--outputAuthorizers ` The destination authorizers.xml file 
containing protected config values (will not modify input authorizers.xml)


> Support encrypted properties in authorizers.xml
> ---
>
> Key: NIFI-4701
> URL: https://issues.apache.org/jira/browse/NIFI-4701
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Kevin Doran
>Assignee: Kevin Doran
> Fix For: 1.5.0
>
>
> Since the addition of LdapUserGroupProvider (see NIFI-4059) in v1.4.0, 
> authorizers.xml can now contain properties for LDAP Server credentials. 
> This ticket is to enable properties in authorizers.xml to be encrypted, so 
> that the LDAP Server Manager credentials can be protected similar to 
> LdapProvider which is configured via login-identity-providers.xml.
> The main changes are in nifi-authorizers are:
> * authorizers.xsd to add an encryption attribute to Property
> * to PropertyAuthorizerFactoryBean to check for that attribute and decrypt 
> the property value if necessary when creating the the configuration context
> Additionally, support for creating an encrypted authorizers.xml, protected by 
> the NiFi master key, should be added to the Encrypt Tool in NiFi Toolkit.



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

[GitHub] nifi pull request #2350: NIFI-4701 Support encrypted authorizers.xml

[kevdoran]

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

https://github.com/apache/nifi/pull/2350#discussion_r158322844
  
--- Diff: nifi-docs/src/main/asciidoc/administration-guide.adoc ---
@@ -1455,25 +1455,27 @@ The default encryption algorithm utilized is 
AES/GCM 128/256-bit. 128-bit is use
 
 You can use the following command line options with the `encrypt-config` 
tool:
 
--- End diff --

The ordering is changed here (to match to ordering of the usage output when 
running the tool), so it looks like a larger change. There are only two new 
options:

* `-a`,`--authorizers `  The authorizers.xml file containing 
unprotected config values (will be overwritten)
* `-u`,`--outputAuthorizers ` The destination authorizers.xml file 
containing protected config values (will not modify input authorizers.xml)


---

[jira] [Commented] (NIFIREG-66) Create LICENSE/NOTICE for assembly

[ASF GitHub Bot (JIRA)]

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

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

Github user joewitt commented on the issue:

https://github.com/apache/nifi-registry/pull/62
  
there is definitely code in here which we need to cite our our source 
LICENSE.  jquery-min would be another one but we have code that clearly looks 
copied over in some js.


> Create LICENSE/NOTICE for assembly
> --
>
> Key: NIFIREG-66
> URL: https://issues.apache.org/jira/browse/NIFIREG-66
> Project: NiFi Registry
>  Issue Type: Improvement
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Blocker
> Fix For: 0.0.1
>
>
> Need to correctly populate the LICENSE and NOTICE in the assembly before we 
> can make a release.



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

[GitHub] nifi-registry issue #62: NIFIREG-66 Initial LICENSE/NOTICE for assembly & WA...

[joewitt]

Github user joewitt commented on the issue:

https://github.com/apache/nifi-registry/pull/62
  
there is definitely code in here which we need to cite our our source 
LICENSE.  jquery-min would be another one but we have code that clearly looks 
copied over in some js.


---

[jira] [Updated] (MINIFICPP-356) Switch to /site-to-site/ to capture Site to Site information

[Joseph Witt (JIRA)]

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

Joseph Witt updated MINIFICPP-356:
--
Fix Version/s: 0.4.0

> Switch to /site-to-site/ to capture Site to Site information
> 
>
> Key: MINIFICPP-356
> URL: https://issues.apache.org/jira/browse/MINIFICPP-356
> Project: NiFi MiNiFi C++
>  Issue Type: Bug
>Reporter: marco polo
>Assignee: marco polo
> Fix For: 0.4.0
>
>
> Switch to /site-to-site/ to capture Site to Site information. Currently we 
> use /controller but that is not a documented endpoint in the rest API 
> documentation, as such we should move to a guaranteed endpoint. 



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

[jira] [Commented] (MINIFICPP-355) Starting minifi on arm fails quietly

[Joseph Witt (JIRA)]

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

Joseph Witt commented on MINIFICPP-355:
---

confirmed that if i change to INFO level logging instead of debug it works

> Starting minifi on arm fails quietly
> 
>
> Key: MINIFICPP-355
> URL: https://issues.apache.org/jira/browse/MINIFICPP-355
> Project: NiFi MiNiFi C++
>  Issue Type: Bug
>Affects Versions: 0.3.0
> Environment: raspberry pi zero w - arm
>Reporter: Joseph Witt
> Attachments: config.yml, minifi-app.log
>
>
> During startup the process quietly dies.  Aldrin showed me the cool process 
> to gather more data
> gdb bin/minifi
> -> run
> -> backtrace
> which yields 
> {quote}
> [Thread 0xb0eff160 (LWP 24133) exited]
> [Thread 0xb2eff160 (LWP 24138) exited]
> Thread 1 "minifi" received signal SIGSEGV, Segmentation fault.
> strlen () at ../sysdeps/arm/armv6/strlen.S:26
> 26../sysdeps/arm/armv6/strlen.S: No such file or directory.
> (gdb) backtrace
> #0  strlen () at ../sysdeps/arm/armv6/strlen.S:26
> #1  0xb64f0690 in _IO_vfprintf_internal (s=s@entry=0xbeffc3c0, 
> format=format@entry=0x609884 "Setting %d as the max queue size for %s", 
> ap=..., ap@entry=...)
> at vfprintf.c:1637
> #2  0xb6513d2c in _IO_vsnprintf (string=0xbeffc4f0 "Setting 0 as the max 
> queue size for p => [success]", maxlen=,
> format=0x609884 "Setting %d as the max queue size for %s", 
> format@entry=0xbeffcac8 "\330\033\207", args=..., args@entry=...) at 
> vsnprintf.c:114
> #3  0xb64f5b18 in __snprintf (s=, maxlen=, 
> format=0x609884 "Setting %d as the max queue size for %s") at snprintf.c:33
> #4  0x00284a4c in std::__cxx11::basic_string std::allocator > 
> org::apache::nifi::minifi::core::logging::format_string const*>(char const*, long long&&, char const*&&) [clone .isra.369] ()
> #5  0x00285dec in void 
> org::apache::nifi::minifi::core::logging::Logger::log std::__cxx11::basic_string > >(spdlog::level::level_enum, char const*, long long const&, 
> std::__cxx11::basic_string > const&) ()
> #6  0x0027efb4 in 
> org::apache::nifi::minifi::core::YamlConfiguration::parseConnectionYaml(YAML::Node*,
>  org::apache::nifi::minifi::core::ProcessGroup*) ()
> #7  0x0025ef3c in 
> org::apache::nifi::minifi::core::YamlConfiguration::getYamlRoot(YAML::Node*) 
> ()
> #8  0x0025f230 in 
> org::apache::nifi::minifi::core::YamlConfiguration::getRoot(std::__cxx11::basic_string  std::char_traits, std::allocator > const&) ()
> #9  0x002965b8 in org::apache::nifi::minifi::FlowController::load() ()
> #10 0x00161998 in main ()
> {quote}



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

[jira] [Created] (MINIFICPP-357) Upgrade YAML parsing to support version 3 of the config schema and work with later toolkits

[Aldrin Piri (JIRA)]

Aldrin Piri created MINIFICPP-357:
-

 Summary: Upgrade YAML parsing to support version 3 of the config 
schema and work with later toolkits
 Key: MINIFICPP-357
 URL: https://issues.apache.org/jira/browse/MINIFICPP-357
 Project: NiFi MiNiFi C++
  Issue Type: Improvement
Reporter: Aldrin Piri


Currently minificpp makes use of what is effectively YAML, v1 and requires the 
usage of the 0.0.1 toolkit to perform transformations.  We should get these in 
sync across agent implementations and allow users to make use of one toolkit 
for performing transformations.



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

[jira] [Commented] (NIFI-3660) ClassCastException from ConvertAvroToORC when the schema contains a map with an array value

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-3660:
--

GitHub user mgaido91 opened a pull request:

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

NIFI-3660: Support schema containing a map with an array value in 
ConvertAvroToORC

Thank you for submitting a contribution to Apache NiFi.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced 
 in the commit message?

- [x] Does your PR title start with NIFI- where  is the JIRA number 
you are trying to resolve? Pay particular attention to the hyphen "-" character.

- [x] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [x] Is your initial contribution a single, squashed commit?

### For code changes:
- [x] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [x] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? NA 
- [ ] If applicable, have you updated the LICENSE file, including the main 
LICENSE file under nifi-assembly? NA
- [ ] If applicable, have you updated the NOTICE file, including the main 
NOTICE file found under nifi-assembly? NA
- [ ] If adding new Properties, have you added .displayName in addition to 
.name (programmatic access) for each of the new properties? NA

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered? NA

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


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

$ git pull https://github.com/mgaido91/nifi NIFI-3660

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

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


commit 0a881a2f65f828172a5c2e9b33b400a78bc3816b
Author: Marco Gaido 
Date:   2017-12-21T15:28:48Z

NIFI-3660: Support schema containing a map with an array value in 
ConvertAvroToORC




> ClassCastException from ConvertAvroToORC when the schema contains a map with 
> an array value
> ---
>
> Key: NIFI-3660
> URL: https://issues.apache.org/jira/browse/NIFI-3660
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.1.1
>Reporter: Steve Champagne
> Attachments: PrimitiveToListTypeException.xml
>
>
> I am getting the following exception with the attached template.
> {panel}
> java.lang.ClassCastException: 
> org.apache.hadoop.hive.serde2.typeinfo.PrimitiveTypeInfo cannot be cast to 
> org.apache.hadoop.hive.serde2.typeinfo.ListTypeInfo
> at 
> org.apache.hadoop.hive.ql.io.orc.NiFiOrcUtils.convertToORCObject(NiFiOrcUtils.java:143)
>  ~[na:na]
> at 
> org.apache.hadoop.hive.ql.io.orc.NiFiOrcUtils.lambda$convertToORCObject$8(NiFiOrcUtils.java:157)
>  ~[na:na]
> at java.util.HashMap.forEach(HashMap.java:1288) ~[na:1.8.0_111]
> at 
> org.apache.hadoop.hive.ql.io.orc.NiFiOrcUtils.convertToORCObject(NiFiOrcUtils.java:155)
>  ~[na:na]
> at 
> org.apache.nifi.processors.hive.ConvertAvroToORC.lambda$onTrigger$0(ConvertAvroToORC.java:243)
>  ~[na:na]
> at 
> org.apache.nifi.controller.repository.StandardProcessSession.write(StandardProcessSession.java:2578)
>  ~[nifi-framework-core-1.1.0.2.1.1.0-2.jar:1.1.0.2.1.1.0-2]
> at 
> org.apache.nifi.processors.hive.ConvertAvroToORC.onTrigger(ConvertAvroToORC.java:207)
>  ~[na:na]
> at 
> org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
>  ~[nifi-api-1.1.0.2.1.1.0-2.jar:1.1.0.2.1.1.0-2]
> at 
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1099)
>  ~[nifi-framework-core-1.1.0.2.1.1.0-2.jar:1.1.0.2.1.1.0-2]
> at 
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136)
>  [nifi-framework-core-1.1.0.2.1.1.0-2.jar:1.1.0.2.1.1.0-2]
> at 
> 

[GitHub] nifi pull request #2356: NIFI-3660: Support schema containing a map with an ...

[mgaido91]

GitHub user mgaido91 opened a pull request:

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

NIFI-3660: Support schema containing a map with an array value in 
ConvertAvroToORC

Thank you for submitting a contribution to Apache NiFi.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced 
 in the commit message?

- [x] Does your PR title start with NIFI- where  is the JIRA number 
you are trying to resolve? Pay particular attention to the hyphen "-" character.

- [x] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [x] Is your initial contribution a single, squashed commit?

### For code changes:
- [x] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [x] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? NA 
- [ ] If applicable, have you updated the LICENSE file, including the main 
LICENSE file under nifi-assembly? NA
- [ ] If applicable, have you updated the NOTICE file, including the main 
NOTICE file found under nifi-assembly? NA
- [ ] If adding new Properties, have you added .displayName in addition to 
.name (programmatic access) for each of the new properties? NA

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered? NA

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


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

$ git pull https://github.com/mgaido91/nifi NIFI-3660

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

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


commit 0a881a2f65f828172a5c2e9b33b400a78bc3816b
Author: Marco Gaido 
Date:   2017-12-21T15:28:48Z

NIFI-3660: Support schema containing a map with an array value in 
ConvertAvroToORC




---

[jira] [Commented] (NIFIREG-30) Integrate security/user/group endpoints

[ASF GitHub Bot (JIRA)]

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

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

GitHub user scottyaslan opened a pull request:

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

[NIFIREG-30] update delete icons



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

$ git pull https://github.com/scottyaslan/nifi-registry NIFIREG-30

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

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


commit 0e3596e7c082221b88e1b3d3e3de9ecbb43618c6
Author: Scott Aslan 
Date:   2017-12-21T15:53:09Z

[NIFIREG-30] update delete icons




> Integrate security/user/group endpoints
> ---
>
> Key: NIFIREG-30
> URL: https://issues.apache.org/jira/browse/NIFIREG-30
> Project: NiFi Registry
>  Issue Type: Improvement
>Reporter: Scott Aslan
>Assignee: Scott Aslan
> Fix For: 0.0.1
>
>




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

[GitHub] nifi-registry pull request #65: [NIFIREG-30] update delete icons

[scottyaslan]

GitHub user scottyaslan opened a pull request:

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

[NIFIREG-30] update delete icons



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

$ git pull https://github.com/scottyaslan/nifi-registry NIFIREG-30

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

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


commit 0e3596e7c082221b88e1b3d3e3de9ecbb43618c6
Author: Scott Aslan 
Date:   2017-12-21T15:53:09Z

[NIFIREG-30] update delete icons




---

[jira] [Commented] (NIFIREG-30) Integrate security/user/group endpoints

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Integrate security/user/group endpoints
> ---
>
> Key: NIFIREG-30
> URL: https://issues.apache.org/jira/browse/NIFIREG-30
> Project: NiFi Registry
>  Issue Type: Improvement
>Reporter: Scott Aslan
>Assignee: Scott Aslan
> Fix For: 0.0.1
>
>




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

[GitHub] nifi-registry pull request #61: [NIFIREG-30] add bucket side nav

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Commented] (NIFIREG-30) Integrate security/user/group endpoints

[ASF GitHub Bot (JIRA)]

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

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

Github user bbende commented on the issue:

https://github.com/apache/nifi-registry/pull/61
  
This looks good, going to merge to master, thanks!


> Integrate security/user/group endpoints
> ---
>
> Key: NIFIREG-30
> URL: https://issues.apache.org/jira/browse/NIFIREG-30
> Project: NiFi Registry
>  Issue Type: Improvement
>Reporter: Scott Aslan
>Assignee: Scott Aslan
> Fix For: 0.0.1
>
>




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

[GitHub] nifi-registry issue #61: [NIFIREG-30] add bucket side nav

[bbende]

Github user bbende commented on the issue:

https://github.com/apache/nifi-registry/pull/61
  
This looks good, going to merge to master, thanks!


---

[jira] [Created] (NIFI-4718) IdentifyMimeType: increase priority for FFv3

[Brandon DeVries (JIRA)]

Brandon DeVries created NIFI-4718:
-

 Summary: IdentifyMimeType: increase priority for FFv3
 Key: NIFI-4718
 URL: https://issues.apache.org/jira/browse/NIFI-4718
 Project: Apache NiFi
  Issue Type: Bug
  Components: Extensions
Reporter: Brandon DeVries
Priority: Minor


IdentifyMimeType uses tika configured with a custom-mimetypes.xml\[1] to 
specify (among others) the flowfile-v* mime types.  However, these do not 
include priorities.  Therefore, a NiFi FlowFile V3 package with a payload 
containing, for example, html including the string:
{code}
https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/resources/org/apache/tika/mime/custom-mimetypes.xml#L26-L31
\2] 
https://gitbox.apache.org/repos/asf?p=tika.git;a=blob;f=tika-core/src/main/resources/org/apache/tika/mime/tika-mimetypes.xml;hb=refs/heads/master



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

[jira] [Commented] (NIFI-4716) Provenance query unhandled exception when Node disconnected

[Joseph Witt (JIRA)]

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

Joseph Witt commented on NIFI-4716:
---

actually in looking at that code it might just be that the clusterNodeId is 
null and it is not a replicated request so that might need different logic for 
the case of a disconnected cluster node doing that operation.  

> Provenance query unhandled exception when Node disconnected
> ---
>
> Key: NIFI-4716
> URL: https://issues.apache.org/jira/browse/NIFI-4716
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.4.0
>Reporter: Mark Bean
>
> Scenario: 2-node Cluster with one Node disconnected. Using the UI of the 
> surviving Node, when attempting a Data Provenance query, a popup error dialog 
> indicates "Cluster is unable to service request to change flow: Node 
>  is currently disconnected.". This occurs even 
> before the Provenance Events list is generated.
> However, using the UI of the disconnected Node the same Data Provenance query 
> is attempted. Now, a list of Provenance events is displayed. Then, when 
> choosing 'View Details', an uncaught exception occurs: "An unexpected error 
> has occurred. Please check the logs for additional details."
> The nifi-user.log indicates:
> o.a.nifi.web.api.config.ThrowableMapper An unexpected error has occurred: 
> java.lang.NullPointerException. Returning Internal Server Error response
> java.lang.NullPointerException: null
> at 
> org.apache.nifi.web.api.ProvenanceEventResource.getProvenanceEvent(ProvenanceEventResource.java:297)
> ...
> First, the error reported by the connected Node is misleading. An attempt to 
> change the flow has not been made.
> Second, recommend the disconnected Node behave as the connected Node and 
> immediate return an error on an attempt to query provenance. (However, the 
> error should be more descriptive of the problem as noted above.)



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

[jira] [Commented] (NIFI-4716) Provenance query unhandled exception when Node disconnected

[Joseph Witt (JIRA)]

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

Joseph Witt commented on NIFI-4716:
---

[~markbean]  At this time issuing provenance queries is considered/handled as a 
mutable change.  It can/should be updated to not be as I agree with your 
intuition that it should have not been.  Just sharing the current state of 
affairs there.  The reason has to do with the fact that the query is 
sent/registered/stored and then the client can check for results/status/etc..

Once the node is disconnected you will be able to directly request the prov 
from it since it no longer has that issue.  However, hitting that NPE is 
indicative of an underlying problem in the data.  Some attribute/property of a 
prov event is null and should not have been.  Can you share more details of the 
stack trace?  

The line you show in your current stack trace is
event.setClusterNodeAddress(nodeId.getApiAddress() + ":" + 
nodeId.getApiPort());


Is either your node API address or port empty in your nifi.properties by any 
chance?

Thanks
Joe

> Provenance query unhandled exception when Node disconnected
> ---
>
> Key: NIFI-4716
> URL: https://issues.apache.org/jira/browse/NIFI-4716
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.4.0
>Reporter: Mark Bean
>
> Scenario: 2-node Cluster with one Node disconnected. Using the UI of the 
> surviving Node, when attempting a Data Provenance query, a popup error dialog 
> indicates "Cluster is unable to service request to change flow: Node 
>  is currently disconnected.". This occurs even 
> before the Provenance Events list is generated.
> However, using the UI of the disconnected Node the same Data Provenance query 
> is attempted. Now, a list of Provenance events is displayed. Then, when 
> choosing 'View Details', an uncaught exception occurs: "An unexpected error 
> has occurred. Please check the logs for additional details."
> The nifi-user.log indicates:
> o.a.nifi.web.api.config.ThrowableMapper An unexpected error has occurred: 
> java.lang.NullPointerException. Returning Internal Server Error response
> java.lang.NullPointerException: null
> at 
> org.apache.nifi.web.api.ProvenanceEventResource.getProvenanceEvent(ProvenanceEventResource.java:297)
> ...
> First, the error reported by the connected Node is misleading. An attempt to 
> change the flow has not been made.
> Second, recommend the disconnected Node behave as the connected Node and 
> immediate return an error on an attempt to query provenance. (However, the 
> error should be more descriptive of the problem as noted above.)



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

[jira] [Assigned] (MINIFICPP-356) Switch to /site-to-site/ to capture Site to Site information

[marco polo (JIRA)]

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

marco polo reassigned MINIFICPP-356:


Assignee: marco polo

> Switch to /site-to-site/ to capture Site to Site information
> 
>
> Key: MINIFICPP-356
> URL: https://issues.apache.org/jira/browse/MINIFICPP-356
> Project: NiFi MiNiFi C++
>  Issue Type: Bug
>Reporter: marco polo
>Assignee: marco polo
>
> Switch to /site-to-site/ to capture Site to Site information. Currently we 
> use /controller but that is not a documented endpoint in the rest API 
> documentation, as such we should move to a guaranteed endpoint. 



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

[jira] [Resolved] (MINIFICPP-356) Switch to /site-to-site/ to capture Site to Site information

[marco polo (JIRA)]

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

marco polo resolved MINIFICPP-356.
--
Resolution: Fixed

> Switch to /site-to-site/ to capture Site to Site information
> 
>
> Key: MINIFICPP-356
> URL: https://issues.apache.org/jira/browse/MINIFICPP-356
> Project: NiFi MiNiFi C++
>  Issue Type: Bug
>Reporter: marco polo
>Assignee: marco polo
>
> Switch to /site-to-site/ to capture Site to Site information. Currently we 
> use /controller but that is not a documented endpoint in the rest API 
> documentation, as such we should move to a guaranteed endpoint. 



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

[jira] [Commented] (MINIFICPP-356) Switch to /site-to-site/ to capture Site to Site information

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MINIFICPP-356:
--

Github user asfgit closed the pull request at:

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


> Switch to /site-to-site/ to capture Site to Site information
> 
>
> Key: MINIFICPP-356
> URL: https://issues.apache.org/jira/browse/MINIFICPP-356
> Project: NiFi MiNiFi C++
>  Issue Type: Bug
>Reporter: marco polo
>
> Switch to /site-to-site/ to capture Site to Site information. Currently we 
> use /controller but that is not a documented endpoint in the rest API 
> documentation, as such we should move to a guaranteed endpoint. 



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

[GitHub] nifi-minifi-cpp pull request #225: MINIFICPP-356: Switch site to site API UR...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Created] (NIFI-4717) Minor bugs and performance improvements to record-oriented processors

[Mark Payne (JIRA)]

Mark Payne created NIFI-4717:


 Summary: Minor bugs and performance improvements to 
record-oriented processors
 Key: NIFI-4717
 URL: https://issues.apache.org/jira/browse/NIFI-4717
 Project: Apache NiFi
  Issue Type: Bug
Reporter: Mark Payne
Assignee: Mark Payne


While testing some corner cases, I have run into a few minor issues with some 
of the record oriented processors/libraries:

ConvertRecord performs very poorly if the writer is the JSON RestSetWriter and 
configured to write the schema using the avro.schema attribute.

If QueryRecord fails to parse data properly with the configured reader, it may 
roll back the session instead of routing to failure, leading the FlowFile being 
stuck on the queue. This includes an error message indicating that the FlowFile 
has an active callback or input stream that hasn't been closed.

QueryRecord fails if referencing a field that is of UNION type.



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

[jira] [Commented] (MINIFICPP-356) Switch to /site-to-site/ to capture Site to Site information

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MINIFICPP-356:
--

Github user joewitt commented on the issue:

https://github.com/apache/nifi-minifi-cpp/pull/225
  
reviewing now 


> Switch to /site-to-site/ to capture Site to Site information
> 
>
> Key: MINIFICPP-356
> URL: https://issues.apache.org/jira/browse/MINIFICPP-356
> Project: NiFi MiNiFi C++
>  Issue Type: Bug
>Reporter: marco polo
>
> Switch to /site-to-site/ to capture Site to Site information. Currently we 
> use /controller but that is not a documented endpoint in the rest API 
> documentation, as such we should move to a guaranteed endpoint. 



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

[GitHub] nifi-minifi-cpp issue #225: MINIFICPP-356: Switch site to site API URL from ...

[joewitt]

Github user joewitt commented on the issue:

https://github.com/apache/nifi-minifi-cpp/pull/225
  
reviewing now 


---

[jira] [Commented] (MINIFICPP-356) Switch to /site-to-site/ to capture Site to Site information

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on MINIFICPP-356:
--

GitHub user phrocker opened a pull request:

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

MINIFICPP-356: Switch site to site API URL from the 0.x endpoint to s…

…ite-to-site

Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced
 in the commit message?

- [ ] Does your PR title start with MINIFI- where  is the JIRA 
number you are trying to resolve? Pay particular attention to the hyphen "-" 
character.

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [ ] Is your initial contribution a single, squashed commit?

### For code changes:
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] If applicable, have you updated the LICENSE file?
- [ ] If applicable, have you updated the NOTICE file?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


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

$ git pull https://github.com/phrocker/nifi-minifi-cpp MINIFICPP-356

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

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


commit 96809984cb190825757525eefbc68002ac42688e
Author: Marc Parisi 
Date:   2017-12-21T14:37:11Z

MINIFICPP-356: Switch site to site API URL from the 0.x endpoint to 
site-to-site




> Switch to /site-to-site/ to capture Site to Site information
> 
>
> Key: MINIFICPP-356
> URL: https://issues.apache.org/jira/browse/MINIFICPP-356
> Project: NiFi MiNiFi C++
>  Issue Type: Bug
>Reporter: marco polo
>
> Switch to /site-to-site/ to capture Site to Site information. Currently we 
> use /controller but that is not a documented endpoint in the rest API 
> documentation, as such we should move to a guaranteed endpoint. 



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

[GitHub] nifi-minifi-cpp pull request #225: MINIFICPP-356: Switch site to site API UR...

[phrocker]

GitHub user phrocker opened a pull request:

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

MINIFICPP-356: Switch site to site API URL from the 0.x endpoint to s…

…ite-to-site

Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced
 in the commit message?

- [ ] Does your PR title start with MINIFI- where  is the JIRA 
number you are trying to resolve? Pay particular attention to the hyphen "-" 
character.

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [ ] Is your initial contribution a single, squashed commit?

### For code changes:
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] If applicable, have you updated the LICENSE file?
- [ ] If applicable, have you updated the NOTICE file?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


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

$ git pull https://github.com/phrocker/nifi-minifi-cpp MINIFICPP-356

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

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


commit 96809984cb190825757525eefbc68002ac42688e
Author: Marc Parisi 
Date:   2017-12-21T14:37:11Z

MINIFICPP-356: Switch site to site API URL from the 0.x endpoint to 
site-to-site




---

[jira] [Updated] (MINIFICPP-356) Switch to /site-to-site/ to capture Site to Site information

[marco polo (JIRA)]

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

marco polo updated MINIFICPP-356:
-
Description: Switch to /site-to-site/ to capture Site to Site information. 
Currently we use /controller but that is not a documented endpoint in the rest 
API documentation, as such we should move to a guaranteed endpoint.   (was: 
Switch to /site-to-site/ to capture Site to Site information)

> Switch to /site-to-site/ to capture Site to Site information
> 
>
> Key: MINIFICPP-356
> URL: https://issues.apache.org/jira/browse/MINIFICPP-356
> Project: NiFi MiNiFi C++
>  Issue Type: Bug
>Reporter: marco polo
>
> Switch to /site-to-site/ to capture Site to Site information. Currently we 
> use /controller but that is not a documented endpoint in the rest API 
> documentation, as such we should move to a guaranteed endpoint. 



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

[jira] [Created] (MINIFICPP-356) Switch to /site-to-site/ to capture Site to Site information

[marco polo (JIRA)]

marco polo created MINIFICPP-356:


 Summary: Switch to /site-to-site/ to capture Site to Site 
information
 Key: MINIFICPP-356
 URL: https://issues.apache.org/jira/browse/MINIFICPP-356
 Project: NiFi MiNiFi C++
  Issue Type: Bug
Reporter: marco polo


Switch to /site-to-site/ to capture Site to Site information



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

[jira] [Commented] (NIFI-4709) ListAzureBlobStorage misunderstands target system timestamp precision as Minutes

[ASF subversion and git services (JIRA)]

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

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

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

NIFI-4709 - Fixed ListAzureBlobStorage timestamp precision handling.

Signed-off-by: Pierre Villard 

This closes #2354.


> ListAzureBlobStorage misunderstands target system timestamp precision as 
> Minutes
> 
>
> Key: NIFI-4709
> URL: https://issues.apache.org/jira/browse/NIFI-4709
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.4.0
>Reporter: Koji Kawamura
>Assignee: Koji Kawamura
> Fix For: 1.5.0
>
>
> NIFI-4069 added target system timestamp detection for List processors. 
> Defaults to auto detection. Most sub classes added 'Target System Timestamp 
> Precision' to their 'getSupportedPropertyDescriptors' method. But 
> ListAzureBlobStorage didn't.
> Even though 'Target System Timestamp Precision' property has a default value, 
> if it's not included in getSupportedPropertyDescriptors method, the property 
> value becomes null, instead of the default value. This combination is not 
> handled well in AbstractListProcessor currently. That makes 
> ListAzureBlobStorage behaves as if Azure Blob Storage time precision is in 
> Minutes while it actually has Seconds precision. Incurs longer time for blob 
> files to be picked than required.
> Not having 'Target System Timestamp Precision' at ListAzureBlobStorage seems 
> reasonable as the processor interact with only Azure Blob Storage, and its 
> timestamp precision should be fixed. AbstractListProcessor should provide an 
> extension point for sub-classes to define default precision. In case for 
> Azure Blob, it's SECONDS.



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

[GitHub] nifi pull request #2354: NIFI-4709: Fixed ListAzureBlobStorage timestamp pre...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Updated] (NIFI-4709) ListAzureBlobStorage misunderstands target system timestamp precision as Minutes

[Pierre Villard (JIRA)]

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

Pierre Villard updated NIFI-4709:
-
   Resolution: Fixed
Fix Version/s: 1.5.0
   Status: Resolved  (was: Patch Available)

> ListAzureBlobStorage misunderstands target system timestamp precision as 
> Minutes
> 
>
> Key: NIFI-4709
> URL: https://issues.apache.org/jira/browse/NIFI-4709
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.4.0
>Reporter: Koji Kawamura
>Assignee: Koji Kawamura
> Fix For: 1.5.0
>
>
> NIFI-4069 added target system timestamp detection for List processors. 
> Defaults to auto detection. Most sub classes added 'Target System Timestamp 
> Precision' to their 'getSupportedPropertyDescriptors' method. But 
> ListAzureBlobStorage didn't.
> Even though 'Target System Timestamp Precision' property has a default value, 
> if it's not included in getSupportedPropertyDescriptors method, the property 
> value becomes null, instead of the default value. This combination is not 
> handled well in AbstractListProcessor currently. That makes 
> ListAzureBlobStorage behaves as if Azure Blob Storage time precision is in 
> Minutes while it actually has Seconds precision. Incurs longer time for blob 
> files to be picked than required.
> Not having 'Target System Timestamp Precision' at ListAzureBlobStorage seems 
> reasonable as the processor interact with only Azure Blob Storage, and its 
> timestamp precision should be fixed. AbstractListProcessor should provide an 
> extension point for sub-classes to define default precision. In case for 
> Azure Blob, it's SECONDS.



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

[jira] [Commented] (NIFI-4709) ListAzureBlobStorage misunderstands target system timestamp precision as Minutes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4709:
--

Github user asfgit closed the pull request at:

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


> ListAzureBlobStorage misunderstands target system timestamp precision as 
> Minutes
> 
>
> Key: NIFI-4709
> URL: https://issues.apache.org/jira/browse/NIFI-4709
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.4.0
>Reporter: Koji Kawamura
>Assignee: Koji Kawamura
> Fix For: 1.5.0
>
>
> NIFI-4069 added target system timestamp detection for List processors. 
> Defaults to auto detection. Most sub classes added 'Target System Timestamp 
> Precision' to their 'getSupportedPropertyDescriptors' method. But 
> ListAzureBlobStorage didn't.
> Even though 'Target System Timestamp Precision' property has a default value, 
> if it's not included in getSupportedPropertyDescriptors method, the property 
> value becomes null, instead of the default value. This combination is not 
> handled well in AbstractListProcessor currently. That makes 
> ListAzureBlobStorage behaves as if Azure Blob Storage time precision is in 
> Minutes while it actually has Seconds precision. Incurs longer time for blob 
> files to be picked than required.
> Not having 'Target System Timestamp Precision' at ListAzureBlobStorage seems 
> reasonable as the processor interact with only Azure Blob Storage, and its 
> timestamp precision should be fixed. AbstractListProcessor should provide an 
> extension point for sub-classes to define default precision. In case for 
> Azure Blob, it's SECONDS.



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

[jira] [Commented] (NIFI-4709) ListAzureBlobStorage misunderstands target system timestamp precision as Minutes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-4709:
--

Github user pvillard31 commented on the issue:

https://github.com/apache/nifi/pull/2354
  
+1, confirmed that default system timestamp precision is set as expected, 
merging to master, thanks @ijokarumawak 


> ListAzureBlobStorage misunderstands target system timestamp precision as 
> Minutes
> 
>
> Key: NIFI-4709
> URL: https://issues.apache.org/jira/browse/NIFI-4709
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.4.0
>Reporter: Koji Kawamura
>Assignee: Koji Kawamura
>
> NIFI-4069 added target system timestamp detection for List processors. 
> Defaults to auto detection. Most sub classes added 'Target System Timestamp 
> Precision' to their 'getSupportedPropertyDescriptors' method. But 
> ListAzureBlobStorage didn't.
> Even though 'Target System Timestamp Precision' property has a default value, 
> if it's not included in getSupportedPropertyDescriptors method, the property 
> value becomes null, instead of the default value. This combination is not 
> handled well in AbstractListProcessor currently. That makes 
> ListAzureBlobStorage behaves as if Azure Blob Storage time precision is in 
> Minutes while it actually has Seconds precision. Incurs longer time for blob 
> files to be picked than required.
> Not having 'Target System Timestamp Precision' at ListAzureBlobStorage seems 
> reasonable as the processor interact with only Azure Blob Storage, and its 
> timestamp precision should be fixed. AbstractListProcessor should provide an 
> extension point for sub-classes to define default precision. In case for 
> Azure Blob, it's SECONDS.



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

[GitHub] nifi issue #2354: NIFI-4709: Fixed ListAzureBlobStorage timestamp precision ...

[pvillard31]

Github user pvillard31 commented on the issue:

https://github.com/apache/nifi/pull/2354
  
+1, confirmed that default system timestamp precision is set as expected, 
merging to master, thanks @ijokarumawak 


---