[jira] [Resolved] (NIFI-9931) OutOfMemoryError from EvaluateXPath processor halts all FlowFiles from upstream
[
https://issues.apache.org/jira/browse/NIFI-9931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
endzeit resolved NIFI-9931.
---
Resolution: Won't Fix
> OutOfMemoryError from EvaluateXPath processor halts all FlowFiles from
> upstream
> ---
>
> Key: NIFI-9931
> URL: https://issues.apache.org/jira/browse/NIFI-9931
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.16.0
>Reporter: endzeit
>Assignee: endzeit
>Priority: Minor
>
> For some of our flows in NiFi Apache we need to extract information out of
> XML files for later use. As we need to transform the FlowFile's content while
> retaining that information, we extract the required bits into FlowFile
> attributes.
> We make use of the _EvaluateXPath_ processor for this, most of the time,
> which works like a charm in 99,99% of cases.
> However, recently we had a minor outage caused by the processor. Normally the
> content inside the tag is quite small and can be put into the FlowFile
> attributes (and thus in RAM) without problems. A malprocessed XML with an
> unusually large content in one of the XML tags we extract to the FlowFile
> attributes reached the processor, which resulted in an _OutOfMemoryError_ and
> the processor itself yielding. As the FlowFile's content did not change, all
> subsequent attempts to extract the data resulted in the same
> _OutOfMemoryError_ and the processor yielding again and again.
> Ultimately, this resulted in blocking any following FlowFiles in the upstream
> and bringing processing to a halt effectively.
>
> That's why we'd like to propose (and contribute, if accepted) an extension to
> the _EvaluateXPath_ processor to mitigate or at least reduce the risk for
> this behaviour to occurr.
> We thought about a new (optional) property which limits the amount of
> characters / bytes allowed for each extracted tag. This "{_}Maximum Attribute
> Size{_}" would only take affect when set and the _Destination_ is set to
> {_}flowfile-attribute{_}. If any extraction would reach this limit, the
> FlowFile should be moved to the _failure_ relationship instead of yielding
> the processor and blocking the upstream.
> However, other ideas and proposals are welcomed as well. This will not be a
> complete solution to the problem, but should limit the propability of it
> happening.
> --
> As a "quick fix", to mitigate the error for now, we prepended every
> _EvaluateXPath_ processor with a _RouteOnAttribute_ processor, that filters
> out any files whose content exceed an arbitrary size of FlowFiles we know
> were processed successfully in the past.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (NIFI-12632) Extract SFTP components out of the standard bundle
[ https://issues.apache.org/jira/browse/NIFI-12632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] endzeit resolved NIFI-12632. Resolution: Later > Extract SFTP components out of the standard bundle > -- > > Key: NIFI-12632 > URL: https://issues.apache.org/jira/browse/NIFI-12632 > Project: Apache NiFi > Issue Type: Sub-task >Reporter: endzeit >Assignee: endzeit >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > NIFI-11171 and the goals for NIFI 2.0 outline the desire to extract the SFTP > based components out of the standard bundle into a separate bundle. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-12841) Introduce RemoveXYZ type of processors
[
https://issues.apache.org/jira/browse/NIFI-12841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
endzeit resolved NIFI-12841.
Resolution: Invalid
> Introduce RemoveXYZ type of processors
> --
>
> Key: NIFI-12841
> URL: https://issues.apache.org/jira/browse/NIFI-12841
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: endzeit
>Priority: Minor
>
> There is the notion of "families" or "types" of processors in the standard
> distribution of NiFi.
> Among others, these are {{ListXYZ}}, {{GetXYZ}}, {{FetchXYZ}}, {{UpdateXYZ}},
> and {{PutXYZ}}.
> The following examples will be based on files on the local filesystem.
> However, the same principle applies to other types of resources, e.g. files
> on a SFTP server.
> The existing {{GetFile}} and {{FetchFile}} processors support the removal of
> the resource from the source after successful transfer into the content of a
> FlowFile.
> However, in some scenarios it might be undesired to remove the resource until
> it has been processed successfully and the transformation result be stored,
> e.g. to a secure network storage.
> This cannot be achieved with a {{GetXYZ}} or {{FetchXYZ}} processor on its
> own.
> As of now, one of the scripting processors or even a full-fledged custom
> processor can be used to achieve this.
> However, these might get relatively involved due to session handling or other
> concerns.
> This issue proposes the introduction of an additional such processor "type",
> namely {{RemoveXYZ}} which removes a resource.
> The base processor should have two properties, namely {{path}} and
> {{filename}}, by default retrieving their values from the respective core
> FlowFile attributes. Implementations may add protocol specific properties,
> e.g. for authentication.
> There should be three outgoing relationships at least:
> - "success" for FlowFiles, where the resource was removed from the source,
> - "not exists" for FlowFiles, where the resource did (no longer) exist on the
> source,
> - "failure" for FlowFiles, where the resource couldn't be removed from the
> source, e.g. due to network errors or missing permissions.
> An initial implementation should provide {{RemoveXYZ}} for one of the
> existing resources types, e.g. File, FTP, SFTP...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] NIFI-12857 Add test for and refactor implementation of QueuePrioritizer [nifi]
EndzeitBegins opened a new pull request, #8466: URL: https://github.com/apache/nifi/pull/8466 # Summary [NIFI-12857](https://issues.apache.org/jira/browse/NIFI-12857) Additionally, removed some dead code from `TestStandardFlowFileQueue`. # Tracking Please complete the following tracking steps prior to pull request creation. ### Issue Tracking - [x] [Apache NiFi Jira](https://issues.apache.org/jira/browse/NIFI) issue created ### Pull Request Tracking - [x] Pull Request title starts with Apache NiFi Jira issue number, such as `NIFI-0` - [x] Pull Request commit message starts with Apache NiFi Jira issue number, as such `NIFI-0` ### Pull Request Formatting - [x] Pull Request based on current revision of the `main` branch - [x] Pull Request refers to a feature branch with one commit containing changes # Verification Please indicate the verification steps performed prior to pull request creation. ### Build - [x] Build completed using `mvn clean install -P contrib-check` - [x] JDK 21 ### Licensing - [x] New dependencies are compatible with the [Apache License 2.0](https://apache.org/licenses/LICENSE-2.0) according to the [License Policy](https://www.apache.org/legal/resolved.html) - [x] New dependencies are documented in applicable `LICENSE` and `NOTICE` files ### Documentation - [x] Documentation formatting appears as expected in rendered files -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (NIFI-12857) Refactor QueuePrioritizer using updated Java APIs
[ https://issues.apache.org/jira/browse/NIFI-12857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] endzeit updated NIFI-12857: --- Description: The QueuePrioritizer is not covered by a dedicated test. Additionally, it contains some boilerplate that can be reduced by using updated Java APIs. (was: The FlowFilePrioritizer implementations and test contain some boilerplate / duplication that can be reduced by using updated Java APIs.) > Refactor QueuePrioritizer using updated Java APIs > - > > Key: NIFI-12857 > URL: https://issues.apache.org/jira/browse/NIFI-12857 > Project: Apache NiFi > Issue Type: Task >Reporter: endzeit >Assignee: endzeit >Priority: Major > > The QueuePrioritizer is not covered by a dedicated test. Additionally, it > contains some boilerplate that can be reduced by using updated Java APIs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-12857) Refactor QueuePrioritizer using updated Java APIs
endzeit created NIFI-12857: -- Summary: Refactor QueuePrioritizer using updated Java APIs Key: NIFI-12857 URL: https://issues.apache.org/jira/browse/NIFI-12857 Project: Apache NiFi Issue Type: Task Reporter: endzeit Assignee: endzeit The FlowFilePrioritizer implementations and test contain some boilerplate / duplication that can be reduced by using updated Java APIs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (NIFI-12720) BUG - Dark mode skeleton loader styles
[ https://issues.apache.org/jira/browse/NIFI-12720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Elliott reassigned NIFI-12720: Assignee: James Elliott > BUG - Dark mode skeleton loader styles > -- > > Key: NIFI-12720 > URL: https://issues.apache.org/jira/browse/NIFI-12720 > Project: Apache NiFi > Issue Type: Sub-task >Reporter: Scott Aslan >Assignee: James Elliott >Priority: Major > Attachments: Screenshot 2024-02-01 at 11.45.08 AM.png > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] NIFI-12720 [nifi]
james-elliott opened a new pull request, #8465: URL: https://github.com/apache/nifi/pull/8465 Set an explicit background color for the skeleton-loader element so there is sufficient contrast to show the animation in both light and dark themes. # Summary [NIFI-12720](https://issues.apache.org/jira/browse/NIFI-12720) BUG - Dark mode skeleton loader styles -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (NIFI-12721) Button UX
[ https://issues.apache.org/jira/browse/NIFI-12721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Elliott reassigned NIFI-12721: Assignee: James Elliott > Button UX > - > > Key: NIFI-12721 > URL: https://issues.apache.org/jira/browse/NIFI-12721 > Project: Apache NiFi > Issue Type: Sub-task >Reporter: Scott Aslan >Assignee: James Elliott >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > When a disabled button is directly on a really dark background it is hard to > read. > When a disabled button is next to a mat-stroked-button they both appear > disabled. > Should we be using a mat-stroked-button? > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] NIFI-12721 Button UX [nifi]
james-elliott opened a new pull request, #8464: URL: https://github.com/apache/nifi/pull/8464 Updated all the dialog buttons to change them from stroked and raised to basic. This better aligns with Angular Material guidelines and should address the confusion between disabled and cancelled. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (NIFI-12855) Add more information to provenance events to facilitate full graph traversal
[
https://issues.apache.org/jira/browse/NIFI-12855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Burgess reassigned NIFI-12855:
---
Assignee: Matt Burgess
> Add more information to provenance events to facilitate full graph traversal
>
>
> Key: NIFI-12855
> URL: https://issues.apache.org/jira/browse/NIFI-12855
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
>Reporter: Matt Burgess
>Assignee: Matt Burgess
>Priority: Major
>
> Although NiFi has a capability in the UI to issue and display lineage queries
> for provenance events, it is not a complete graph that can be traversed if
> for example provenance events were stored in a graph database. The following
> features should be added:
> - A reference in a provenance event to any parent events ("previousEventIds")
> - Add methods to GraphClientService to generate queries/statements in popular
> graph languages such as Tinkerpop/Gremlin, Cypher, and SQL
> - Add explicit references to the relationship to which the FlowFile was
> transferred
> - Add ArcadeDB service as reference implementation for SQL generation
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (NIFI-12856) BUG - Documentation looks off in dark themes
James Elliott created NIFI-12856: Summary: BUG - Documentation looks off in dark themes Key: NIFI-12856 URL: https://issues.apache.org/jira/browse/NIFI-12856 Project: Apache NiFi Issue Type: Sub-task Reporter: James Elliott Attachments: image-2024-03-01-16-50-03-450.png The documentation iframe doesn't follow the dark theme class so the title looks off and the colors do not reflect dark mode. !image-2024-03-01-16-50-03-450.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] NIFI-11259 - Kafka processor refactor [nifi]
greyp9 opened a new pull request, #8463: URL: https://github.com/apache/nifi/pull/8463 # Background Previous iterations of support for Kafka client versions in NiFi (1.0, 2.0, 2.6) duplicated code from existing Kafka processors into new Maven modules, adjusted Kafka client library dependencies for the new modules, and adjusted for API differences as needed. The original JIRA associated with NiFi support for Kafka 3 (`NIFI-9330`), followed this same approach. After discussion, a new approach was chosen, and a new JIRA (`NIFI-11259`) created. - Refactor Kafka client library dependencies into a new controller service. - Expose a service API that was agnostic of any particular Kafka version. - Create new processor implementations that interacted with Kafka through the service API. In particular, the new processor module should have no Kafka dependencies. This is expected to ease the transition to future Kafka versions. - A new 3.0++ controller service might be created to isolate any major API changes to the Kafka client APIs. - The new `PublishKafka` and `ConsumeKafka` processors would need minimal / no changes to enable interactivity with the new controller service. Other refactoring activities have been undertaken at the same time: - The new `PublishKafka` processor is intended as a replacement for the existing `PublishKafka_2_6` and `PublishKafkaRecord_2_6` processor pair. It provides FlowFile-based or record-based data handling modes, controlled via a per-processor property. Similarly, `ConsumeKafka` replaces both `ConsumeKafka_2_6` and `ConsumeKafkaRecord_2_6`. This design adjustment reduces the code duplication that was present in the 2.6 processor set. # New Modules - `nifi-kafka-service-api` - API contract for `KafkaConnectionService`, which exposes access to instances of `KafkaConsumerService` and `KafkaProducerService` in a manner agnostic to a particular version of Kafka - `KafkaProducerService` - intermediary logical service brokering interactions with the producer APIs of the Kafka client libraries - `KafkaConsumerService` - intermediary logical service brokering interactions with the producer APIs of the Kafka client libraries - `nifi-kafka-service-api-nar` - NiFi NAR wrapper for the `KafkaConnectionService` API contract - `nifi-kafka-3-service` - home for `Kafka3ConnectionService`, which abstracts Kafka dependencies away from the new Kafka processors, and manages runtime connections to a remote Kafka 3 service instance - `nifi-kafka-3-service-nar` - NiFi NAR wrapper for `Kafka3ConnectionService` - `nifi-kafka-processors` - home for `PublishKafka` and `ConsumeKafka` processors, which allow interactivity with remote Kafka service instances agnostic to a particular Kafka version - `nifi-kafka-nar` - NiFi NAR wrapper for the `PublishKafka` and `ConsumeKafka` processors - `nifi-kafka-2-6-integration` - test bed to establish runtime behavior (testcontainers/kafka) of Kafka 2.6 processors for certain conditions, in order to better replicate those behaviors - `nifi-kafka-3-integration` - testing infrastructure to test new processors / controller service while communicating with an actual (testcontainers) Kafka instance - `nifi-kafka-jacoco` - module home for configuration to instrument executions of `nifi-kafka-bundle` unit tests / integration tests, in order to assess test coverage # Notes - Integration tests are employed as a "first-class citizen" means of testing expected interactions with Kafka instances, running in `testcontainers`. - https://github.com/testcontainers/testcontainers-java - It is possible to use a single instance of testcontainers/kafka per Maven module, in order to incur the startup/teardown cost only once. The intent is to employ this strategy where feasible. - Instances of `simplelogger.properties` have been useful during development, but these would be removed before PR merge. - I’ve done a significant amount of runtime testing against containerized Kafka instances using the repo/branch below. This resource may be useful for others who want to do runtime testing without the need for fixed Kafka infrastructure. - https://github.com/greyp9/kafka-images/tree/NIFI-12194 - There are opportunities to refactor common methods and declarations into the `nifi-kafka-shared` module; I’ve avoided that during development to ease the process of rebasing to `nifi/main`. - It is likely that this set of new components will co-exist with the existing Kafka 2.6 based processors for some period of time. - Allow for migration of existing flows to use the new components. - Slight behavioral differences might be anticipated during the "burn in" phase of the new components, due to the scope of work. - Code compatibility with JRE 8 has been targeted, to leave open the option of backporting this work to the
[jira] [Created] (NIFI-12855) Add more information to provenance events to facilitate full graph traversal
Matt Burgess created NIFI-12855:
---
Summary: Add more information to provenance events to facilitate
full graph traversal
Key: NIFI-12855
URL: https://issues.apache.org/jira/browse/NIFI-12855
Project: Apache NiFi
Issue Type: Improvement
Components: Core Framework
Reporter: Matt Burgess
Although NiFi has a capability in the UI to issue and display lineage queries
for provenance events, it is not a complete graph that can be traversed if for
example provenance events were stored in a graph database. The following
features should be added:
- A reference in a provenance event to any parent events ("previousEventIds")
- Add methods to GraphClientService to generate queries/statements in popular
graph languages such as Tinkerpop/Gremlin, Cypher, and SQL
- Add explicit references to the relationship to which the FlowFile was
transferred
- Add ArcadeDB service as reference implementation for SQL generation
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-12845) ListenTCP/ListenTCPRecord: store the source IPAddress/Port
[ https://issues.apache.org/jira/browse/NIFI-12845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822679#comment-17822679 ] Jim Steinebrey commented on NIFI-12845: --- [~fube1] Have you examined the existing write attributes tcp.sender and tcp.port of flow files produced by those two processors? Do they provide the information that you are looking for? Related Processor Documentation: [https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-standard-nar/1.23.2/org.apache.nifi.processors.standard.ListenTCP/index.html] [https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-standard-nar/1.23.2/org.apache.nifi.processors.standard.ListenTCPRecord/index.html] > ListenTCP/ListenTCPRecord: store the source IPAddress/Port > -- > > Key: NIFI-12845 > URL: https://issues.apache.org/jira/browse/NIFI-12845 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.23.2 >Reporter: Beat Fuellemann >Priority: Major > > We would like to use NIFI to handle a TCP Session, on which we recieve some > ASN1 keepalive. On the same session we should send back the Keepalive > response.^ > It would be great if we could store some additional attributes in the > flowfile. > * Source IP Address of the incomming connection > * Source Port of the incomming connection > This could be done for ListenTCP and ListenTCPRecord. > OR > It would be great if we have a HandleTCPRequest/HandleTCPResponse like > HandleHTTPRequest/HandleHTTPResponse. > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-12854) PutS3Object: expand support for generating metadata
Gregory M. Foreman created NIFI-12854: - Summary: PutS3Object: expand support for generating metadata Key: NIFI-12854 URL: https://issues.apache.org/jira/browse/NIFI-12854 Project: Apache NiFi Issue Type: Improvement Affects Versions: 2.0.0-M2 Reporter: Gregory M. Foreman The PutS3Object processor currently supports adding metadata to objects via dynamic properties. Add support for using FlowFile attributes to generate S3 metadata. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] MINIFICPP-2203 Add support for building Windows MSI without any redistributables included [nifi-minifi-cpp]
lordgamez commented on code in PR #1734:
URL: https://github.com/apache/nifi-minifi-cpp/pull/1734#discussion_r1509271721
##
cmake/MiNiFiOptions.cmake:
##
@@ -82,6 +80,8 @@ list(APPEND STRICT_GSL_CHECKS_Values AUDIT ON DEBUG_ONLY OFF)
set_property(CACHE STRICT_GSL_CHECKS PROPERTY STRINGS
${STRICT_GSL_CHECKS_Values})
if (WIN32)
+add_minifi_option(INSTALLER_MERGE_MODULES "Creates installer with merge
modules" OFF)
+add_minifi_option(INSTALLER_WITH_VC_REDISTRIBUTABLES "Creates installer
with Visual C++ redistributables included" OFF)
Review Comment:
I agree the naming should be changed, to be more clear, and clarify which
option bundles what artifacts exactly. It also needs to be specified if a
bundle falls under a different license.
On the other hand I would keep all three bundle options separate. The
rationale behind this version is it's easier and more direct to specify a
single option for each installer bundle option instead of combining build
options like `INCLUDE_MS_BLOBS` + `USE_UCRT_DLLS`. So I would keep them
separately like `INCLUDE_UCRT_IN_INSTALLER`, `INCLUDE_VC_REDIST_DLLS`, and
`INCLUDE_VC_REDIST_MERGE_MODULES`. This way you can directly specify which
libraries you want to include in the installer, and by not specifying anything,
no Microsoft blobs will be included. What are your thoughts on this?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] MINIFICPP-2203 Add support for building Windows MSI without any redistributables included [nifi-minifi-cpp]
szaszm commented on code in PR #1734:
URL: https://github.com/apache/nifi-minifi-cpp/pull/1734#discussion_r1509232446
##
cmake/MiNiFiOptions.cmake:
##
@@ -82,6 +80,8 @@ list(APPEND STRICT_GSL_CHECKS_Values AUDIT ON DEBUG_ONLY OFF)
set_property(CACHE STRICT_GSL_CHECKS PROPERTY STRINGS
${STRICT_GSL_CHECKS_Values})
if (WIN32)
+add_minifi_option(INSTALLER_MERGE_MODULES "Creates installer with merge
modules" OFF)
+add_minifi_option(INSTALLER_WITH_VC_REDISTRIBUTABLES "Creates installer
with Visual C++ redistributables included" OFF)
Review Comment:
The naming is confusing, and not specific enough. Merge modules and bundled
DLLs are both Visual C++ redistributable runtimes (runtime meaning library or
DLL in this case), they're just different ways of installing the same DLLs of
the C and C++ standard libraries. Under the old version, if the user didn't ask
for merge modules, they got bundled DLLs.
There is also the Universal C Runtime (UCRT) DLLs that are not part of the
same Visual C++ redistributable runtimes package, but they are also standard
library DLLs, they also fall under the same license terms, and are not
redistributable under the Apache License. If someone wants to NOT include the
Visual C++ redistributable runtime, then they probably want a package free of
Microsoft blobs, and they don't want to include the UCRT either.
The previous version was fine, as it treated both kinds of redistributables
under the same banner, disabling them altogether. This new version seems to
treat the Visual C++ redistributable runtime package separately from the UCRT,
and I don't see the rationale behind this.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[PR] MINIFICPP-2282 Support re-encryption of sensitive properties [nifi-minifi-cpp]
fgerlits opened a new pull request, #1739: URL: https://github.com/apache/nifi-minifi-cpp/pull/1739 Added a new `--re-encrypt` option to the `flow-config` action of the `encrypt-config` binary, which can decrypt the sensitive properties using the `.old` key and re-encrypt them with a new key (either supported by the user or auto-generated). https://issues.apache.org/jira/browse/MINIFICPP-2282 --- 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 MINIFICPP- 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 main)? - [x] 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 GitHub Actions CI results for build issues and submit an update to your PR as soon as possible. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] MINIFICPP-2306 Filter out corrupt flowfiles during startup [nifi-minifi-cpp]
martinzink opened a new pull request, #1738: URL: https://github.com/apache/nifi-minifi-cpp/pull/1738 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 MINIFICPP- 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 main)? - [ ] 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 GitHub Actions CI results for build issues and submit an update to your PR as soon as possible. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] NIFI-11520: Add a menu to display Flow Analysis report results [nifi]
tpalfy commented on code in PR #8273:
URL: https://github.com/apache/nifi/pull/8273#discussion_r1509031907
##
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui/src/main/webapp/js/nf/canvas/controllers/nf-ng-canvas-flow-status-controller.js:
##
@@ -400,6 +406,556 @@
}
}
+/**
+ * The flow analysis controller.
+ */
+
+this.flowAnalysis = {
+
+/**
+ * Create the list of rule violations
+ */
+buildRuleViolationsList: function(rules, violationsAndRecs) {
+var ruleViolationCountEl = $('#rule-violation-count');
+var ruleViolationListEl = $('#rule-violations-list');
+var ruleWarningCountEl = $('#rule-warning-count');
+var ruleWarningListEl = $('#rule-warnings-list');
+var violations = violationsAndRecs.filter(function
(violation) {
+return violation.enforcementPolicy === 'ENFORCE'
+});
+var warnings = violationsAndRecs.filter(function
(violation) {
+return violation.enforcementPolicy === 'WARN'
+});
+ruleViolationCountEl.empty().text('(' + violations.length
+ ')');
+ruleWarningCountEl.empty().text('(' + warnings.length +
')');
+ruleViolationListEl.empty();
+violations.forEach(function(violation) {
+var rule = rules.find(function(rule) {
+return rule.id === violation.ruleId;
+});
+// create DOM elements
+var violationListItemEl = $('');
+var violationEl = $('');
+var violationListItemWrapperEl = $('');
+var violationRuleEl = $('');
+var violationListItemNameEl = $('');
+var violationListItemIdEl = $('');
+var violationInfoButtonEl = $('');
+
+// add text content and button data
+$(violationRuleEl).text(rule.name);
+
$(violationListItemNameEl).text(violation.subjectDisplayName);
Review Comment:
@mcgilman this is a good observation. I'm trying to figure out how to solve
this. In cluster mode usually the Merger (and in this case the
FlowAnalysisResultEntityMerger) actually filters the result based on
authorization. But in non-cluster mode I don't see what the usual practice is.
Do you have a suggestion?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] MINIFICPP-1797 Python bootstrap (part 1) [nifi-minifi-cpp]
martinzink commented on PR #1681: URL: https://github.com/apache/nifi-minifi-cpp/pull/1681#issuecomment-1973123420 > An other issue I had with the minificontroller build was this on Windows: > > ``` > FAILED: bin/minificontroller.exe > cmd.exe /C "cd . && "C:\Program Files\CMake\bin\cmake.exe" -E vs_link_exe --intdir=controller\CMakeFiles\minificontroller.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\mt.exe --manifests -- C:\PROGRA~1\MICROS~1\2022\COMMUN~1\VC\Tools\MSVC\1439~1.335\bin\Hostx64\x64\link.exe /nologo controller\CMakeFiles\minificontroller.dir\MiNiFiController.cpp.obj controller\CMakeFiles\minificontroller.dir\Controller.cpp.obj controller\CMakeFiles\minificontroller.dir\__\minifi_main\MainHelper.cpp.obj controller\CMakeFiles\minificontroller.dir\versioninfo.rc.res /out:bin\minificontroller.exe /implib:controller\minificontroller.lib /pdb:bin\minificontroller.pdb /version:0.0 /machine:x64 /INCREMENTAL:NO /subsystem:console bin\core-minifi.lib thirdparty\yaml-cpp-install\lib\yaml-cpp.lib thirdparty\zlib-install\lib\zlibstatic.lib _deps\spdlog-build\spdlog.lib _deps\fmt-build\fmt.lib thirdparty\libsodium-install\lib\sodium.lib date -tz.lib thirdparty\openssl-install\lib\libssl.lib thirdparty\openssl-install\lib\libcrypto.lib crypt32.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cmd.exe /C "cd /D D:\Projects\nifi-minifi-cpp\build\controller && cat D:/Projects/nifi-minifi-cpp/build/all.log"" > 'cat' is not recognized as an internal or external command, > operable program or batch file. > ``` I think this was caused by an old post build step, removed it in https://github.com/apache/nifi-minifi-cpp/pull/1681/commits/9f39511a1a991454311992cbd5dbf4e128a27051 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] MINIFICPP-1797 Python bootstrap (part 1) [nifi-minifi-cpp]
martinzink commented on PR #1681: URL: https://github.com/apache/nifi-minifi-cpp/pull/1681#issuecomment-1972985944 > I created a clean new Windows VM and tried out the new python bootstrap to set up the environment. When it installed the dependencies and got into the build menu I exited the bootstrap, and tried if the build can be still run using the win_build_vs.bat script. The configuration was successful and the build started, but failed with the following issues: > > ``` > Performing configure step for 'openssl-external' > 'perl' is not recognized as an internal or external command, > operable program or batch file. > ``` > > ``` > Failure! build file wasn't produced. > Please read INSTALL.md and associated NOTES-* files. You may also have to > look over your available compiler tool chain or change your configuration. > > NASM not found - make sure it's installed and available on %PATH% > ``` > > Are the perl and NASM dependencies installed in build time using the bootstrap build command, or are they missing somehow? After I installed these 2 dependencies manually the build continued. They are installed but the choco installer doesnt add them to path. I didnt want to modify the path because strawberry ssl and nasm can mess up the path, so they are only added temporaraly to path during the bootstrap process. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
