[jira] [Commented] (NIFI-2374) IdentifyMimeType documentation is misleading
[ https://issues.apache.org/jira/browse/NIFI-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15481534#comment-15481534 ] Andre commented on NIFI-2374: - [~joewitt] Note sure if we are on the same page, but this is truly a version bump, no added functionality, specially around metadata extraction via parsers. 1 - I am not sure if we need the parsers to be honest... If I understand Tika correctly, the core library does identification while the Parsers would allow us to extract metadata from the identified files. I base this understanding on the following excerpt from the URL you linked: bq. Please note that Apache Tika is able to detect a much wider range of formats than those listed below, this page only documents those formats from which Tika is able to extract metadata and/or textual content. 2 - The list is for parsers, not for "file magic" performed by [Detector|https://tika.apache.org/1.13/api/org/apache/tika/detect/Detector.html] we call here: https://github.com/apache/nifi/blob/f987b216090f29719976ed1693be2ea358523aa5/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/IdentifyMimeType.java#L134 I tried to find a better list but couldn't. :-( 3 - Very valid point... Afaik no changes in regards to NIFI-2667 :-) So just to emphasise again, my idea was just to bump dependency version, without adding any additional Tika feature. Let me know if you would like some extra action I will be happy to address. > IdentifyMimeType documentation is misleading > > > Key: NIFI-2374 > URL: https://issues.apache.org/jira/browse/NIFI-2374 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.0.0, 0.7.0 >Reporter: Andre >Assignee: Andre >Priority: Minor > Fix For: 1.1.0 > > > The current documentation of IdentifyMimeType mentions the processor is > capable of identifying a reasonably small range of file types. > However, upon inspecting the code, it becomes evident that the processor > employs Apache Tike detectors and parsers (required to distinguish a ZIP file > from a JAR). > This means the list of File(MIME) types detected is the same as the one > present in Tika's DefaultDetector. > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (NIFI-2744) pom files should allow hbase version to be overwritten
[ https://issues.apache.org/jira/browse/NIFI-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andre resolved NIFI-2744. - Resolution: Duplicate > pom files should allow hbase version to be overwritten > -- > > Key: NIFI-2744 > URL: https://issues.apache.org/jira/browse/NIFI-2744 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.0.0 >Reporter: Andre >Assignee: Andre > Fix For: 1.1.0 > > > As part of 1.0.0 we allowed users to compile NiFi against vendor maintained > repositories. > While this works very well for Hadoop (and HDFS), we have not allowed users > to overwrite the HBASE version to use particular versions supported by a > vendor (e.g. use {{1.1.1-mapr-1602-m7-5.1.0}} to enable NiFi to write into > MapR-DB) > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2684) Validation error messages should refer to propertyDescriptor using its displayName
[ https://issues.apache.org/jira/browse/NIFI-2684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andre updated NIFI-2684: Description: When certain validation violation are triggered, {{AbstractConfigurableComponent}} refers to the descriptor using {{descriptor.getName()}} the result is that error messages end up referring to properties by sometimes cryptic names (instead of the "pretty names" defined in {{.displayName}} ) Users would be better of if we used {{displayName}} on error messages when available, but to fallback to names in case displayName is null. was: When message validation violation is triggered, {{AbstractConfigurableComponent}} refers to the descriptor using {{descriptor.getName()}} the result is that error messages end up referring to properties by sometimes cryptic names (instead of the "pretty names" defined in {{.displayName}} ) Users would be better of if we used {{displayName}} on error messages. > Validation error messages should refer to propertyDescriptor using its > displayName > -- > > Key: NIFI-2684 > URL: https://issues.apache.org/jira/browse/NIFI-2684 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.0.0 >Reporter: Andre >Assignee: Andre > Fix For: 1.1.0 > > > When certain validation violation are triggered, > {{AbstractConfigurableComponent}} refers to the descriptor using > {{descriptor.getName()}} > the result is that error messages end up referring to properties by sometimes > cryptic names (instead of the "pretty names" defined in {{.displayName}} ) > Users would be better of if we used {{displayName}} on error messages when > available, but to fallback to names in case displayName is null. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi pull request #1002: NIFI-2684 - Change AbstractConfigurableComponent to...
GitHub user trixpan opened a pull request: https://github.com/apache/nifi/pull/1002 NIFI-2684 - Change AbstractConfigurableComponent to use displayName w⦠â¦hen available You can merge this pull request into a Git repository by running: $ git pull https://github.com/trixpan/nifi NIFI-2684 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/1002.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 #1002 commit c6a36323ec73d1eb6744132857c2e86998678013 Author: Andre F de Miranda Date: 2016-09-11T11:45:02Z NIFI-2684 - Change AbstractConfigurableComponent to use displayName when available --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2684) Validation error messages should refer to propertyDescriptor using its displayName
[ https://issues.apache.org/jira/browse/NIFI-2684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15481620#comment-15481620 ] ASF GitHub Bot commented on NIFI-2684: -- GitHub user trixpan opened a pull request: https://github.com/apache/nifi/pull/1002 NIFI-2684 - Change AbstractConfigurableComponent to use displayName w… …hen available You can merge this pull request into a Git repository by running: $ git pull https://github.com/trixpan/nifi NIFI-2684 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/1002.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 #1002 commit c6a36323ec73d1eb6744132857c2e86998678013 Author: Andre F de Miranda Date: 2016-09-11T11:45:02Z NIFI-2684 - Change AbstractConfigurableComponent to use displayName when available > Validation error messages should refer to propertyDescriptor using its > displayName > -- > > Key: NIFI-2684 > URL: https://issues.apache.org/jira/browse/NIFI-2684 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.0.0 >Reporter: Andre >Assignee: Andre > Fix For: 1.1.0 > > > When certain validation violation are triggered, > {{AbstractConfigurableComponent}} refers to the descriptor using > {{descriptor.getName()}} > the result is that error messages end up referring to properties by sometimes > cryptic names (instead of the "pretty names" defined in {{.displayName}} ) > Users would be better of if we used {{displayName}} on error messages when > available, but to fallback to names in case displayName is null. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #1002: NIFI-2684 - Change AbstractConfigurableComponent to use di...
Github user trixpan commented on the issue: https://github.com/apache/nifi/pull/1002 @joewitt this commit is quite small (intent is just aesthetics / UX) but ventures into waters I don't usually sail... Would you mind having a look? I thank you in advance --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2684) Validation error messages should refer to propertyDescriptor using its displayName
[ https://issues.apache.org/jira/browse/NIFI-2684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15481633#comment-15481633 ] ASF GitHub Bot commented on NIFI-2684: -- Github user trixpan commented on the issue: https://github.com/apache/nifi/pull/1002 @joewitt this commit is quite small (intent is just aesthetics / UX) but ventures into waters I don't usually sail... Would you mind having a look? I thank you in advance > Validation error messages should refer to propertyDescriptor using its > displayName > -- > > Key: NIFI-2684 > URL: https://issues.apache.org/jira/browse/NIFI-2684 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.0.0 >Reporter: Andre >Assignee: Andre > Fix For: 1.1.0 > > > When certain validation violation are triggered, > {{AbstractConfigurableComponent}} refers to the descriptor using > {{descriptor.getName()}} > the result is that error messages end up referring to properties by sometimes > cryptic names (instead of the "pretty names" defined in {{.displayName}} ) > Users would be better of if we used {{displayName}} on error messages when > available, but to fallback to names in case displayName is null. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2685) Builds fails due to "java.awt.AWTError: Can't connect to X11 window server "
[ https://issues.apache.org/jira/browse/NIFI-2685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15481759#comment-15481759 ] Andre commented on NIFI-2685: - [~tkurc] NIFI-827 is source of the bootstrap setting mentioned above, it predates NIFI-615 and the inclusion of ResizeImage processor, reason perhaps why the bug was not previously identified. There seem to be no other uses of AWT across NiFi and we can also pinpoint the issue to: https://github.com/apache/nifi/blob/7e7d79fc6a0376ed27c37bd75ef5bd57d439979d/nifi-nar-bundles/nifi-media-bundle/nifi-media-processors/src/main/java/org/apache/nifi/processors/image/ResizeImage.java#L171 as far as I could tell, the only way of getting AWT to ignore the display setting is (1) to unset DISPLAY prior to execution, (2) set a java property via code or via {{-D}} I am on the same page with you regarding the environmental aspect of this bug, however, independently of the trigger for this issue, it seems reasonable to me that surefire should be configured to closely match the environment NIFI will run on, in this case a headless environment as set by the bootstrap. Let me know your preferred approach (close with won't fix) or to push the pom change. Cheers > Builds fails due to "java.awt.AWTError: Can't connect to X11 window server " > > > Key: NIFI-2685 > URL: https://issues.apache.org/jira/browse/NIFI-2685 > Project: Apache NiFi > Issue Type: Bug >Reporter: Andre >Assignee: Andre >Priority: Trivial > > When building NiFi on a machine with ssh X11 forwarding enabled, maven may > fail to build due to the following error: > {code} > testResize(org.apache.nifi.processors.image.TestResizeImage) Time elapsed: > 2.22 sec <<< FAILURE! > java.lang.AssertionError: java.awt.AWTError: Can't connect to X11 window > server using 'localhost:12.0' as the value of the DISPLAY variable. > at > org.apache.nifi.util.StandardProcessorTestRunner.run(StandardProcessorTestRunner.java:192) > at > org.apache.nifi.util.StandardProcessorTestRunner.run(StandardProcessorTestRunner.java:151) > at > org.apache.nifi.util.StandardProcessorTestRunner.run(StandardProcessorTestRunner.java:146) > at > org.apache.nifi.util.StandardProcessorTestRunner.run(StandardProcessorTestRunner.java:141) > at > org.apache.nifi.util.StandardProcessorTestRunner.run(StandardProcessorTestRunner.java:136) > at > org.apache.nifi.processors.image.TestResizeImage.testResize(TestResizeImage.java:44) > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2685) Builds fails due to "java.awt.AWTError: Can't connect to X11 window server "
[ https://issues.apache.org/jira/browse/NIFI-2685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15481794#comment-15481794 ] Joseph Witt commented on NIFI-2685: --- [~tkurc] i do share the view that the system property setting in the pom is fair game based on what Andre raised (build environment to match execution environment). In some cases the build fails and in others during the build you see a window pop up and go away. I"d like to avoid both and this fix does that. I think your point about proper environmental settings is still true but this pom change fixes the spirit of the JIRA. [~trixpan] I'm a +1 but let's see what Tony says. > Builds fails due to "java.awt.AWTError: Can't connect to X11 window server " > > > Key: NIFI-2685 > URL: https://issues.apache.org/jira/browse/NIFI-2685 > Project: Apache NiFi > Issue Type: Bug >Reporter: Andre >Assignee: Andre >Priority: Trivial > > When building NiFi on a machine with ssh X11 forwarding enabled, maven may > fail to build due to the following error: > {code} > testResize(org.apache.nifi.processors.image.TestResizeImage) Time elapsed: > 2.22 sec <<< FAILURE! > java.lang.AssertionError: java.awt.AWTError: Can't connect to X11 window > server using 'localhost:12.0' as the value of the DISPLAY variable. > at > org.apache.nifi.util.StandardProcessorTestRunner.run(StandardProcessorTestRunner.java:192) > at > org.apache.nifi.util.StandardProcessorTestRunner.run(StandardProcessorTestRunner.java:151) > at > org.apache.nifi.util.StandardProcessorTestRunner.run(StandardProcessorTestRunner.java:146) > at > org.apache.nifi.util.StandardProcessorTestRunner.run(StandardProcessorTestRunner.java:141) > at > org.apache.nifi.util.StandardProcessorTestRunner.run(StandardProcessorTestRunner.java:136) > at > org.apache.nifi.processors.image.TestResizeImage.testResize(TestResizeImage.java:44) > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #1002: NIFI-2684 - Change AbstractConfigurableComponent to use di...
Github user joewitt commented on the issue: https://github.com/apache/nifi/pull/1002 @trixpan from DRY/readability perspective consider creating the builder ahead of the if/else. So an alternative approach would look like this (formatting aside) ` ValidationResult.Builder builder = new ValidationResult.Builder().valid(false).input(null).subject(descriptor.getDisplayName()); builder = (descriptor.getDisplayName() != null) ? builder.explanation(descriptor.getDisplayName() + " is required") : .explanation(descriptor.getName() + " is required"); results.add(builder.build()); ` --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2684) Validation error messages should refer to propertyDescriptor using its displayName
[ https://issues.apache.org/jira/browse/NIFI-2684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15481805#comment-15481805 ] ASF GitHub Bot commented on NIFI-2684: -- Github user joewitt commented on the issue: https://github.com/apache/nifi/pull/1002 @trixpan from DRY/readability perspective consider creating the builder ahead of the if/else. So an alternative approach would look like this (formatting aside) ` ValidationResult.Builder builder = new ValidationResult.Builder().valid(false).input(null).subject(descriptor.getDisplayName()); builder = (descriptor.getDisplayName() != null) ? builder.explanation(descriptor.getDisplayName() + " is required") : .explanation(descriptor.getName() + " is required"); results.add(builder.build()); ` > Validation error messages should refer to propertyDescriptor using its > displayName > -- > > Key: NIFI-2684 > URL: https://issues.apache.org/jira/browse/NIFI-2684 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.0.0 >Reporter: Andre >Assignee: Andre > Fix For: 1.1.0 > > > When certain validation violation are triggered, > {{AbstractConfigurableComponent}} refers to the descriptor using > {{descriptor.getName()}} > the result is that error messages end up referring to properties by sometimes > cryptic names (instead of the "pretty names" defined in {{.displayName}} ) > Users would be better of if we used {{displayName}} on error messages when > available, but to fallback to names in case displayName is null. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2755) Minor typo on Developer Guide's Controller Services section
Andre created NIFI-2755: --- Summary: Minor typo on Developer Guide's Controller Services section Key: NIFI-2755 URL: https://issues.apache.org/jira/browse/NIFI-2755 Project: Apache NiFi Issue Type: Bug Reporter: Andre Assignee: Andre Priority: Trivial Fix For: 1.1.0 {{Rather, they are used Processors, Reporting Tasks, and other Controller Services.}} should read Rather, they are used *by* Processors, Reporting Tasks, and other Controller Services. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi pull request #1003: NIFI-2755 - Fixes minor typo in Developers Guide
GitHub user trixpan opened a pull request: https://github.com/apache/nifi/pull/1003 NIFI-2755 - Fixes minor typo in Developers Guide You can merge this pull request into a Git repository by running: $ git pull https://github.com/trixpan/nifi NIFI-2755 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/1003.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 #1003 commit 0641bfd688cd1408b4963239a25140bc846763d1 Author: Andre F de Miranda Date: 2016-09-11T15:04:11Z NIFI-2755 - Fixes minor typo in Developers Guide --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2755) Minor typo on Developer Guide's Controller Services section
[ https://issues.apache.org/jira/browse/NIFI-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15481888#comment-15481888 ] ASF GitHub Bot commented on NIFI-2755: -- GitHub user trixpan opened a pull request: https://github.com/apache/nifi/pull/1003 NIFI-2755 - Fixes minor typo in Developers Guide You can merge this pull request into a Git repository by running: $ git pull https://github.com/trixpan/nifi NIFI-2755 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/1003.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 #1003 commit 0641bfd688cd1408b4963239a25140bc846763d1 Author: Andre F de Miranda Date: 2016-09-11T15:04:11Z NIFI-2755 - Fixes minor typo in Developers Guide > Minor typo on Developer Guide's Controller Services section > --- > > Key: NIFI-2755 > URL: https://issues.apache.org/jira/browse/NIFI-2755 > Project: Apache NiFi > Issue Type: Bug >Reporter: Andre >Assignee: Andre >Priority: Trivial > Fix For: 1.1.0 > > > {{Rather, they are used Processors, Reporting Tasks, and other Controller > Services.}} > should read > Rather, they are used *by* Processors, Reporting Tasks, and other Controller > Services. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2756) nifi-processor-bundle-archetype lacks displayName property
Andre created NIFI-2756: --- Summary: nifi-processor-bundle-archetype lacks displayName property Key: NIFI-2756 URL: https://issues.apache.org/jira/browse/NIFI-2756 Project: Apache NiFi Issue Type: Bug Reporter: Andre Assignee: Andre When using {{nifi-processor-bundle-archetype}} to create a new bundle, the resulting code lacks displayName leading to a number of PR and contributions to arrive to peer review without displayName configured -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi pull request #1004: NIFI-2756 - Add displayName to maven archetypes
GitHub user trixpan opened a pull request: https://github.com/apache/nifi/pull/1004 NIFI-2756 - Add displayName to maven archetypes @alopresto Would you mind having a look on this PR? I am not familiar with maven archetypes but I noticed that the ones we have seem to result in code lacking some of the present practices such as having displayName, including * imports, unused classes, etc. This PR tries to address that. Cheer You can merge this pull request into a Git repository by running: $ git pull https://github.com/trixpan/nifi NIFI-2756 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/1004.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 #1004 commit 7f4436286713dcbb303114eeb5f1fd8fc8ef9799 Author: Andre F de Miranda Date: 2016-09-11T15:49:01Z NIFI-2756 - Add displayName to maven archetypes --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2756) nifi-processor-bundle-archetype lacks displayName property
[ https://issues.apache.org/jira/browse/NIFI-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15481958#comment-15481958 ] ASF GitHub Bot commented on NIFI-2756: -- GitHub user trixpan opened a pull request: https://github.com/apache/nifi/pull/1004 NIFI-2756 - Add displayName to maven archetypes @alopresto Would you mind having a look on this PR? I am not familiar with maven archetypes but I noticed that the ones we have seem to result in code lacking some of the present practices such as having displayName, including * imports, unused classes, etc. This PR tries to address that. Cheer You can merge this pull request into a Git repository by running: $ git pull https://github.com/trixpan/nifi NIFI-2756 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/1004.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 #1004 commit 7f4436286713dcbb303114eeb5f1fd8fc8ef9799 Author: Andre F de Miranda Date: 2016-09-11T15:49:01Z NIFI-2756 - Add displayName to maven archetypes > nifi-processor-bundle-archetype lacks displayName property > -- > > Key: NIFI-2756 > URL: https://issues.apache.org/jira/browse/NIFI-2756 > Project: Apache NiFi > Issue Type: Bug >Reporter: Andre >Assignee: Andre > > When using {{nifi-processor-bundle-archetype}} to create a new bundle, the > resulting code lacks displayName leading to a number of PR and contributions > to arrive to peer review without displayName configured -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] nifi issue #982: NIFI-2251 - Initial commit for client side provenance linea...
Github user YolandaMDavis commented on the issue: https://github.com/apache/nifi/pull/982 @mcgilman thanks for reviewing. I can take a look at the svg rendered and retest. Also I'll update the icon. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-2251) Restore lineage graph export
[ https://issues.apache.org/jira/browse/NIFI-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15482363#comment-15482363 ] ASF GitHub Bot commented on NIFI-2251: -- Github user YolandaMDavis commented on the issue: https://github.com/apache/nifi/pull/982 @mcgilman thanks for reviewing. I can take a look at the svg rendered and retest. Also I'll update the icon. > Restore lineage graph export > > > Key: NIFI-2251 > URL: https://issues.apache.org/jira/browse/NIFI-2251 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Reporter: Matt Gilman >Assignee: Yolanda M. Davis > Fix For: 1.1.0 > > > Restore the lineage graph download/export using client side > methods/technologies to prevent unnecessary trips to the server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2757) Site-to-Site Auth Breaks when using DN Identity Mapping Patterns
Peter Wicks created NIFI-2757: - Summary: Site-to-Site Auth Breaks when using DN Identity Mapping Patterns Key: NIFI-2757 URL: https://issues.apache.org/jira/browse/NIFI-2757 Project: Apache NiFi Issue Type: Bug Components: Core Framework Affects Versions: 1.0.0 Reporter: Peter Wicks If you setup a nifi.security.identity.mapping for DN's Site-to-Site won't be able to authenticate against the server with identity mappings unless you create two user accounts, one for the identity mapped one and another with the full DN from the certificate. Maybe look at StandardRootGroupPort.java, final CommunicationsSession commsSession = peer.getCommunicationsSession(); final String sourceDn = commsSession.getUserDn(); .. final PortAuthorizationResult authorizationResult = checkUserAuthorization(sourceDn); -- This message was sent by Atlassian JIRA (v6.3.4#6332)