date:20240531



joewitt opened a new pull request, #8907:
URL: https://github.com/apache/nifi/pull/8907

   com.amazonaws* 1.12.730 1.12.733
   com.azure azure-sdk-bom 1.2.23 1.2.24
   com.google.cloud libraries-bom 26.39.0 26.40.0
   commons-cli 1.7.0 1.8.0
   commons-net 3.10.0 3.11.0
   io.fabric8 * 6.12.1 6.13.0
   org.apache.commons commons-compress 1.26.1 1.26.2
   software.amazon.awssdk 2.25.60 2.25.63
   com.google.apis  google-api-services-drive v3-rev20240327-2.0.0   
v3-rev20240521-2.0.0 org.neo4j.driver  neo4j-java-driver 5.20.0 5.21.0
   org.springframework.integration  spring-integration-mail 6.2.4 6.2.5
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   # Summary
   
   [NIFI-13336](https://issues.apache.org/jira/browse/NIFI-13336)
   
   # Tracking
   
   Please complete the following tracking steps prior to pull request creation.
   
   ### Issue Tracking
   
   - [ ] [Apache NiFi Jira](https://issues.apache.org/jira/browse/NIFI) issue 
created
   
   ### Pull Request Tracking
   
   - [ ] Pull Request title starts with Apache NiFi Jira issue number, such as 
`NIFI-0`
   - [ ] Pull Request commit message starts with Apache NiFi Jira issue number, 
as such `NIFI-0`
   
   ### Pull Request Formatting
   
   - [ ] Pull Request based on current revision of the `main` branch
   - [ ] 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
   
   - [ ] Build completed using `mvn clean install -P contrib-check`
 - [ ] JDK 21
   
   ### UI Contributions
   
   - [ ] NiFi is modernizing its UI. Any contributions that update the [current 
UI](https://github.com/apache/nifi/tree/main/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui)
 also need to be implemented in the [new 
UI](https://github.com/apache/nifi/tree/main/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-frontend/src/main/nifi).
  
   
   ### Licensing
   
   - [ ] 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)
   - [ ] New dependencies are documented in applicable `LICENSE` and `NOTICE` 
files
   
   ### Documentation
   
   - [ ] 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

Re: [PR] NIFI-13313: Remove old UI [nifi]



joewitt commented on PR #8906:
URL: https://github.com/apache/nifi/pull/8906#issuecomment-2143047480

   guessing yall already on top of this based on discussion above but the build 
fails currently with
   
   `[ERROR]   
OidcLogoutSuccessHandlerTest.testOnLogoutSuccessRequestFoundEndSessionNotSupported:161
 expected:  but was: 

   [ERROR]   
OidcLogoutSuccessHandlerTest.testOnLogoutSuccessRequestFoundEndSessionSupportedTokenFound:212
 expected: 

 but was: 

   [ERROR]   
OidcLogoutSuccessHandlerTest.testOnLogoutSuccessRequestFoundEndSessionSupportedTokenNotFound:177
 expected:  but was: 

   [ERROR]   
OidcLogoutSuccessHandlerTest.testOnLogoutSuccessRequestNotFound:146 expected: 
 but was: 

   [ERROR]   Saml2LogoutSuccessHandlerTest.testOnLogoutSuccessRequestFound:95 
expected:  but was: 

   [ERROR]   
Saml2LogoutSuccessHandlerTest.testOnLogoutSuccessRequestNotFound:79 expected: 
 but was: 
`


-- 
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-13323) For 1.x, Remove the instantiation of Object arrays for arguments in ComponentLog log and org.slf4j.Logger statements



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

Daniel Stieglitz updated NIFI-13323:

Status: In Progress  (was: Patch Available)

> For 1.x, Remove the instantiation of Object arrays for arguments in 
> ComponentLog log and org.slf4j.Logger statements
> 
>
> Key: NIFI-13323
> URL: https://issues.apache.org/jira/browse/NIFI-13323
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.27.0
>Reporter: Daniel Stieglitz
>Assignee: Daniel Stieglitz
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> This ticket is a follow up of NIFI-13265 which was only able to be applied to 
> the 2.x branch. This ticket aims to do the same type of changes in the 1.x 
> branch.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (NIFI-13173) Update Hive components to Hive 4

2024-05-31 Thread Matt Burgess (Jira)



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

Matt Burgess commented on NIFI-13173:
-

Hive 4.0.0 has known vulnerabilities as well so we may need to wait for a 
version of Hive 4 with no current vulnerabilities as well as an Iceberg release 
that brings in Hive 4 on its own.

> Update Hive components to Hive 4
> 
>
> Key: NIFI-13173
> URL: https://issues.apache.org/jira/browse/NIFI-13173
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Joe Witt
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PR] NIFI-13323 Removed the instantiation of Object arrays for arguments in ComponentLog log in the HashAttribute and PostHttp Processors. [nifi]



dan-s1 commented on PR #8903:
URL: https://github.com/apache/nifi/pull/8903#issuecomment-2142998036

   @exceptionfactory I have made the changes to the 1.x branch to remove the 
instantiated Object arrays in log statements. I want to just make sure this PR 
is not to big as in addition to the two files already done I ended up changing 
296 files (so in total this PR will be changes to 298 files). Please advise.


-- 
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-13313: Remove old UI [nifi]



mcgilman commented on code in PR #8906:
URL: https://github.com/apache/nifi/pull/8906#discussion_r1622961535


##
nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/api/AccessResource.java:
##
@@ -412,7 +412,7 @@ private LogoutRequest completeLogoutRequest(final 
HttpServletResponse httpServle
 }
 
 private String getNiFiLogoutCompleteUri() {
-return getNiFiUri() + "logout-complete";
+return getNiFiUri() + "#/logout-complete";

Review Comment:
   Must have misread your comment initially but we may be able to manually add 
a Jetty config that just redirects `/nifi/logout-complete` to 
`/nifi/#/logout-complete`. This is a good idea and would address the other 
issue I noted above. Will try it out. 👍 



-- 
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-13313: Remove old UI [nifi]



mcgilman commented on code in PR #8906:
URL: https://github.com/apache/nifi/pull/8906#discussion_r1622959963


##
nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/api/AccessResource.java:
##
@@ -412,7 +412,7 @@ private LogoutRequest completeLogoutRequest(final 
HttpServletResponse httpServle
 }
 
 private String getNiFiLogoutCompleteUri() {
-return getNiFiUri() + "logout-complete";
+return getNiFiUri() + "#/logout-complete";

Review Comment:
   Good point. However, we cannot use that path because we use hash based 
routing. The hash is inserted and all routes begin after it. This allows the 
front end to handle routing independent of the path the application is deployed 
to. Switching to path based routing is a possibility but is a larger effort. 
Path based routing typically requires knowing the base path at build time. 
There may be options for setting it at run time but this would need to be 
investigated more thoroughly. 
   
   I was actually just evaluating this in the context of OIDC and there was an 
issue with hash being encoded. So we'll need to consider the options here. 



-- 
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-13313: Remove old UI [nifi]



exceptionfactory commented on code in PR #8906:
URL: https://github.com/apache/nifi/pull/8906#discussion_r1622948663


##
nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/api/AccessResource.java:
##
@@ -412,7 +412,7 @@ private LogoutRequest completeLogoutRequest(final 
HttpServletResponse httpServle
 }
 
 private String getNiFiLogoutCompleteUri() {
-return getNiFiUri() + "logout-complete";
+return getNiFiUri() + "#/logout-complete";

Review Comment:
   This will be a breaking change for existing deployments given that identity 
providers require registration of logout URLs. What do you think about 
considering a redirect from `/nifi/logout-complete` in the Jetty Server 
configuration?



-- 
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] NIFI-13313: Remove old UI [nifi]



mcgilman opened a new pull request, #8906:
URL: https://github.com/apache/nifi/pull/8906

   NIFI-13313:
   - Use nifi-web-frontend as the default UI hosted at /nifi no longer 
deploying nifi-web-ui.
   - Adding logout complete page.
   - Updating backend to redirect to new logout complete page.
   - Remove nifi-web-ui module.
   - Updating LICENSE and NOTICE files for dependencies that are no longer 
included.
   - Removing unnecessary rat config.
   - Updating README.
   - Updating proxy config to mirror actual context path.


-- 
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-13313) Replace old UI



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

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

> Replace old UI
> --
>
> Key: NIFI-13313
> URL: https://issues.apache.org/jira/browse/NIFI-13313
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> With the new UI functionally ready and other UIs (documentations, data 
> viewers, etc) no longer depending on the old UI it can now be removed. This 
> Jira is tracking removal of that maven module and any downstream changes.
> These include updating of LICENSE/NOTICEs that no longer bundle removed 
> dependencies and updating the Jetty Server to only deploy the new UI. The new 
> UI should use "/nifi" context. Existing functionality around authentication 
> where the back end redirects the user to the UI should be verified.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (NIFI-13336) Update aws, azure, gcp, commons-cli/net/compress, fabric8, neo4j, and spring integration mail

2024-05-31 Thread Joe Witt (Jira)

Joe Witt created NIFI-13336:
---

 Summary: Update aws, azure, gcp, commons-cli/net/compress, 
fabric8, neo4j, and spring integration mail
 Key: NIFI-13336
 URL: https://issues.apache.org/jira/browse/NIFI-13336
 Project: Apache NiFi
  Issue Type: Task
Reporter: Joe Witt
Assignee: Joe Witt


com.amazonaws   * 1.12.730 1.12.733
com.azure azure-sdk-bom 1.2.23 1.2.24
com.google.cloud libraries-bom 26.39.0 26.40.0
commons-cli 1.7.0 1.8.0
commons-net 3.10.0 3.11.0
io.fabric8 * 6.12.1 6.13.0
org.apache.commons commons-compress 1.26.1 1.26.2
software.amazon.awssdk 2.25.60 2.25.63
com.google.apis google-api-services-drive v3-rev20240327-2.0.0   
v3-rev20240521-2.0.0
org.neo4j.driverneo4j-java-driver 5.20.0 5.21.0
org.springframework.integration spring-integration-mail 6.2.4 6.2.5



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PR] NIFI-12801 Add local file upload option in PutHDFS processor [nifi]



shubhluck commented on PR #8415:
URL: https://github.com/apache/nifi/pull/8415#issuecomment-2142944809

   Thank you @turcsanyip for review let me quickly complete your suggested 
changes and rebasing with main branch.


-- 
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-12801 Add local file upload option in PutHDFS processor [nifi]



turcsanyip commented on code in PR #8415:
URL: https://github.com/apache/nifi/pull/8415#discussion_r1622927597


##
nifi-nar-bundles/nifi-hadoop-bundle/nifi-hdfs-processors/src/main/java/org/apache/nifi/processors/hadoop/PutHDFS.java:
##
@@ -366,14 +374,18 @@ public Object run() {
 
 // Write FlowFile to temp file on HDFS
 final StopWatch stopWatch = new StopWatch(true);
-session.read(putFlowFile, in -> {
-OutputStream fos = null;
-Path createdFile = null;
-try {
-if (conflictResponse.equals(APPEND_RESOLUTION) && 
destinationExists) {
-fos = hdfs.append(copyFile, bufferSize);
-} else {
-final EnumSet cflags = 
EnumSet.of(CreateFlag.CREATE, CreateFlag.OVERWRITE);
+final ResourceTransferSource resourceTransferSource = 
ResourceTransferSource.valueOf(
+
context.getProperty(RESOURCE_TRANSFER_SOURCE).getValue());

Review Comment:
   The preferred way to read a property containing allowable/described value:
   ```suggestion
   final ResourceTransferSource resourceTransferSource = 
context.getProperty(RESOURCE_TRANSFER_SOURCE).asAllowableValue(ResourceTransferSource.class);
   ```
   ```suggestion
   final ResourceTransferSource resourceTransferSource = 
ResourceTransferSource.valueOf(
   
context.getProperty(RESOURCE_TRANSFER_SOURCE).getValue());
   ```



-- 
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-12801 Add local file upload option in PutHDFS processor [nifi]



turcsanyip commented on code in PR #8415:
URL: https://github.com/apache/nifi/pull/8415#discussion_r1622927597


##
nifi-nar-bundles/nifi-hadoop-bundle/nifi-hdfs-processors/src/main/java/org/apache/nifi/processors/hadoop/PutHDFS.java:
##
@@ -366,14 +374,18 @@ public Object run() {
 
 // Write FlowFile to temp file on HDFS
 final StopWatch stopWatch = new StopWatch(true);
-session.read(putFlowFile, in -> {
-OutputStream fos = null;
-Path createdFile = null;
-try {
-if (conflictResponse.equals(APPEND_RESOLUTION) && 
destinationExists) {
-fos = hdfs.append(copyFile, bufferSize);
-} else {
-final EnumSet cflags = 
EnumSet.of(CreateFlag.CREATE, CreateFlag.OVERWRITE);
+final ResourceTransferSource resourceTransferSource = 
ResourceTransferSource.valueOf(
+
context.getProperty(RESOURCE_TRANSFER_SOURCE).getValue());

Review Comment:
   The preferred way the read a property containing allowable/described value:
   ```suggestion
   final ResourceTransferSource resourceTransferSource = 
context.getProperty(RESOURCE_TRANSFER_SOURCE).asAllowableValue(ResourceTransferSource.class);
   ```
   ```suggestion
   final ResourceTransferSource resourceTransferSource = 
ResourceTransferSource.valueOf(
   
context.getProperty(RESOURCE_TRANSFER_SOURCE).getValue());
   ```



-- 
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-12801 Add local file upload option in PutHDFS processor [nifi]

2024-05-31 Thread ASF subversion and git services (Jira)



turcsanyip commented on PR #8415:
URL: https://github.com/apache/nifi/pull/8415#issuecomment-2142938831

   @shubhluck Thanks for your first contribution!
   There have been changes on the main branch since you opened this PR. Could 
you please rebase your branch onto the current main, resolve the conflicts and 
then force push the branch?
   Thanks


-- 
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] [Commented] (NIFI-13307) Refactor KeyStoreUtils References using nifi-security-ssl



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

ASF subversion and git services commented on NIFI-13307:


Commit 5cf43f4a3c1a7a19550c0936c3de8f5969ccbb18 in nifi's branch 
refs/heads/main from David Handermann
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=5cf43f4a3c ]

NIFI-13307 Replaced KeyStoreUtils with nifi-security-ssl Builders (#8895)

- Removed unused test classes from nifi-web-api

> Refactor KeyStoreUtils References using nifi-security-ssl
> -
>
> Key: NIFI-13307
> URL: https://issues.apache.org/jira/browse/NIFI-13307
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The {{KeyStoreUtils}} class in {{nifi-security-utils}} contains a large 
> number of similar methods for loading keystores and other TLS components. The 
> {{nifi-security-ssl}} module contains a streamlined set of builder classes, 
> without external dependencies. References to {{KeyStoreUtils}} should be 
> refactored to use the newer builder classes to remove unnecessary 
> dependencies on {{nifi-security-utils}} and associated transitive 
> dependencies.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (NIFI-13307) Refactor KeyStoreUtils References using nifi-security-ssl

2024-05-31 Thread Bryan Bende (Jira)



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

Bryan Bende updated NIFI-13307:
---
Fix Version/s: 2.0.0-M4
   Resolution: Fixed
   Status: Resolved  (was: Patch Available)

> Refactor KeyStoreUtils References using nifi-security-ssl
> -
>
> Key: NIFI-13307
> URL: https://issues.apache.org/jira/browse/NIFI-13307
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Major
> Fix For: 2.0.0-M4
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The {{KeyStoreUtils}} class in {{nifi-security-utils}} contains a large 
> number of similar methods for loading keystores and other TLS components. The 
> {{nifi-security-ssl}} module contains a streamlined set of builder classes, 
> without external dependencies. References to {{KeyStoreUtils}} should be 
> refactored to use the newer builder classes to remove unnecessary 
> dependencies on {{nifi-security-utils}} and associated transitive 
> dependencies.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PR] NIFI-13307 Replace KeyStoreUtils with nifi-security-ssl Builders [nifi]



bbende merged PR #8895:
URL: https://github.com/apache/nifi/pull/8895


-- 
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-13231 Added Private key authentication for GitHubFlowRegistryClient [nifi]



exceptionfactory commented on PR #8890:
URL: https://github.com/apache/nifi/pull/8890#issuecomment-2142820021

   > For some reason JwtTokenProvider throws Bad Credentials , can you please 
check into it?
   
   Thanks for the updates. It sounds like an error coming from the GitHub REST 
API. I will run some local tests as part of adding the key parsing and follow 
up.


-- 
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-13329) Fallback to raw viewer when formatted viewer fails



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

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

> Fallback to raw viewer when formatted viewer fails
> --
>
> Key: NIFI-13329
> URL: https://issues.apache.org/jira/browse/NIFI-13329
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Pierre Villard
>Assignee: Matt Gilman
>Priority: Major
> Attachments: Screenshot 2024-05-30 at 11.19.23.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The formatted viewer (based on the mime.type attribute) recently became the 
> default. In case the MIME type is wrong, this would return an error when 
> opening the flowfile's content. It could be nice to catch the error and 
> fallback to the raw viewer.
> !Screenshot 2024-05-30 at 11.19.23.png|width=611,height=150!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (NIFI-13329) Fallback to raw viewer when formatted viewer fails



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

Matt Gilman reassigned NIFI-13329:
--

Assignee: Matt Gilman

> Fallback to raw viewer when formatted viewer fails
> --
>
> Key: NIFI-13329
> URL: https://issues.apache.org/jira/browse/NIFI-13329
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Pierre Villard
>Assignee: Matt Gilman
>Priority: Major
> Attachments: Screenshot 2024-05-30 at 11.19.23.png
>
>
> The formatted viewer (based on the mime.type attribute) recently became the 
> default. In case the MIME type is wrong, this would return an error when 
> opening the flowfile's content. It could be nice to catch the error and 
> fallback to the raw viewer.
> !Screenshot 2024-05-30 at 11.19.23.png|width=611,height=150!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PR] NIFI-13138 - Add extensions name and description in NiFi Registry [nifi]



pvillard31 commented on PR #8740:
URL: https://github.com/apache/nifi/pull/8740#issuecomment-2142712309

   Done, thanks @exceptionfactory 
   
   ![Screenshot 2024-05-31 at 19 27 
01](https://github.com/apache/nifi/assets/11541012/52081133-97a2-4f59-adbd-cacfa3a28e15)
   


-- 
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] [Commented] (NIFI-13329) Fallback to raw viewer when formatted viewer fails



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

Pierre Villard commented on NIFI-13329:
---

{quote}Would it make sense for this case to render an error message stating 
that the content does not match the mime type? Or there was an error in 
processing the content in formatted mode? The UI would render correctly and 
show Formatted mode with the message. The user could then change the mode to 
Original or Hex to see those views. It addresses the error page your seeing 
above. And I think this case is more uncommon. Defaulting to Formatted and 
having to manually change to Original when the content in the flowfile is wrong 
is less annoying for the user than defaulting to Original and having to 
manually change to Formatted when the content in the flowfile is correct.
{quote}
I think that makes perfect sense and is a very good behavior IMO.

> Fallback to raw viewer when formatted viewer fails
> --
>
> Key: NIFI-13329
> URL: https://issues.apache.org/jira/browse/NIFI-13329
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Pierre Villard
>Priority: Major
> Attachments: Screenshot 2024-05-30 at 11.19.23.png
>
>
> The formatted viewer (based on the mime.type attribute) recently became the 
> default. In case the MIME type is wrong, this would return an error when 
> opening the flowfile's content. It could be nice to catch the error and 
> fallback to the raw viewer.
> !Screenshot 2024-05-30 at 11.19.23.png|width=611,height=150!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (NIFI-13329) Fallback to raw viewer when formatted viewer fails



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

Matt Gilman edited comment on NIFI-13329 at 5/31/24 4:55 PM:
-

So the error is happening while the data viewer is consuming the stream. Once 
this fails, subsequent attempts to re-read the stream fail. The stream is 
either accessing the flowfile from the content repo or consuming an http 
response in clustered mode. To be able to reread the http response, we'd need 
to hold the arbitrarily large content and is a bigger effort.

Would it make sense for this case to render an error message stating that the 
content does not match the mime type? Or there was an error in processing the 
content in formatted mode? The UI would render correctly and show Formatted 
mode with the message. The user could then change the mode to Original or Hex 
to see those views. It addresses the error page your seeing above. And I think 
this case is more uncommon. Defaulting to Formatted and having to manually 
change to Original when the content in the flowfile is wrong is less annoying 
for the user than defaulting to Original and having to manually change to 
Formatted when the content in the flowfile is correct.

We could consider alternative behaviors in the future as replacement of these 
data viewers is on the roadmap to continue modernizing the UIs.


was (Author: mcgilman):
So the error is happening while the data viewer is consuming the stream. Once 
this fails, subsequent attempts to re-read the stream fail. The stream is 
either accessing the flowfile from the content repo or consuming an http 
response in clustered mode. To be able to reread the http response, we'd need 
to hold the arbitrarily large content and is a bigger effort.

Would be make sense for this case to render an error message stating that the 
content does not match the mime type? Or there was an error in processing the 
content in formatted mode? The UI would render correctly and show Formatted 
mode with the message. The user could then change the mode to Original or Hex 
to see those views. It addresses the error page your seeing above. And I think 
this case is more uncommon. Defaulting to Formatted and having to manually 
change to Original when the content in the flowfile is wrong is less annoying 
for the user than defaulting to Original and having to manually change to 
Formatted when the content in the flowfile is correct.

We could consider alternative behaviors in the future as replacement of these 
data viewers is on the roadmap to continue modernizing the UIs.

> Fallback to raw viewer when formatted viewer fails
> --
>
> Key: NIFI-13329
> URL: https://issues.apache.org/jira/browse/NIFI-13329
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Pierre Villard
>Priority: Major
> Attachments: Screenshot 2024-05-30 at 11.19.23.png
>
>
> The formatted viewer (based on the mime.type attribute) recently became the 
> default. In case the MIME type is wrong, this would return an error when 
> opening the flowfile's content. It could be nice to catch the error and 
> fallback to the raw viewer.
> !Screenshot 2024-05-30 at 11.19.23.png|width=611,height=150!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (NIFI-13329) Fallback to raw viewer when formatted viewer fails



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

Matt Gilman commented on NIFI-13329:


So the error is happening while the data viewer is consuming the stream. Once 
this fails, subsequent attempts to re-read the stream fail. The stream is 
either accessing the flowfile from the content repo or consuming an http 
response in clustered mode. To be able to reread the http response, we'd need 
to hold the arbitrarily large content and is a bigger effort.

Would be make sense for this case to render an error message stating that the 
content does not match the mime type? Or there was an error in processing the 
content in formatted mode? The UI would render correctly and show Formatted 
mode with the message. The user could then change the mode to Original or Hex 
to see those views. It addresses the error page your seeing above. And I think 
this case is more uncommon. Defaulting to Formatted and having to manually 
change to Original when the content in the flowfile is wrong is less annoying 
for the user than defaulting to Original and having to manually change to 
Formatted when the content in the flowfile is correct.

We could consider alternative behaviors in the future as replacement of these 
data viewers is on the roadmap to continue modernizing the UIs.

> Fallback to raw viewer when formatted viewer fails
> --
>
> Key: NIFI-13329
> URL: https://issues.apache.org/jira/browse/NIFI-13329
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Pierre Villard
>Priority: Major
> Attachments: Screenshot 2024-05-30 at 11.19.23.png
>
>
> The formatted viewer (based on the mime.type attribute) recently became the 
> default. In case the MIME type is wrong, this would return an error when 
> opening the flowfile's content. It could be nice to catch the error and 
> fallback to the raw viewer.
> !Screenshot 2024-05-30 at 11.19.23.png|width=611,height=150!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PR] NIFI-13138 - Add extensions name and description in NiFi Registry [nifi]



exceptionfactory commented on PR #8740:
URL: https://github.com/apache/nifi/pull/8740#issuecomment-2142562013

   > @exceptionfactory - I will update this PR to also include Parameter 
Providers and Flow Analysis Rules. Is there something else you'd expect to see 
here?
   
   Thanks @pvillard31, I was planning on circling back to this, so if you can 
add those items, I think it should be ready to merge.


-- 
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] [Commented] (NIFI-13329) Fallback to raw viewer when formatted viewer fails



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

Pierre Villard commented on NIFI-13329:
---

Agree that it'd be an improvement. Thanks for looking into it Matt.

> Fallback to raw viewer when formatted viewer fails
> --
>
> Key: NIFI-13329
> URL: https://issues.apache.org/jira/browse/NIFI-13329
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Pierre Villard
>Priority: Major
> Attachments: Screenshot 2024-05-30 at 11.19.23.png
>
>
> The formatted viewer (based on the mime.type attribute) recently became the 
> default. In case the MIME type is wrong, this would return an error when 
> opening the flowfile's content. It could be nice to catch the error and 
> fallback to the raw viewer.
> !Screenshot 2024-05-30 at 11.19.23.png|width=611,height=150!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (NIFI-13329) Fallback to raw viewer when formatted viewer fails



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

Matt Gilman commented on NIFI-13329:


Thanks for clarifying. I wasn't reproducing correctly. I thought the mime type 
in the attribute was wrong. In this case the attribute was correct but the 
content was not of that type.

So in NiFi the attribute value drives which data viewer is used. In this case, 
it matched. The error that is happening is a function of this data viewer. The 
data viewer that handles JSON does not have explicit error handling for this 
case which is resulting in the error in your screenshot. This behavior also 
happened before Formatted was made the default. Previously, it required the 
user to select Formatted first. The downside currently, is that the user never 
gets the UI where they can attempt to change the mode.

The client/browser drives which mode we're in. We may be able to update this 
data viewer to catch the errors and instead return the content in its original 
form. But the UI would likely still reflect Formatted mode. The data viewers 
are actually multiple JSPs included together (header, content, footer). I don't 
think an error or change in the mode happening in the content can impact the 
header but I'll need to investigate. It's possible that even if we can't update 
the selected mode, it would be an improvement over what's happening here.

> Fallback to raw viewer when formatted viewer fails
> --
>
> Key: NIFI-13329
> URL: https://issues.apache.org/jira/browse/NIFI-13329
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Pierre Villard
>Priority: Major
> Attachments: Screenshot 2024-05-30 at 11.19.23.png
>
>
> The formatted viewer (based on the mime.type attribute) recently became the 
> default. In case the MIME type is wrong, this would return an error when 
> opening the flowfile's content. It could be nice to catch the error and 
> fallback to the raw viewer.
> !Screenshot 2024-05-30 at 11.19.23.png|width=611,height=150!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PR] NIFI-13138 - Add extensions name and description in NiFi Registry [nifi]



pvillard31 commented on PR #8740:
URL: https://github.com/apache/nifi/pull/8740#issuecomment-2142525123

   @exceptionfactory - I will update this PR to also include Parameter 
Providers and Flow Analysis Rules. Is there something else you'd expect to see 
here?


-- 
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] [Commented] (NIFI-13329) Fallback to raw viewer when formatted viewer fails



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

Pierre Villard commented on NIFI-13329:
---

Just built latest and getting the same (legacy and new UI). You can reproduce 
with GFF to funnel. GFF configured with 'custom text' = 'Hi', and 'MIME type' = 
'application/json', then Run Once, then list flow files in connection and show 
content of the flow file.

> Fallback to raw viewer when formatted viewer fails
> --
>
> Key: NIFI-13329
> URL: https://issues.apache.org/jira/browse/NIFI-13329
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Pierre Villard
>Priority: Major
> Attachments: Screenshot 2024-05-30 at 11.19.23.png
>
>
> The formatted viewer (based on the mime.type attribute) recently became the 
> default. In case the MIME type is wrong, this would return an error when 
> opening the flowfile's content. It could be nice to catch the error and 
> fallback to the raw viewer.
> !Screenshot 2024-05-30 at 11.19.23.png|width=611,height=150!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (NIFI-13335) XMLReader drops values from name-value content if values are mixture of strings and numbers

Stephen Jeffrey Hindmarch created NIFI-13335:


 Summary: XMLReader drops values from name-value content if values 
are mixture of strings and numbers
 Key: NIFI-13335
 URL: https://issues.apache.org/jira/browse/NIFI-13335
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework
Affects Versions: 1.24.0
 Environment: Docker
Reporter: Stephen Jeffrey Hindmarch


This is similar to NIFI-13334, but does not require an array of records to 
demonstrate.

If you create an XMLReader service and set the following:
 * Parse XML Attributes = false
 * Expect Records as Arrays = true
 * Field Name for Content = Value

Then use the reader in a ConvertRecord processor with a JSONRecordSetWriter

When parsing a flow file such as
{noformat}

  
    0x0001
  
  
    String1
    String2
    String3
  
{noformat}
then the data tags all get parsed with the correct values.
{noformat}
[ {
  "Type" : "foo",
  "System" : {
    "EventID" : "0x0001"
  },
  "UserData" : {
    "Data" : [ {
        "Name" : "Param1",
        "Value" : "String1"
    }, {
        "Name" : "Param2",
        "Value" : "String2"
    }, {
        "Name" : "Param3",
        "Value" : "String3"
    } ]
  }
} ]{noformat}
But if one of those data tags has a numeric value then all of the values are 
dropped and are replaced with null. For example
{noformat}

  
    0x0001
  
  
    String1
    2
    String3
  

{noformat}
parses to
{noformat}
[ {
  "Type" : "foo",
  "System" : {
    "EventID" : "0x0001"
  },
  "UserData" : {
    "Data" : [ {
        "Name" : "Param1",
        "Value" : null
    }, {
        "Name" : "Param2",
        "Value" : null
    }, {
        "Name" : "Param3",
        "Value" : null
    } ]
  }
} ]{noformat}
and all of the tag data is lost.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (NIFI-13334) XMLReader drops name-value content tags from record arrays if one record has only one tag

Stephen Jeffrey Hindmarch created NIFI-13334:


 Summary: XMLReader drops name-value content tags from record 
arrays if one record has only one tag
 Key: NIFI-13334
 URL: https://issues.apache.org/jira/browse/NIFI-13334
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core UI
Affects Versions: 1.24.0
 Environment: Docker
Reporter: Stephen Jeffrey Hindmarch


If you create an XMLReader service and set the following:
 * Parse XML Attributes = true
 * Expect Records as Arrays = true
 * Field Name for Content = Value

Then use the reader in a ConvertRecord processor with a JSONRecordSetWriter

When parsing a flow file such as
{noformat}

  
    
      String1
      String2
    
  
  
    
      String
      String2
      String3
    
  
{noformat}
Then as expected the content tags are parsed into arrays
{noformat}
[ {
  "Type" : "foo",
  "UserData" : {
    "Data" : [ {
      "Name" : "Param1",
      "Value" : "String1"
    }, {
      "Name" : "Param2",
      "Value" : "String2"
    } ]
  }
}, {
  "Type" : "bar",
  "UserData" : {
    "Data" : [ {
      "Name" : "Param1",
      "Value" : "String"
    }, {
      "Name" : "Param2",
      "Value" : "String2"
    }, {
      "Name" : "Param3",
      "Value" : "String3"
    } ]
  }
} ]{noformat}
But if one of the records has only one data tag, then it will not be presented 
in an array, and more importantly, nor will the tags for the other record. 
Instead, all but the last tags are dropped.

For example
{noformat}

  
    
      String1
    
  
  
    
      String
      String2
      String3
    
  
{noformat}
parses to
{noformat}
[ {
  "Type" : "foo",
  "UserData" : {
    "Data" : {
      "Name" : "Param1",
      "Value" : "String1"
    }
  }
}, {
  "Type" : "bar",
  "UserData" : {
    "Data" : {
      "Name" : "Param3",
      "Value" : "String3"
    }
  }
} ]{noformat}
Note that the second event has lost all but the last of its data content tags.

It does not matter which event (first or second) has 1 tag, the other event 
loses content.

 

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (NIFI-13323) For 1.x, Remove the instantiation of Object arrays for arguments in ComponentLog log and org.slf4j.Logger statements



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

Daniel Stieglitz updated NIFI-13323:

Description: This ticket is a follow up of NIFI-13265 which was only able 
to be applied to the 2.x branch. This ticket aims to do the same type of 
changes in the 1.x branch.  (was: This ticket is a follow up in NIFI-13265 
which was only able to be applied to the 2.x branch. This ticket aims to do the 
same type of changes in the 1.x branch.)

> For 1.x, Remove the instantiation of Object arrays for arguments in 
> ComponentLog log and org.slf4j.Logger statements
> 
>
> Key: NIFI-13323
> URL: https://issues.apache.org/jira/browse/NIFI-13323
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.27.0
>Reporter: Daniel Stieglitz
>Assignee: Daniel Stieglitz
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> This ticket is a follow up of NIFI-13265 which was only able to be applied to 
> the 2.x branch. This ticket aims to do the same type of changes in the 1.x 
> branch.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (NIFI-13323) For 1.x, Remove the instantiation of Object arrays for arguments in ComponentLog log and org.slf4j.Logger statements



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

Daniel Stieglitz updated NIFI-13323:

Description: This ticket is a follow up in NIFI-13265 which was only able 
to be applied to the 2.x branch. This ticket aims to do the same type of 
changes in the 1.x branch.

> For 1.x, Remove the instantiation of Object arrays for arguments in 
> ComponentLog log and org.slf4j.Logger statements
> 
>
> Key: NIFI-13323
> URL: https://issues.apache.org/jira/browse/NIFI-13323
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.27.0
>Reporter: Daniel Stieglitz
>Assignee: Daniel Stieglitz
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> This ticket is a follow up in NIFI-13265 which was only able to be applied to 
> the 2.x branch. This ticket aims to do the same type of changes in the 1.x 
> branch.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (NIFI-13323) For 1.x, Remove the instantiation of Object arrays for arguments in ComponentLog log and org.slf4j.Logger statements

2024-05-31 Thread ASF subversion and git services (Jira)



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

Daniel Stieglitz updated NIFI-13323:

Priority: Major  (was: Minor)
 Summary: For 1.x, Remove the instantiation of Object arrays for arguments 
in ComponentLog log and org.slf4j.Logger statements  (was: Remove the 
instantiation of Object arrays for arguments in ComponentLog log in the 
HashAttribute and PostHttp Processors)

> For 1.x, Remove the instantiation of Object arrays for arguments in 
> ComponentLog log and org.slf4j.Logger statements
> 
>
> Key: NIFI-13323
> URL: https://issues.apache.org/jira/browse/NIFI-13323
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.27.0
>Reporter: Daniel Stieglitz
>Assignee: Daniel Stieglitz
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (NIFI-13267) Bump NiFi NAR Maven plugin version

2024-05-31 Thread Bryan Bende (Jira)



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

Bryan Bende updated NIFI-13267:
---
Fix Version/s: 2.0.0-M4
   Resolution: Fixed
   Status: Resolved  (was: Patch Available)

> Bump NiFi NAR Maven plugin version
> --
>
> Key: NIFI-13267
> URL: https://issues.apache.org/jira/browse/NIFI-13267
> Project: Apache NiFi
>  Issue Type: Task
>Reporter: Pierre Villard
>Assignee: Pierre Villard
>Priority: Major
> Fix For: 2.0.0-M4
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Once we have a new version of the NiFi NAR Maven Plugin, we'll need to bump 
> the version in the NiFi code base and make some changes to account for the 
> new extension types (Parameter Providers and Flow Analysis Rules).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (NIFI-13267) Bump NiFi NAR Maven plugin version



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

ASF subversion and git services commented on NIFI-13267:


Commit 9606102c49af70dd140aa5027dec45ae4c9f18bb in nifi's branch 
refs/heads/main from Pierre Villard
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=9606102c49 ]

NIFI-13267 - Bump NiFi NAR Maven plugin version (#8860)

* NIFI-13267 - Bump NiFi NAR Maven plugin version
* Review - adding Parameter Providers and Flow Analaysis Rules in 
c2-protocol-component-api ComponentManifest
* Review - fix build() of ComponentManifest

> Bump NiFi NAR Maven plugin version
> --
>
> Key: NIFI-13267
> URL: https://issues.apache.org/jira/browse/NIFI-13267
> Project: Apache NiFi
>  Issue Type: Task
>Reporter: Pierre Villard
>Assignee: Pierre Villard
>Priority: Major
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Once we have a new version of the NiFi NAR Maven Plugin, we'll need to bump 
> the version in the NiFi code base and make some changes to account for the 
> new extension types (Parameter Providers and Flow Analysis Rules).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PR] NIFI-13267 - Bump NiFi NAR Maven plugin version [nifi]



bbende merged PR #8860:
URL: https://github.com/apache/nifi/pull/8860


-- 
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] [Created] (NIFI-13333) ParseEVTX Processor does not pass failed flow files to failure relationship

Stephen Jeffrey Hindmarch created NIFI-1:


 Summary: ParseEVTX Processor does not pass failed flow files to 
failure relationship
 Key: NIFI-1
 URL: https://issues.apache.org/jira/browse/NIFI-1
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework
Affects Versions: 1.24.0
 Environment: Docker
Reporter: Stephen Jeffrey Hindmarch


As noted in NIFI-13332, when the ParseEVTX fails to parse a file, eg if the 
file has the wrong minor version, the flow file is not passed to the failure 
relationship, but instead remains on the incoming relationship with a penalty 
and is repeatedly parsed.

This seems like a poor behaviour choice, as there is nothing that is going to 
change about that incoming file that will allow it to be parsed.

For example, generate a test flow with some simple text content, eg 
{code:java}
Not an EVTX File{code}
Then send this to a ParseEVTX processor. The parser will keep penalising the 
flow file and keep it on the incoming queue with this error message.
{noformat}
ParseEvtx[id=c5eadd74-56b2-3763-b7d0-1274b905ce06] Processing failed: 
org.apache.nifi.processor.exception.ProcessException: IOException thrown from 
ParseEvtx[id=c5eadd74-56b2-3763-b7d0-1274b905ce06]: java.io.IOException: 
Expected null terminated string
- Caused by: java.io.IOException: Expected null terminated string{noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (NIFI-13329) Fallback to raw viewer when formatted viewer fails



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

Matt Gilman updated NIFI-13329:
---
Parent: (was: NIFI-12400)
Issue Type: Bug  (was: Sub-task)

> Fallback to raw viewer when formatted viewer fails
> --
>
> Key: NIFI-13329
> URL: https://issues.apache.org/jira/browse/NIFI-13329
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Pierre Villard
>Priority: Major
> Attachments: Screenshot 2024-05-30 at 11.19.23.png
>
>
> The formatted viewer (based on the mime.type attribute) recently became the 
> default. In case the MIME type is wrong, this would return an error when 
> opening the flowfile's content. It could be nice to catch the error and 
> fallback to the raw viewer.
> !Screenshot 2024-05-30 at 11.19.23.png|width=611,height=150!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (NIFI-13329) Fallback to raw viewer when formatted viewer fails



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

Pierre Villard commented on NIFI-13329:
---

Hey [~mcgilman] - I'll retry with latest on main because last time I built was 
probably a couple of weeks ago.

I'm trying to open a flow file content for which mime.type is application/json 
but the content is not JSON. I get the below stacktrace:
{code:java}
2024-05-31 15:31:44,682 ERROR [NiFi Web Server-457] 
o.a.nifi.web.ContentViewerController Content preparation failed for Content 
Viewer [/nifi-standard-content-viewer-2.0.0-SNAPSHOT]
com.fasterxml.jackson.core.JsonParseException: Unrecognized token 'Hi': was 
expecting (JSON String, Number, Array, Object or token 'null', 'true' or 
'false')
 at [Source: REDACTED (`StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION` 
disabled); line: 1, column: 4]
at 
com.fasterxml.jackson.core.JsonParser._constructError(JsonParser.java:2567)
at 
com.fasterxml.jackson.core.JsonParser._constructReadException(JsonParser.java:2593)
at 
com.fasterxml.jackson.core.JsonParser._constructReadException(JsonParser.java:2601)
at 
com.fasterxml.jackson.core.base.ParserMinimalBase._reportError(ParserMinimalBase.java:765)
at 
com.fasterxml.jackson.core.json.UTF8StreamJsonParser._reportInvalidToken(UTF8StreamJsonParser.java:3659)
at 
com.fasterxml.jackson.core.json.UTF8StreamJsonParser._handleUnexpectedValue(UTF8StreamJsonParser.java:2747)
at 
com.fasterxml.jackson.core.json.UTF8StreamJsonParser._nextTokenNotInObject(UTF8StreamJsonParser.java:867)
at 
com.fasterxml.jackson.core.json.UTF8StreamJsonParser.nextToken(UTF8StreamJsonParser.java:753)
at 
com.fasterxml.jackson.databind.ObjectMapper._initForReading(ObjectMapper.java:4992)
at 
com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:4898)
at 
com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3885)
at 
org.apache.nifi.web.StandardContentViewerController.doGet(StandardContentViewerController.java:90)
at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:527)
at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:614)
at 
org.eclipse.jetty.ee10.servlet.ServletHolder$NotAsync.service(ServletHolder.java:1379)
at 
org.eclipse.jetty.ee10.servlet.ServletHolder.handle(ServletHolder.java:736)
at 
org.eclipse.jetty.ee10.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1614)
at 
org.springframework.security.web.FilterChainProxy.lambda$doFilterInternal$3(FilterChainProxy.java:231)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:365)
at 
org.springframework.security.web.access.intercept.AuthorizationFilter.doFilter(AuthorizationFilter.java:100)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374)
at 
org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:126)
at 
org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:120)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374)
at 
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:110)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374)
at 
org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:100)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374)
at 
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:110)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374)
at 
org.apache.nifi.web.security.NiFiAuthenticationFilter.doFilter(NiFiAuthenticationFilter.java:58)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374)
at 
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:110)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374)
at 
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:110)
at 
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374)
at 
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:110)
at 
org.springframework.security.web.FilterC

Re: [PR] NIFI-13231 Added Private key authentication for GitHubFlowRegistryClient [nifi]



maybevanshh commented on PR #8890:
URL: https://github.com/apache/nifi/pull/8890#issuecomment-2142166337

   For some reason JwtTokenProvider throws Bad Credentials , can you please 
check into it?


-- 
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] [Commented] (NIFI-13329) Fallback to raw viewer when formatted viewer fails



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

Matt Gilman commented on NIFI-13329:


[~pvillard] Can you provide some more details? I just tried to reproduce this 
and I am seeing different behavior. Also are you seeing any errors in any of 
the logs? Thanks.

> Fallback to raw viewer when formatted viewer fails
> --
>
> Key: NIFI-13329
> URL: https://issues.apache.org/jira/browse/NIFI-13329
> Project: Apache NiFi
>  Issue Type: Sub-task
>Reporter: Pierre Villard
>Priority: Major
> Attachments: Screenshot 2024-05-30 at 11.19.23.png
>
>
> The formatted viewer (based on the mime.type attribute) recently became the 
> default. In case the MIME type is wrong, this would return an error when 
> opening the flowfile's content. It could be nice to catch the error and 
> fallback to the raw viewer.
> !Screenshot 2024-05-30 at 11.19.23.png|width=611,height=150!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (NIFI-13332) NiFi ParseEVTX processor should support EVTX format version 3.2

Stephen Jeffrey Hindmarch created NIFI-13332:

Summary: NiFi ParseEVTX processor should support EVTX format
version 3.2
Key: NIFI-13332
URL: https://issues.apache.org/jira/browse/NIFI-13332
Project: Apache NiFi
Issue Type: Improvement
Components: Core Framework
Affects Versions: 1.24.0
Environment: Docker
Reporter: Stephen Jeffrey Hindmarch

>From Windows 10 onwards the format for EVTX (compressed windows event logs)
>has been changed from version 3.1 to 3.2.

The ParseEVTX processor in NiFi parses these files to turn them into sets of
windows event logs in XML. However, EVTX logs extracted from a Windows 10
laptop will cause the processor to fail with this message.
{noformat}
ParseEvtx[id=c5eadd74-56b2-3763-b7d0-1274b905ce06] Processing failed:
org.apache.nifi.processor.exception.ProcessException: IOException thrown from
ParseEvtx[id=c5eadd74-56b2-3763-b7d0-1274b905ce06]: java.io.IOException:
Invalid minor version. Expected 1 got 2.
- Caused by: java.io.IOException: Invalid minor version. Expected 1 got
2.{noformat}
Also, the incoming flow file is stuck in the input queue instead of being
transferred to the failure queue.

As Windows 10 and 11 use this format, and I suspect Windows Server 2022 does
too, then this EVTX 3.2 will be quite mainstream soon and NiFi should support
it.

See [GitHub Project
libevtx|https://github.com/libyal/libevtx/blob/main/documentation/Windows%20XML%20Event%20Log%20(EVTX).asciidoc]
for more detailed information.

--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (NIFI-13331) Make tables more compact



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

Matt Gilman edited comment on NIFI-13331 at 5/31/24 1:13 PM:
-

In the new UI we are using the Angular Material. Their APIs allow the density 
of the table to be configured. We are currently using the densest option.
{noformat}
@include mat.table-density(-4);{noformat}
Material design is definitely less compact than the old NiFi UI. We could 
consider not using their API and instead overriding some of their styles. 
However, that may introduce upgrade challenges down the road as their is no 
guarantee those styles or the generated mark up remains the same from release 
to release. Because we opted to use Material design we probably shouldn't try 
to introduce changes that diverge from it.

Another option we could consider is building a custom table component or 
bringing in a separate dependency for it but each of those options have own 
consequences.


was (Author: mcgilman):
In the new UI we are using the Angular Material. Their APIs allow the density 
of the table to be configured. We are currently using the densest option.
{noformat}
@include mat.table-density(-4);{noformat}
Material design is definitely less compact than the old NiFi UI. We could 
consider not using their API and instead overriding some of their styles. 
However, that may introduce upgrade challenges down the road as their is no 
guarantee those styles or the generated mark up remains the same from release 
to release. We could also consider building a custom table component or 
bringing in a separate dependency for it but that what would be a big effort.

> Make tables more compact
> 
>
> Key: NIFI-13331
> URL: https://issues.apache.org/jira/browse/NIFI-13331
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Matt Gilman
>Priority: Major
>
> The rows in the tables in the old UI were more compact than the new UI. We 
> should consider options for making the tables in the new UI more dense.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (NIFI-13331) Make tables more compact



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

Matt Gilman commented on NIFI-13331:


In the new UI we are using the Angular Material. Their APIs allow the density 
of the table to be configured. We are currently using the densest option.
{noformat}
@include mat.table-density(-4);{noformat}
Material design is definitely less compact than the old NiFi UI. We could 
consider not using their API and instead overriding some of their styles. 
However, that may introduce upgrade challenges down the road as their is no 
guarantee those styles or the generated mark up remains the same from release 
to release. We could also consider building a custom table component or 
bringing in a separate dependency for it but that what would be a big effort.

> Make tables more compact
> 
>
> Key: NIFI-13331
> URL: https://issues.apache.org/jira/browse/NIFI-13331
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Matt Gilman
>Priority: Major
>
> The rows in the tables in the old UI were more compact than the new UI. We 
> should consider options for making the tables in the new UI more dense.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (NIFI-13331) Make table more compact

Matt Gilman created NIFI-13331:
--

 Summary: Make table more compact
 Key: NIFI-13331
 URL: https://issues.apache.org/jira/browse/NIFI-13331
 Project: Apache NiFi
  Issue Type: Sub-task
  Components: Core UI
Reporter: Matt Gilman


The rows in the tables in the old UI were more compact than the new UI. We 
should consider options for making the tables in the new UI more dense.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (NIFI-13331) Make tables more compact



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

Matt Gilman updated NIFI-13331:
---
Summary: Make tables more compact  (was: Make table more compact)

> Make tables more compact
> 
>
> Key: NIFI-13331
> URL: https://issues.apache.org/jira/browse/NIFI-13331
> Project: Apache NiFi
>  Issue Type: Sub-task
>  Components: Core UI
>Reporter: Matt Gilman
>Priority: Major
>
> The rows in the tables in the old UI were more compact than the new UI. We 
> should consider options for making the tables in the new UI more dense.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PR] NIFI-13267 - Bump NiFi NAR Maven plugin version [nifi]



pvillard31 commented on code in PR #8860:
URL: https://github.com/apache/nifi/pull/8860#discussion_r1622376427


##
nifi-manifest/nifi-runtime-manifest-core/src/main/java/org/apache/nifi/runtime/manifest/impl/StandardComponentManifestBuilder.java:
##
@@ -61,6 +65,24 @@ public ComponentManifestBuilder addReportingTask(final 
ReportingTaskDefinition r
 return this;
 }
 
+@Override
+public ComponentManifestBuilder 
addParameterProvider(ParameterProviderDefinition parameterProviderDefinition) {
+if (parameterProviderDefinition == null) {
+throw new IllegalArgumentException("Parameter Provider definition 
cannot be null");
+}
+parameterProviders.add(parameterProviderDefinition);
+return this;
+}
+
+@Override
+public ComponentManifestBuilder 
addFlowAnalysisRule(FlowAnalysisRuleDefinition flowAnalysisRuleDefinition) {
+if (flowAnalysisRuleDefinition == null) {
+throw new IllegalArgumentException("Flow Analysis Rule definition 
cannot be null");
+}
+flowAnalysisRules.add(flowAnalysisRuleDefinition);
+return this;
+}
+

Review Comment:
   Good catch, done, thanks @bbende 



-- 
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-13231 Added Private key authentication for GitHubFlowRegistryClient [nifi]



maybevanshh commented on PR #8890:
URL: https://github.com/apache/nifi/pull/8890#issuecomment-2142028923

   Sure
   Making these changes 


-- 
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-13231 Added Private key authentication for GitHubFlowRegistryClient [nifi]



exceptionfactory commented on code in PR #8890:
URL: https://github.com/apache/nifi/pull/8890#discussion_r1622354948


##
nifi-extension-bundles/nifi-github-bundle/nifi-github-extensions/src/main/java/org/apache/nifi/github/GitHubRepositoryClient.java:
##
@@ -19,7 +19,12 @@
 
 package org.apache.nifi.github;
 
+import io.jsonwebtoken.Jwts;
+import io.jsonwebtoken.SignatureAlgorithm;
 import org.apache.nifi.registry.flow.FlowRegistryException;
+import org.bouncycastle.asn1.pkcs.RSAPrivateKey;
+import org.bouncycastle.openssl.PEMKeyPair;
+import org.bouncycastle.openssl.PEMParser;

Review Comment:
   These imports can be removed.



##
nifi-extension-bundles/nifi-github-bundle/nifi-github-extensions/src/main/java/org/apache/nifi/github/GitHubRepositoryClient.java:
##
@@ -74,6 +81,15 @@ private GitHubRepositoryClient(final Builder builder) throws 
IOException, FlowRe
 switch (authenticationType) {
 case PERSONAL_ACCESS_TOKEN -> 
gitHubBuilder.withOAuthToken(builder.personalAccessToken);
 case APP_INSTALLATION_TOKEN -> 
gitHubBuilder.withAppInstallationToken(builder.appInstallationToken);
+case APP_INSTALLATION_ID_AND_PRIVATE_KEY -> {
+try {
+JWTTokenProvider jwtTokenProvider = new 
JWTTokenProvider(builder().appId, builder().privateKey);
+String token = jwtTokenProvider.getEncodedAuthorization();
+gitHubBuilder.withJwtToken(token);
+} catch (Exception e) {
+throw new FlowRegistryException(e.getMessage());

Review Comment:
   A custom message should be set, and the exception passed to the constructor 
to preserve the stack trace.
   ```suggestion
   throw new FlowRegistryException("Failed to generate JWT 
from App ID and Private Key", e);
   ```



-- 
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-13328) WindowsEventLogReader should parse RenderingInfo



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

Stephen Jeffrey Hindmarch updated NIFI-13328:
-
Summary: WindowsEventLogReader should parse RenderingInfo  (was: 
WindowsEventLogRecordReader should parse RenderingInfo)

> WindowsEventLogReader should parse RenderingInfo
> 
>
> Key: NIFI-13328
> URL: https://issues.apache.org/jira/browse/NIFI-13328
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 1.24.0
> Environment: Docker
>Reporter: Stephen Jeffrey Hindmarch
>Priority: Major
>
> If windows events are extracted from the windows event collector they will 
> include a "RenderingInfo" tag. However, this tag is not expected by the 
> WindowsEventLogReader and will throw an error and pass the flow file into the 
> failure relationship if the event contains the tag. This tag should be 
> supported as it is a legitimate part of the Windows Event XML schema.
> See 
> [https://learn.microsoft.com/en-us/windows/win32/wes/eventschema-renderingtype-complextype]
>  and 
> [https://learn.microsoft.com/en-us/windows/win32/wec/windows-event-collector] 
> . In this particular use case, events are being collected from field 
> technicians' laptops to perform a cybersecurity audit after they have 
> plugging their laptops into customer networks.
> When these events are processed through a WindowsEventLogReader, the reader 
> throws the following error.
> {noformat}
> ConvertRecord[id=7b99392f-2b54-139e-8791-349e930904cd] Failed to process 
> FlowFile[filename=ffca2ea2-edd5-4ad1-8380-2bc4c8dae1ac]; will route to 
> failure: org.apache.nifi.processor.exception.ProcessException: Could not 
> parse incoming data
> - Caused by: org.apache.nifi.serialization.MalformedRecordException: Error 
> reading records to determine the FlowFile's RecordSchema
> - Caused by: javax.xml.stream.XMLStreamException: Expecting  tag but 
> found unknown/invalid tag RenderingInfo{noformat}
> An example of the event record might be
> {noformat}
> https://schemas.microsoft.com/win/2004/08/events/event";>
>   
>      Guid="{555908d1-a6d7-4695-8e1e-26931d2012f4}" EventSourceName="Service 
> Control Manager"/>
>     7036
>     0
>     4
>     0
>     0
>     0x8080
>     
>     34153
>     
>     
>     System
>     WIN-O05CNUCF16M.hdf.local
>     
>   
>   
>     Smart Card Device Enumeration Service
>     param2
>     
> 5300630044006500760069006300650045006E0075006D002F003400
>   
>   
>     This is a message
>   
> {noformat}
> Removing the tag allows the event to be processed as normal.
> One possible workaround is to use a ReplaceText processor to remove the tag 
> before reading, but this then involves either discarding the tag contents, or 
> using an enrichment fork to find some other way of processing it. Another 
> workaround is to use the XMLReader service, but this is a generic parser and 
> has a its own problems.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (NIFI-13330) WindowsEventLogReader fails with NPE if data tag is empty

Stephen Jeffrey Hindmarch created NIFI-13330:


 Summary: WindowsEventLogReader fails with NPE if data tag is empty
 Key: NIFI-13330
 URL: https://issues.apache.org/jira/browse/NIFI-13330
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework
Affects Versions: 1.24.0
 Environment: Docker
Reporter: Stephen Jeffrey Hindmarch


If a windows event contains an empty data tag then the WindowsEventLogReader 
will fail with a Null Pointer Exception instead of treating it as a null field. 
If the tag contains the word null then this gets treated as string.

For example, parsing this
{noformat}
https://schemas.microsoft.com/win/2004/08/events/event";>
  
    
    7036
    0
    4
    0
    0
    0x8080
    
    34153
    
    
    System
    WIN-O05CNUCF16M.hdf.local
    
  
  
    Smart Card Device Enumeration Service
    
    
    
  
{noformat}
Results in the error
{noformat}
ConvertRecord[id=7b99392f-2b54-139e-8791-349e930904cd] Failed to process 
FlowFile[filename=cdd10be3-9364-4458-bb89-69988b3e7a60]; will route to failure: 
java.lang.NullPointerException{noformat}
And this (partial) stack trace.
{noformat}
2024-05-31 12:55:15 2024-05-31 11:55:15,722 ERROR [Timer-Driven Process 
Thread-5] o.a.n.processors.standard.ConvertRecord 
ConvertRecord[id=7b99392f-2b54-139e-8791-349e930904cd] Failed to process 
StandardFlowFileRecord[uuid=cdd10be3-9364-4458-bb89-69988b3e7a60,claim=StandardContentClaim
 [resourceClaim=StandardResourceClaim[id=1717153302525-1, container=default, 
section=1], offset=6510, 
length=880],offset=0,name=cdd10be3-9364-4458-bb89-69988b3e7a60,size=880]; will 
route to failure
2024-05-31 12:55:15 java.lang.NullPointerException: null
2024-05-31 12:55:15     at java.base/java.util.Objects.requireNonNull(Unknown 
Source)
2024-05-31 12:55:15     at 
org.apache.nifi.serialization.record.RecordField.(RecordField.java:70)
2024-05-31 12:55:15     at 
org.apache.nifi.serialization.record.RecordField.(RecordField.java:40)
2024-05-31 12:55:15     at 
org.apache.nifi.windowsevent.WindowsEventLogRecordReader.getDataFieldsFrom(WindowsEventLogRecordReader.java:292){noformat}
What is expected is that the empty data fields should be parsed as null, for 
example
{noformat}
[ {
  "System" : {
    "Provider" : {
      "Guid" : "{555908d1-a6d7-4695-8e1e-26931d2012f4}",
      "Name" : "Service Control Manager"
    },
    "EventID" : 7036,
    "Version" : 0,
    "Level" : 4,
    "Task" : 0,
    "Opcode" : 0,
    "Keywords" : "0x8080",
    "TimeCreated" : {
      "SystemTime" : "2016-06-10T22:28:53.905233700Z"
    },
    "EventRecordID" : 34153,
    "Correlation" : null,
    "Execution" : {
      "ThreadID" : 3504,
      "ProcessID" : 684
    },
    "Channel" : "System",
    "Computer" : "WIN-O05CNUCF16M.hdf.local",
    "Security" : null
  },
  "EventData" : {
    "param1" : "Smart Card Device Enumeration Service",
    "CertIssuer" : null,
    "CertSignature": null,
"CertExpiryDate": null
} ]{noformat}
A workaround is to use ReplaceText to replace any empty tags and either delete 
them or insert a string value such as "null" or "-" which can be handled later 
on by JSON readers.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PR] NIFI-13231 Added Private key authentication for GitHubFlowRegistryClient [nifi]



maybevanshh commented on code in PR #8890:
URL: https://github.com/apache/nifi/pull/8890#discussion_r1622321295


##
nifi-extension-bundles/nifi-github-bundle/nifi-github-extensions/src/main/java/org/apache/nifi/github/GitHubRepositoryClient.java:
##
@@ -379,6 +392,41 @@ public GHContent deleteContent(final String filePath, 
final String commitMessage
 });
 }
 
+/**
+ * Creates the JwtToken for Authentication with Private Key
+ *
+ * @param pemString is the PKCS#1 String
+ * @return the JwtToken
+ *
+ * @throws Exception if an error occurs parsing key
+ */
+private static String loadPrivateKeyFromPEM(String pemString) throws 
Exception {
+long nowMillis = System.currentTimeMillis();
+long expMillis = nowMillis + 60; // Token validity 10 minutes
+Date now = new Date(nowMillis);
+Date exp = new Date(expMillis);
+PEMParser pemParser = new PEMParser(new StringReader(pemString));
+Object object = pemParser.readObject();
+pemParser.close();
+
+if (object instanceof PEMKeyPair) {
+PEMKeyPair keyPair = (PEMKeyPair) object;
+RSAPrivateKey rsaPrivateKey = 
RSAPrivateKey.getInstance(keyPair.getPrivateKeyInfo().parsePrivateKey());
+PKCS8EncodedKeySpec keySpec = new 
PKCS8EncodedKeySpec(rsaPrivateKey.getEncoded());

Review Comment:
   I removed the seperate function for jwt and used JWTTokenProvider for token 
generation.



-- 
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] [Created] (NIFI-13329) Fallback to raw viewer when formatted viewer fails

2024-05-31 Thread ASF subversion and git services (Jira)

Pierre Villard created NIFI-13329:
-

 Summary: Fallback to raw viewer when formatted viewer fails
 Key: NIFI-13329
 URL: https://issues.apache.org/jira/browse/NIFI-13329
 Project: Apache NiFi
  Issue Type: Sub-task
Reporter: Pierre Villard
 Attachments: Screenshot 2024-05-30 at 11.19.23.png

The formatted viewer (based on the mime.type attribute) recently became the 
default. In case the MIME type is wrong, this would return an error when 
opening the flowfile's content. It could be nice to catch the error and 
fallback to the raw viewer.

!Screenshot 2024-05-30 at 11.19.23.png|width=611,height=150!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (NIFI-13320) Upgrade Spring Boot to 3.3.0



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

ASF subversion and git services commented on NIFI-13320:


Commit 6c8cc2dd3a9a74ee134fc3d620eba6c6466a6891 in nifi's branch 
refs/heads/main from David Handermann
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=6c8cc2dd3a ]

NIFI-13320 Upgraded Spring Boot from 3.2.6 to 3.3.0

Signed-off-by: Pierre Villard 

This closes #8899.


> Upgrade Spring Boot to 3.3.0
> 
>
> Key: NIFI-13320
> URL: https://issues.apache.org/jira/browse/NIFI-13320
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: NiFi Registry
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Spring Boot dependencies for NiFi Registry should be upgraded to 
> [3.3.0|https://github.com/spring-projects/spring-boot/releases/tag/v3.3.0] to 
> incorporate the latest set of improvements and dependency upgrades. The 3.3.0 
> release provides the latest maintained version beyond the 3.2 series.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (NIFI-13320) Upgrade Spring Boot to 3.3.0



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

Pierre Villard updated NIFI-13320:
--
Fix Version/s: 2.0.0-M4
   Resolution: Fixed
   Status: Resolved  (was: Patch Available)

> Upgrade Spring Boot to 3.3.0
> 
>
> Key: NIFI-13320
> URL: https://issues.apache.org/jira/browse/NIFI-13320
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: NiFi Registry
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
> Fix For: 2.0.0-M4
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Spring Boot dependencies for NiFi Registry should be upgraded to 
> [3.3.0|https://github.com/spring-projects/spring-boot/releases/tag/v3.3.0] to 
> incorporate the latest set of improvements and dependency upgrades. The 3.3.0 
> release provides the latest maintained version beyond the 3.2 series.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PR] NIFI-13320 Upgrade Spring Boot from 3.2.6 to 3.3.0 for Registry [nifi]



asfgit closed pull request #8899: NIFI-13320 Upgrade Spring Boot from 3.2.6 to 
3.3.0 for Registry
URL: https://github.com/apache/nifi/pull/8899


-- 
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] libminifi: Rename mutex_ to mtx_ member of ConcurrentQueue [nifi-minifi-cpp]



martinzink commented on PR #1803:
URL: https://github.com/apache/nifi-minifi-cpp/pull/1803#issuecomment-2141861786

   Thanks for fix 👍 , I've created a Jira so it adhears the the naming rules.
   https://issues.apache.org/jira/browse/MINIFICPP-2391 


-- 
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] [Created] (MINIFICPP-2391) Fix ConcurrentQueue move ctor

2024-05-31 Thread Martin Zink (Jira)

Martin Zink created MINIFICPP-2391:
--

 Summary: Fix ConcurrentQueue move ctor
 Key: MINIFICPP-2391
 URL: https://issues.apache.org/jira/browse/MINIFICPP-2391
 Project: Apache NiFi MiNiFi C++
  Issue Type: Bug
Reporter: Martin Zink


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



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (NIFI-13301) Create ExtensionRegistryClient for External Extension Registry Interaction



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

Pierre Villard commented on NIFI-13301:
---

{quote}Although NiFi Registry has a number of configurable features, it does 
not support clustered deployment for high availability, which would be a vital 
part of such a marketplace.
{quote}
Can you elaborate on this [~exceptionfactory] ? Such a marketplace would likely 
be read-only for the consumers of the artefacts so I don't see why you could 
not have multiple NiFi Registry instances serving the same assets.

As a note, I filed NIFI-13077 which I think could be linked to this one.

> Create ExtensionRegistryClient for External Extension Registry Interaction
> --
>
> Key: NIFI-13301
> URL: https://issues.apache.org/jira/browse/NIFI-13301
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions, NiFi Registry
> Environment: Linux: Ubuntu 20.04 or 22.04
>Reporter: James Guzman (Medel)
>Assignee: James Guzman (Medel)
>Priority: Minor
>
> *Objective:* Improve/enable sharing/reuse of at least two features of Apache 
> NiFi, so the community can have an easier time contributing their flows 
> and/or custom processors into a NiFi Marketplace:
>  * {*}Pre-Designed Flows{*}: (Approach 1) stored in a NiFi Registry or 
> accessible location. (Approach 2) NiFi Registry can also substituted by 
> NiFi's git registry client having the location of the NiFi Marketplace.  
> Thus, we just have a git location and NiFi uses that to find/store flows.
>  * *Components/Processors* built in *Java/Python* that anyone is free to use
>  * *End to End Full Stack Applications Powered By NiFi or MiNiFi CPP?* The 
> frontend could be various ones from PyQT, ReactJS, H2O.ai Wave, 3D Slicer, 
> OHIF Viewer, etc: (Maybe this one can be subscription based where users get 
> access if they invest in the monthly or yearly subscription?)
> *Potential Solution:* Apache NiFi builds an extension point for interacting 
> with Extension Registries, similar to how it currently has 
> *{{FlowRegistryClient}}* with implementations for NiFi Registry and now 
> GitHub, there would be *{{ExtensionRegistryClient}}* with implementations for 
> stuff like Nexus, NiFi Registry, and any other vendor ones, for example maybe 
> Datavolo provides one, but basically in apache we don't want to build another 
> application, we already have NiFi Registry. (Briefly Discussed with [~bbende] 
> )
>  * I will start by looking into *{{FlowRegistryClient}}* and then base 
> *{{ExtensionRegistryClient}}* toward that approach. If I am understanding 
> correctly, we would contribute an *{{ExtensionRegistryClient}}* feature into 
> Apache NiFi that enables NiFi to integrate with other vendors (Datavolo, 
> H2Oai, etc) group of processors, data flow templates and so on. I see where 
> you are coming from with for Apache the goal being not to build another 
> application. That application could be by the another and NiFi's 
> *{{ExtensionRegistryClient}}* hooks up to their {*}RegistryServer{*}. (Heres 
> the path I will take toward that goal).
>  
> {*}Project Ownership{*}: There will be a clear line that the NiFi Marketplace 
> is not owned by the Apache NiFi PMC, rather it will be managed and owned by a 
> vendor in close alignment with NiFi, which we will announce at a later time.
>  
> {*}Motivation (NiFi){*}: Some people in the community have shown interest in 
> having a NiFi Processor Marketplace where they can contribute their category 
> of processors. In particular, I saw some people interested in contributing 
> their NiFi python processors. This NiFi Processor marketplace could be also 
> applied toward the community interested in contributing custom NiFi java 
> processors.
>  * {*}Extra MiNiFi C+{+}{{+}}{*}: We could even add a section for MiNiFi C+ 
> custom processors. There is a part of the MiNiFi build process that brings in 
> NiFi through building the JNI extension. So, that is a way to integrate NiFi 
> Registry there too.
> I have briefly talked with [~bbende] and [~joewitt] asking them questions on 
> ways to bring custom python processors into production. One of the routes was 
> through leveraging NiFi Registry in connection with Apache NiFi to streamline 
> integration. For my use case, I would leverage the NiFi Processor Marketplace 
> to start contributing my AI/DL "Medical Imaging" Pipeline of custom NiFi 
> Python Processors where I focused on my master thesis AI/DL for stroke 
> diagnosis.
> *High Level Details of NiFi Processor Marketplace App:* For a full stack NiFi 
> Processor Marketplace App, there are frameworks we can leverage for the UI 
> from ReactJS (this mainly is used for frontend),

[jira] [Updated] (NIFI-13328) WindowsEventLogRecordReader should parse RenderingInfo



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

Stephen Jeffrey Hindmarch updated NIFI-13328:
-
Description: 
If windows events are extracted from the windows event collector they will 
include a "RenderingInfo" tag. However, this tag is not expected by the 
WindowsEventLogReader and will throw an error and pass the flow file into the 
failure relationship if the event contains the tag. This tag should be 
supported as it is a legitimate part of the Windows Event XML schema.

See 
[https://learn.microsoft.com/en-us/windows/win32/wes/eventschema-renderingtype-complextype]
 and 
[https://learn.microsoft.com/en-us/windows/win32/wec/windows-event-collector] . 
In this particular use case, events are being collected from field technicians' 
laptops to perform a cybersecurity audit after they have plugging their laptops 
into customer networks.

When these events are processed through a WindowsEventLogReader, the reader 
throws the following error.
{noformat}
ConvertRecord[id=7b99392f-2b54-139e-8791-349e930904cd] Failed to process 
FlowFile[filename=ffca2ea2-edd5-4ad1-8380-2bc4c8dae1ac]; will route to failure: 
org.apache.nifi.processor.exception.ProcessException: Could not parse incoming 
data
- Caused by: org.apache.nifi.serialization.MalformedRecordException: Error 
reading records to determine the FlowFile's RecordSchema
- Caused by: javax.xml.stream.XMLStreamException: Expecting  tag but 
found unknown/invalid tag RenderingInfo{noformat}
An example of the event record might be
{noformat}
https://schemas.microsoft.com/win/2004/08/events/event";>
  
    
    7036
    0
    4
    0
    0
    0x8080
    
    34153
    
    
    System
    WIN-O05CNUCF16M.hdf.local
    
  
  
    Smart Card Device Enumeration Service
    param2
    
5300630044006500760069006300650045006E0075006D002F003400
  
  
    This is a message
  
{noformat}
Removing the tag allows the event to be processed as normal.

One possible workaround is to use a ReplaceText processor to remove the tag 
before reading, but this then involves either discarding the tag contents, or 
using an enrichment fork to find some other way of processing it. Another 
workaround is to use the XMLReader service, but this is a generic parser and 
has a its own problems.

  was:
If windows events are extracted from the windows event collector they will 
include a "RenderingInfo" tag. However, this tag is not expected by the 
WindowsEventLogReader and will throw an error and pass the flow file into the 
failure relationship if the event contains the tag. This tag should be 
supported as it is a legitimate part of the Windows Event XML schema.

See 
[https://learn.microsoft.com/en-us/windows/win32/wes/eventschema-renderingtype-complextype]
 and 
[https://learn.microsoft.com/en-us/windows/win32/wec/windows-event-collector] . 
In this particular use case, events are being collected from field technicians' 
laptops to perform a cybersecurity audit after they have plugging their laptops 
into customer networks.

However, when these events are processed through a WindowsEventLogReader, the 
reader throws the following error.
{noformat}
ConvertRecord[id=7b99392f-2b54-139e-8791-349e930904cd] Failed to process 
FlowFile[filename=ffca2ea2-edd5-4ad1-8380-2bc4c8dae1ac]; will route to failure: 
org.apache.nifi.processor.exception.ProcessException: Could not parse incoming 
data
- Caused by: org.apache.nifi.serialization.MalformedRecordException: Error 
reading records to determine the FlowFile's RecordSchema
- Caused by: javax.xml.stream.XMLStreamException: Expecting  tag but 
found unknown/invalid tag RenderingInfo{noformat}
An example of the event record might be
{noformat}
https://schemas.microsoft.com/win/2004/08/events/event";>
  
    
    7036
    0
    4
    0
    0
    0x8080
    
    34153
    
    
    System
    WIN-O05CNUCF16M.hdf.local
    
  
  
    Smart Card Device Enumeration Service
    param2
    
5300630044006500760069006300650045006E0075006D002F003400
  
  
    This is a message
  
{noformat}
Removing the tag allows the event to be processed as normal.

One possible workaround is to use a ReplaceText processor to remove the tag 
before reading, but this then involves either discarding the tag contents, or 
using an enrichment fork to find some other way of processing it. Another 
workaround is to use the XMLReader service, but this is a generic parser and 
has a its own problems.


> WindowsEventLogRecordReader should parse RenderingInfo
> --
>
> Key: NIFI-13328
> URL: https://issues.apache.org/jira/browse/NIFI-13328
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 1.24.0
> Environment: Docker
>Reporter: Stephen Jeffre

[jira] [Commented] (NIFI-13328) WindowsEventLogRecordReader should parse RenderingInfo



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

Stephen Jeffrey Hindmarch commented on NIFI-13328:
--

I believe this will solve the issues that [~huntes5] is having with parsing 
windows events in NiFi-11784.

> WindowsEventLogRecordReader should parse RenderingInfo
> --
>
> Key: NIFI-13328
> URL: https://issues.apache.org/jira/browse/NIFI-13328
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 1.24.0
> Environment: Docker
>Reporter: Stephen Jeffrey Hindmarch
>Priority: Major
>
> If windows events are extracted from the windows event collector they will 
> include a "RenderingInfo" tag. However, this tag is not expected by the 
> WindowsEventLogReader and will throw an error and pass the flow file into the 
> failure relationship if the event contains the tag. This tag should be 
> supported as it is a legitimate part of the Windows Event XML schema.
> See 
> [https://learn.microsoft.com/en-us/windows/win32/wes/eventschema-renderingtype-complextype]
>  and 
> [https://learn.microsoft.com/en-us/windows/win32/wec/windows-event-collector] 
> . In this particular use case, events are being collected from field 
> technicians' laptops to perform a cybersecurity audit after they have 
> plugging their laptops into customer networks.
> However, when these events are processed through a WindowsEventLogReader, the 
> reader throws the following error.
> {noformat}
> ConvertRecord[id=7b99392f-2b54-139e-8791-349e930904cd] Failed to process 
> FlowFile[filename=ffca2ea2-edd5-4ad1-8380-2bc4c8dae1ac]; will route to 
> failure: org.apache.nifi.processor.exception.ProcessException: Could not 
> parse incoming data
> - Caused by: org.apache.nifi.serialization.MalformedRecordException: Error 
> reading records to determine the FlowFile's RecordSchema
> - Caused by: javax.xml.stream.XMLStreamException: Expecting  tag but 
> found unknown/invalid tag RenderingInfo{noformat}
> An example of the event record might be
> {noformat}
> https://schemas.microsoft.com/win/2004/08/events/event";>
>   
>      Guid="{555908d1-a6d7-4695-8e1e-26931d2012f4}" EventSourceName="Service 
> Control Manager"/>
>     7036
>     0
>     4
>     0
>     0
>     0x8080
>     
>     34153
>     
>     
>     System
>     WIN-O05CNUCF16M.hdf.local
>     
>   
>   
>     Smart Card Device Enumeration Service
>     param2
>     
> 5300630044006500760069006300650045006E0075006D002F003400
>   
>   
>     This is a message
>   
> {noformat}
> Removing the tag allows the event to be processed as normal.
> One possible workaround is to use a ReplaceText processor to remove the tag 
> before reading, but this then involves either discarding the tag contents, or 
> using an enrichment fork to find some other way of processing it. Another 
> workaround is to use the XMLReader service, but this is a generic parser and 
> has a its own problems.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (NIFI-13328) WindowsEventLogRecordReader should parse RenderingInfo

Stephen Jeffrey Hindmarch created NIFI-13328:


 Summary: WindowsEventLogRecordReader should parse RenderingInfo
 Key: NIFI-13328
 URL: https://issues.apache.org/jira/browse/NIFI-13328
 Project: Apache NiFi
  Issue Type: Improvement
  Components: Core Framework
Affects Versions: 1.24.0
 Environment: Docker
Reporter: Stephen Jeffrey Hindmarch


If windows events are extracted from the windows event collector they will 
include a "RenderingInfo" tag. However, this tag is not expected by the 
WindowsEventLogReader and will throw an error and pass the flow file into the 
failure relationship if the event contains the tag. This tag should be 
supported as it is a legitimate part of the Windows Event XML schema.

See 
[https://learn.microsoft.com/en-us/windows/win32/wes/eventschema-renderingtype-complextype]
 and 
[https://learn.microsoft.com/en-us/windows/win32/wec/windows-event-collector] . 
In this particular use case, events are being collected from field technicians' 
laptops to perform a cybersecurity audit after they have plugging their laptops 
into customer networks.

However, when these events are processed through a WindowsEventLogReader, the 
reader throws the following error.
{noformat}
ConvertRecord[id=7b99392f-2b54-139e-8791-349e930904cd] Failed to process 
FlowFile[filename=ffca2ea2-edd5-4ad1-8380-2bc4c8dae1ac]; will route to failure: 
org.apache.nifi.processor.exception.ProcessException: Could not parse incoming 
data
- Caused by: org.apache.nifi.serialization.MalformedRecordException: Error 
reading records to determine the FlowFile's RecordSchema
- Caused by: javax.xml.stream.XMLStreamException: Expecting  tag but 
found unknown/invalid tag RenderingInfo{noformat}
An example of the event record might be
{noformat}
https://schemas.microsoft.com/win/2004/08/events/event";>
  
    
    7036
    0
    4
    0
    0
    0x8080
    
    34153
    
    
    System
    WIN-O05CNUCF16M.hdf.local
    
  
  
    Smart Card Device Enumeration Service
    param2
    
5300630044006500760069006300650045006E0075006D002F003400
  
  
    This is a message
  
{noformat}
Removing the tag allows the event to be processed as normal.

One possible workaround is to use a ReplaceText processor to remove the tag 
before reading, but this then involves either discarding the tag contents, or 
using an enrichment fork to find some other way of processing it. Another 
workaround is to use the XMLReader service, but this is a generic parser and 
has a its own problems.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (NIFI-11784) XML to JSON conversion loses data (ConvertRecord processor - XMLReader and JSONRecordSetWriter)



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

Stephen Jeffrey Hindmarch commented on NIFI-11784:
--

[~huntes5]  I think this ticket should be closed as the advice from [~markap14] 
was the correct answer rather than a workaround. This is the approach described 
in the documentation. However I am also looking at issues involving parsing 
Windows Event XML. In your particular case the reason the WindowsEventLogReader 
was failing is that it is not set up to parse the RenderingInfo tag, which I 
believe is a missing feature and am about to raise a ticket for it. My 
workaround has been to use a ReplaceText to drop the RenderingInfo tag, as it 
does not contain any data of interest to me. Your use case may vary.

> XML to JSON conversion loses data (ConvertRecord processor - XMLReader and 
> JSONRecordSetWriter)
> ---
>
> Key: NIFI-11784
> URL: https://issues.apache.org/jira/browse/NIFI-11784
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.22.0
> Environment: Tested on Windows with ConsumeWindowsEventLog, 
> particularly obvious (100% failure rate) on ForwardedEvents channel in a 
> WEF/WEC setup
>Reporter: Sean Hunter
>Priority: Major
> Attachments: 735fcbc4-13ee-4b9e-bee0-91eb9084cb7e.xml, 
> image-2023-07-06-14-42-46-700.png, image-2023-07-06-14-45-15-939.png, 
> image-2023-07-06-15-04-04-992.png, image-2023-07-06-15-04-53-194.png
>
>
> Screenshot of event going into ConvertRecord processor in XML with valid data 
> in SubjectUserName field (one example of data that's lost):
> !image-2023-07-06-14-42-46-700.png!
> Screenshot of the same flowfile once processed, showing that SubjectUserName 
> field has lost information:
> !image-2023-07-06-14-45-15-939.png!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PR] NIFI-12704 Support record root reference in function arguments [nifi]



hindmasj commented on code in PR #8450:
URL: https://github.com/apache/nifi/pull/8450#discussion_r1622193537


##
nifi-commons/nifi-record-path/src/test/java/org/apache/nifi/record/path/TestRecordPath.java:
##
@@ -2115,4 +2068,11 @@ private Record createSimpleRecord() {
 return new MapRecord(schema, values);
 }
 
+private static FieldValue evaluateSingleFieldValue(RecordPath recordPath, 
Record record) {
+return 
recordPath.evaluate(record).getSelectedFields().findFirst().get();
+}
+
+private static FieldValue evaluateSingleFieldValue(String path, Record 
record) {
+return evaluateSingleFieldValue(RecordPath.compile(path), record);
+}

Review Comment:
   Hi @markap14 , can you take a look at this PR please as I am interested in 
getting the ticket closed. Thanks.



-- 
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] [Commented] (NIFI-8035) Handle nested LDAP groups in LdapUserGroupProvider



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

Stephen Jeffrey Hindmarch commented on NIFI-8035:
-

I would be interested in seeing this issue considered again as it is impacting 
a current project of mine. It looks like the PR was ready to be merged but 
timed out due to lack of action. Is there a way it could be resurrected?

> Handle nested LDAP groups in LdapUserGroupProvider
> --
>
> Key: NIFI-8035
> URL: https://issues.apache.org/jira/browse/NIFI-8035
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Security
>Affects Versions: 1.12.1
>Reporter: Moncef ABBOUD
>Priority: Major
>  Labels: authorization, ldap, security
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Nested LDAP groups are widely used in big organizations especially with 
> Active Directory. Microsoft's AGDLP recommendations rely on nested groups.
> Currently, the LdapUserGroupProvider retrieves users and groups separately. 
> Group memberships are inferred using 'Group Member Attribute' or 'User Group 
> Name Attribute'. It is also possible to construct users and groups relying 
> only on the groups and users entries respectively, this is done in case only 
> one of the "User Search Base" or "Group Search Base" is specified. 
> Microsoft AD (and others such asRed Hat/389 DS) provides support for nested 
> groups retrieval using special filters such as the 
> _LDAP_MATCHING_RULE_IN_CHAIN_ filter_._ With the current implementation, it 
> is not possible to use this filter since it relies on the user's DN being 
> part of the LDAP search filter which would require querying the LDAP server 
> per user. 
> Handling LDAP nested groups would provide much flexibility to organization 
> using Nifi and it would allow compliance with the AGDLP recommandations which 
> is not currently possible. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PR] NIFI-13311: Turn DB adapters into controller services [nifi]



takraj commented on code in PR #8892:
URL: https://github.com/apache/nifi/pull/8892#discussion_r1622011949


##
nifi-extension-bundles/nifi-standard-bundle/nifi-standard-parameter-providers/src/main/java/org/apache/nifi/parameter/DatabaseParameterProvider.java:
##
@@ -38,37 +26,34 @@
 import java.util.HashMap;
 import java.util.List;
 import java.util.Map;
-import java.util.ServiceLoader;
 import java.util.stream.Collectors;
+import org.apache.nifi.annotation.documentation.CapabilityDescription;
+import org.apache.nifi.annotation.documentation.Tags;
+import org.apache.nifi.components.AllowableValue;
+import org.apache.nifi.components.ConfigVerificationResult;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.components.PropertyDescriptor.Builder;
+import org.apache.nifi.controller.ConfigurationContext;
+import org.apache.nifi.db.DatabaseAdapter;
+import org.apache.nifi.dbcp.DBCPService;
+import org.apache.nifi.logging.ComponentLog;
+import org.apache.nifi.processor.util.StandardValidators;
+import org.apache.nifi.util.StringUtils;
 
 @Tags({"database", "dbcp", "sql"})
 @CapabilityDescription("Fetches parameters from database tables")
 
 public class DatabaseParameterProvider extends AbstractParameterProvider 
implements VerifiableParameterProvider {
 
-protected final static Map dbAdapters = new 
HashMap<>();
-
-public static final PropertyDescriptor DB_TYPE;
-
-static {
-// Load the DatabaseAdapters
-ArrayList dbAdapterValues = new ArrayList<>();
-ServiceLoader dbAdapterLoader = 
ServiceLoader.load(DatabaseAdapter.class);
-dbAdapterLoader.forEach(it -> {
-dbAdapters.put(it.getName(), it);
-dbAdapterValues.add(new AllowableValue(it.getName(), it.getName(), 
it.getDescription()));
-});
-
-DB_TYPE = new PropertyDescriptor.Builder()
-.name("db-type")
-.displayName("Database Type")
-.description("The type/flavor of database, used for generating 
database-specific code. In many cases the Generic type "
-+ "should suffice, but some databases (such as Oracle) 
require custom SQL clauses. ")
-.allowableValues(dbAdapterValues.toArray(new 
AllowableValue[dbAdapterValues.size()]))
-.defaultValue("Generic")
-.required(true)
-.build();
-}
+// TODO: There was no migration facility for Parameter Providers by the 
time of introducing this property,

Review Comment:
   What would be the good strategy, given that there is no way to apply 
migration on Parameter Providers?
   
   1. Keep the fixed list of Db adapters in the `DatabaseParameterProvider`?
   2. Replace the fixed list with the new controller service concept, and 
require a manual migration step from the user after upgrade?
   3. Block this commit until the issue is resolved?



-- 
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-13311: Turn DB adapters into controller services [nifi]



takraj commented on code in PR #8892:
URL: https://github.com/apache/nifi/pull/8892#discussion_r1622011949


##
nifi-extension-bundles/nifi-standard-bundle/nifi-standard-parameter-providers/src/main/java/org/apache/nifi/parameter/DatabaseParameterProvider.java:
##
@@ -38,37 +26,34 @@
 import java.util.HashMap;
 import java.util.List;
 import java.util.Map;
-import java.util.ServiceLoader;
 import java.util.stream.Collectors;
+import org.apache.nifi.annotation.documentation.CapabilityDescription;
+import org.apache.nifi.annotation.documentation.Tags;
+import org.apache.nifi.components.AllowableValue;
+import org.apache.nifi.components.ConfigVerificationResult;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.components.PropertyDescriptor.Builder;
+import org.apache.nifi.controller.ConfigurationContext;
+import org.apache.nifi.db.DatabaseAdapter;
+import org.apache.nifi.dbcp.DBCPService;
+import org.apache.nifi.logging.ComponentLog;
+import org.apache.nifi.processor.util.StandardValidators;
+import org.apache.nifi.util.StringUtils;
 
 @Tags({"database", "dbcp", "sql"})
 @CapabilityDescription("Fetches parameters from database tables")
 
 public class DatabaseParameterProvider extends AbstractParameterProvider 
implements VerifiableParameterProvider {
 
-protected final static Map dbAdapters = new 
HashMap<>();
-
-public static final PropertyDescriptor DB_TYPE;
-
-static {
-// Load the DatabaseAdapters
-ArrayList dbAdapterValues = new ArrayList<>();
-ServiceLoader dbAdapterLoader = 
ServiceLoader.load(DatabaseAdapter.class);
-dbAdapterLoader.forEach(it -> {
-dbAdapters.put(it.getName(), it);
-dbAdapterValues.add(new AllowableValue(it.getName(), it.getName(), 
it.getDescription()));
-});
-
-DB_TYPE = new PropertyDescriptor.Builder()
-.name("db-type")
-.displayName("Database Type")
-.description("The type/flavor of database, used for generating 
database-specific code. In many cases the Generic type "
-+ "should suffice, but some databases (such as Oracle) 
require custom SQL clauses. ")
-.allowableValues(dbAdapterValues.toArray(new 
AllowableValue[dbAdapterValues.size()]))
-.defaultValue("Generic")
-.required(true)
-.build();
-}
+// TODO: There was no migration facility for Parameter Providers by the 
time of introducing this property,

Review Comment:
   What would be the good strategy, given that there is no way to apply 
migration on Parameter Providers?
   
   1. Have the fixed list of Db adapters in the {{DatabaseParameterProvider}}?
   2. Replace the fixed list with the new controller service concept, and 
require a manual migration step from the user after upgrade?
   3. Block this commit until the issue is resolved?



-- 
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-13311: Turn DB adapters into controller services [nifi]



takraj commented on code in PR #8892:
URL: https://github.com/apache/nifi/pull/8892#discussion_r1622011949


##
nifi-extension-bundles/nifi-standard-bundle/nifi-standard-parameter-providers/src/main/java/org/apache/nifi/parameter/DatabaseParameterProvider.java:
##
@@ -38,37 +26,34 @@
 import java.util.HashMap;
 import java.util.List;
 import java.util.Map;
-import java.util.ServiceLoader;
 import java.util.stream.Collectors;
+import org.apache.nifi.annotation.documentation.CapabilityDescription;
+import org.apache.nifi.annotation.documentation.Tags;
+import org.apache.nifi.components.AllowableValue;
+import org.apache.nifi.components.ConfigVerificationResult;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.components.PropertyDescriptor.Builder;
+import org.apache.nifi.controller.ConfigurationContext;
+import org.apache.nifi.db.DatabaseAdapter;
+import org.apache.nifi.dbcp.DBCPService;
+import org.apache.nifi.logging.ComponentLog;
+import org.apache.nifi.processor.util.StandardValidators;
+import org.apache.nifi.util.StringUtils;
 
 @Tags({"database", "dbcp", "sql"})
 @CapabilityDescription("Fetches parameters from database tables")
 
 public class DatabaseParameterProvider extends AbstractParameterProvider 
implements VerifiableParameterProvider {
 
-protected final static Map dbAdapters = new 
HashMap<>();
-
-public static final PropertyDescriptor DB_TYPE;
-
-static {
-// Load the DatabaseAdapters
-ArrayList dbAdapterValues = new ArrayList<>();
-ServiceLoader dbAdapterLoader = 
ServiceLoader.load(DatabaseAdapter.class);
-dbAdapterLoader.forEach(it -> {
-dbAdapters.put(it.getName(), it);
-dbAdapterValues.add(new AllowableValue(it.getName(), it.getName(), 
it.getDescription()));
-});
-
-DB_TYPE = new PropertyDescriptor.Builder()
-.name("db-type")
-.displayName("Database Type")
-.description("The type/flavor of database, used for generating 
database-specific code. In many cases the Generic type "
-+ "should suffice, but some databases (such as Oracle) 
require custom SQL clauses. ")
-.allowableValues(dbAdapterValues.toArray(new 
AllowableValue[dbAdapterValues.size()]))
-.defaultValue("Generic")
-.required(true)
-.build();
-}
+// TODO: There was no migration facility for Parameter Providers by the 
time of introducing this property,

Review Comment:
   What would be the good strategy, given that there is no way to apply 
migration on Parameter Providers?
   
   1. Keep the fixed list of Db adapters in the `DatabaseParameterProvider`?
   2. Replace the fixed list with the new controller service concept, and 
require a manual migration step from the user after upgrade?
   3. Block this PR until the issue is resolved?



-- 
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-13311: Turn DB adapters into controller services [nifi]

2024-05-31 Thread ASF subversion and git services (Jira)



takraj commented on code in PR #8892:
URL: https://github.com/apache/nifi/pull/8892#discussion_r1622011949


##
nifi-extension-bundles/nifi-standard-bundle/nifi-standard-parameter-providers/src/main/java/org/apache/nifi/parameter/DatabaseParameterProvider.java:
##
@@ -38,37 +26,34 @@
 import java.util.HashMap;
 import java.util.List;
 import java.util.Map;
-import java.util.ServiceLoader;
 import java.util.stream.Collectors;
+import org.apache.nifi.annotation.documentation.CapabilityDescription;
+import org.apache.nifi.annotation.documentation.Tags;
+import org.apache.nifi.components.AllowableValue;
+import org.apache.nifi.components.ConfigVerificationResult;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.components.PropertyDescriptor.Builder;
+import org.apache.nifi.controller.ConfigurationContext;
+import org.apache.nifi.db.DatabaseAdapter;
+import org.apache.nifi.dbcp.DBCPService;
+import org.apache.nifi.logging.ComponentLog;
+import org.apache.nifi.processor.util.StandardValidators;
+import org.apache.nifi.util.StringUtils;
 
 @Tags({"database", "dbcp", "sql"})
 @CapabilityDescription("Fetches parameters from database tables")
 
 public class DatabaseParameterProvider extends AbstractParameterProvider 
implements VerifiableParameterProvider {
 
-protected final static Map dbAdapters = new 
HashMap<>();
-
-public static final PropertyDescriptor DB_TYPE;
-
-static {
-// Load the DatabaseAdapters
-ArrayList dbAdapterValues = new ArrayList<>();
-ServiceLoader dbAdapterLoader = 
ServiceLoader.load(DatabaseAdapter.class);
-dbAdapterLoader.forEach(it -> {
-dbAdapters.put(it.getName(), it);
-dbAdapterValues.add(new AllowableValue(it.getName(), it.getName(), 
it.getDescription()));
-});
-
-DB_TYPE = new PropertyDescriptor.Builder()
-.name("db-type")
-.displayName("Database Type")
-.description("The type/flavor of database, used for generating 
database-specific code. In many cases the Generic type "
-+ "should suffice, but some databases (such as Oracle) 
require custom SQL clauses. ")
-.allowableValues(dbAdapterValues.toArray(new 
AllowableValue[dbAdapterValues.size()]))
-.defaultValue("Generic")
-.required(true)
-.build();
-}
+// TODO: There was no migration facility for Parameter Providers by the 
time of introducing this property,

Review Comment:
   What would be the good strategy, given that there is no way to apply 
migration on Parameter Providers?
   
   1. Have the fixed list of Db adapters in the `DatabaseParameterProvider`?
   2. Replace the fixed list with the new controller service concept, and 
require a manual migration step from the user after upgrade?
   3. Block this commit until the issue is resolved?



-- 
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] [Resolved] (NIFI-13309) MiNiFi flow update fails to lookup compatible bundles

2024-05-31 Thread Ferenc Kis (Jira)



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

Ferenc Kis resolved NIFI-13309.
---
Resolution: Fixed

> MiNiFi flow update fails to lookup compatible bundles
> -
>
> Key: NIFI-13309
> URL: https://issues.apache.org/jira/browse/NIFI-13309
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: MiNiFi
>Affects Versions: 2.0.0-M1, 2.0.0-M2, 2.0.0-M3
>Reporter: Ferenc Erdei
>Assignee: Ferenc Erdei
>Priority: Minor
>  Labels: minifi-java
> Fix For: 2.0.0-M4
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> h3. Issue
> Publishing a MiNiFi flow that was designed with not the same manifest version 
> as the current MiNiFi runtime use causes flow update failure. 
> Steps to reproduce:
>  * Design a Flow with the previous NiFi version
>  * Publish that flow through C2 Server
> h3. Expected behaviour
> The flow should be loaded with the compatible bundles.
> h3. Actual behaviour
> Exceptions in logs:
> {noformat}
> 2024-05-29 11:43:43,872 INFO [pool-15-thread-1] 
> o.a.n.f.s.StandardVersionedComponentSynchronizer Added 
> GhostProcessor[id=f4d7586c-d575-4255-bbe1-c0f7b129a7ea] to 
> StandardProcessGroup[identifier=7072239a-c047-4d5e-8e68-cd2cbc651343,name=root]
> 2024-05-29 11:43:43,872 ERROR [pool-15-thread-1] 
> o.a.nifi.controller.ExtensionBuilder Could not create Processor of type 
> org.apache.nifi.processors.standard.GenerateFlowFile for ID 
> d7c7463f-beaf-4122-b7af-581a41740512 due to: 
> org.apache.nifi.processors.standard.GenerateFlowFile; creating "Ghost" 
> implementation{noformat}
> And Flow is reverted to the previous flow.
> h3. Root cause
> We have a condition in 
> [https://github.com/apache/nifi/blob/main/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/serialization/VersionedFlowSynchronizer.java#L170]
>  for the existing flow, but we should have a null check for the proposed, and 
> map the compatible bundles even if the old flow was empty.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (NIFI-13309) MiNiFi flow update fails to lookup compatible bundles



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

ASF subversion and git services commented on NIFI-13309:


Commit c12842fc83d0d68fa8091f639f6df7d259d0d0c0 in nifi's branch 
refs/heads/main from Ferenc Erdei
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=c12842fc83 ]

NIFI-13309 Lookup compatible bundles even if previous flow was empty

Signed-off-by: Ferenc Kis 

This closes #.


> MiNiFi flow update fails to lookup compatible bundles
> -
>
> Key: NIFI-13309
> URL: https://issues.apache.org/jira/browse/NIFI-13309
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: MiNiFi
>Affects Versions: 2.0.0-M1, 2.0.0-M2, 2.0.0-M3
>Reporter: Ferenc Erdei
>Assignee: Ferenc Erdei
>Priority: Minor
>  Labels: minifi-java
> Fix For: 2.0.0-M4
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> h3. Issue
> Publishing a MiNiFi flow that was designed with not the same manifest version 
> as the current MiNiFi runtime use causes flow update failure. 
> Steps to reproduce:
>  * Design a Flow with the previous NiFi version
>  * Publish that flow through C2 Server
> h3. Expected behaviour
> The flow should be loaded with the compatible bundles.
> h3. Actual behaviour
> Exceptions in logs:
> {noformat}
> 2024-05-29 11:43:43,872 INFO [pool-15-thread-1] 
> o.a.n.f.s.StandardVersionedComponentSynchronizer Added 
> GhostProcessor[id=f4d7586c-d575-4255-bbe1-c0f7b129a7ea] to 
> StandardProcessGroup[identifier=7072239a-c047-4d5e-8e68-cd2cbc651343,name=root]
> 2024-05-29 11:43:43,872 ERROR [pool-15-thread-1] 
> o.a.nifi.controller.ExtensionBuilder Could not create Processor of type 
> org.apache.nifi.processors.standard.GenerateFlowFile for ID 
> d7c7463f-beaf-4122-b7af-581a41740512 due to: 
> org.apache.nifi.processors.standard.GenerateFlowFile; creating "Ghost" 
> implementation{noformat}
> And Flow is reverted to the previous flow.
> h3. Root cause
> We have a condition in 
> [https://github.com/apache/nifi/blob/main/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/serialization/VersionedFlowSynchronizer.java#L170]
>  for the existing flow, but we should have a null check for the proposed, and 
> map the compatible bundles even if the old flow was empty.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PR] NIFI-13309 Lookup compatible bundles even if previous flow was empty [nifi]



briansolo1985 closed pull request #: NIFI-13309 Lookup compatible bundles 
even if previous flow was empty
URL: https://github.com/apache/nifi/pull/


-- 
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-13311) Turn DB adapters into controller services

2024-05-31 Thread Rajmund Takacs (Jira)



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

Rajmund Takacs updated NIFI-13311:
--
Status: Patch Available  (was: In Progress)

> Turn DB adapters into controller services
> -
>
> Key: NIFI-13311
> URL: https://issues.apache.org/jira/browse/NIFI-13311
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: 2.0.0-M3, 2.0.0-M2, 2.0.0-M1
>Reporter: Rajmund Takacs
>Assignee: Rajmund Takacs
>Priority: Major
>  Labels: enhancement, migration, poc
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> Most of the SQL processors have a property now, where the user is supposed to 
> select a dialect their database understands. The list of supported dialects 
> is currently hard-coded into the standard processors, and therefore there is 
> no way to add a new one as an end-user, without forking NiFi.
> On the other hand, the user is allowed to supply their own DBCP controller 
> service, by just dropping in the nar. So having a fixed list of supported SQL 
> dialects is a serious limitation, since the user can have an unsupported 
> database, and while they can create the necessary DBCP, they cannot add 
> support for the dialect.
> We could resolve this problem by turning these fixed lists into controller 
> services, so letting users fully interfacing NiFi with their own database.
> With NiFi 2.x, there is a property migration framework, that could be 
> utilized in order to avoid breaking existing flows after upgrade.
> For 1.x line, we could probably introduce an option to pick the controller 
> service too, by having an option in these fixed lists like 'Use Controller 
> Service'. This could also be the default option, educating existing users.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (NIFI-13327) Allow migrating properties of Parameter Providers

2024-05-31 Thread Rajmund Takacs (Jira)



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

Rajmund Takacs updated NIFI-13327:
--
Labels: migration  (was: )

> Allow migrating properties of Parameter Providers
> -
>
> Key: NIFI-13327
> URL: https://issues.apache.org/jira/browse/NIFI-13327
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 2.0.0-M3
>Reporter: Rajmund Takacs
>Priority: Major
>  Labels: migration
>
> As of now there is no way to rename, delete properties of a Parameter 
> Providers, or migrate them to newly created Controller Services.
> Please add this feature. Other components, such as processors already have 
> this via the {{migrateProperties()}} interface.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (NIFI-13327) Allow migrating properties of Parameter Providers

2024-05-31 Thread Rajmund Takacs (Jira)

Rajmund Takacs created NIFI-13327:
-

 Summary: Allow migrating properties of Parameter Providers
 Key: NIFI-13327
 URL: https://issues.apache.org/jira/browse/NIFI-13327
 Project: Apache NiFi
  Issue Type: Improvement
  Components: Core Framework
Affects Versions: 2.0.0-M3
Reporter: Rajmund Takacs


As of now there is no way to rename, delete properties of a Parameter 
Providers, or migrate them to newly created Controller Services.

Please add this feature. Other components, such as processors already have this 
via the {{migrateProperties()}} interface.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PR] NIFI-13311: Turn DB adapters into controller services [nifi]