[jira] [Updated] (NIFI-11658) Streamline using single parameter context for nested PGs
[ https://issues.apache.org/jira/browse/NIFI-11658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-11658: -- Fix Version/s: 1.27.0 > Streamline using single parameter context for nested PGs > > > Key: NIFI-11658 > URL: https://issues.apache.org/jira/browse/NIFI-11658 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Timea Barna >Assignee: Timea Barna >Priority: Major > Fix For: 2.0.0-M1, 1.27.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > 1. when adding a new process group to the canvas, in the create PG view where > one should give the name of the process group, add a drop down menu to select > the parameter context to associate with the process group. It would default > to the parameter context associated to the parent process group (if there is > one specified and if the user has the permissions) > 2. in the configuration view of a process group, add a dedicated tab for > parameter context to have dedicated handling. In addition to the dropdown > menu for selecting a parameter context, add a checkbox to recursively apply > the change. This checkbox would only be used when clicking "Apply", it would > not be persisted. If checked, it means that the parameter context will be > applied to the process group as well to all the embedded process groups > (recursively) if and only if the user has the proper permissions on all > process groups. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-13283) Exception thrown in PutKinesisFirehose processor
[ https://issues.apache.org/jira/browse/NIFI-13283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard resolved NIFI-13283. --- Fix Version/s: 2.0.0-M4 Resolution: Fixed > Exception thrown in PutKinesisFirehose processor > > > Key: NIFI-13283 > URL: https://issues.apache.org/jira/browse/NIFI-13283 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 2.0.0-M1, 2.0.0-M2, 2.0.0-M3 >Reporter: Evan Shelton >Priority: Major > Fix For: 2.0.0-M4 > > Time Spent: 0.5h > Remaining Estimate: 0h > > When attempting to send data to Firehose an exception is thrown related to > attempting to access an ArrayList that hasn't been initialized -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13283) Exception thrown in PutKinesisFirehose processor
[ https://issues.apache.org/jira/browse/NIFI-13283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13283: -- Affects Version/s: 2.0.0-M2 2.0.0-M1 > Exception thrown in PutKinesisFirehose processor > > > Key: NIFI-13283 > URL: https://issues.apache.org/jira/browse/NIFI-13283 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 2.0.0-M1, 2.0.0-M2, 2.0.0-M3 >Reporter: Evan Shelton >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > When attempting to send data to Firehose an exception is thrown related to > attempting to access an ArrayList that hasn't been initialized -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13268) ConsumeGCPPubSub Stopped Working with M3
[
https://issues.apache.org/jira/browse/NIFI-13268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard updated NIFI-13268:
--
Component/s: Extensions
> ConsumeGCPPubSub Stopped Working with M3
>
>
> Key: NIFI-13268
> URL: https://issues.apache.org/jira/browse/NIFI-13268
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 2.0.0-M3
>Reporter: Emin
>Assignee: Peter Turcsanyi
>Priority: Major
>
> After updating from 1.26 to 2.0.0M3, getting the following for
> `ConsumeGCPPubSub`
>
> {{nifi-1 | 2024-05-18 23:00:02,157 INFO [NiFi Web Server-405]
> o.a.n.c.s.StandardProcessScheduler Running once
> ConsumeGCPubSub[id=890ffc25-018f-1000-f9bc-b29966db3fc6] nifi-1 | 2024-05-18
> 23:00:02,158 INFO [NiFi Web Server-405]
> o.a.n.controller.StandardProcessorNode Starting
> ConsumeGCPubSub[id=890ffc25-018f-1000-f9bc-b29966db3fc6] nifi-1 | 2024-05-18
> 23:00:02,170 ERROR [Timer-Driven Process Thread-1]
> o.a.n.p.gcp.pubsub.ConsumeGCPubSub
> ConsumeGCPubSub[id=890ffc25-018f-1000-f9bc-b29966db3fc6] Failed to properly
> initialize Processor. If still scheduled to run, NiFi will attempt to
> initialize and run the Processor again after the 'Administrative Yield
> Duration' has elapsed. Failure is due to java.util.ServiceConfigurationError:
> io.grpc.ManagedChannelProvider:
> io.grpc.netty.shaded.io.grpc.netty.UdsNettyChannelProvider Unable to get
> public no-arg constructor nifi-1 | java.util.ServiceConfigurationError:
> io.grpc.ManagedChannelProvider:
> io.grpc.netty.shaded.io.grpc.netty.UdsNettyChannelProvider Unable to get
> public no-arg constructor nifi-1 | at
> java.base/java.util.ServiceLoader.fail(ServiceLoader.java:586) nifi-1 | at
> java.base/java.util.ServiceLoader.getConstructor(ServiceLoader.java:679)
> nifi-1 | at
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1240)
> nifi-1 | at
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1273)
> nifi-1 | at
> java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1309) nifi-1 |
> at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1393)
> nifi-1 | at io.grpc.ServiceProviders.loadAll(ServiceProviders.java:67) nifi-1
> | at
> io.grpc.ManagedChannelRegistry.getDefaultRegistry(ManagedChannelRegistry.java:101)
> nifi-1 | at
> io.grpc.ManagedChannelProvider.provider(ManagedChannelProvider.java:43)
> nifi-1 | at
> io.grpc.ManagedChannelBuilder.forAddress(ManagedChannelBuilder.java:44)
> nifi-1 | at
> com.google.api.gax.grpc.InstantiatingGrpcChannelProvider.createSingleChannel(InstantiatingGrpcChannelProvider.java:404)
> nifi-1 | at com.google.api.gax.grpc.ChannelPool.(ChannelPool.java:107)
> nifi-1 | at com.google.api.gax.grpc.ChannelPool.create(ChannelPool.java:85)
> nifi-1 | at
> com.google.api.gax.grpc.InstantiatingGrpcChannelProvider.createChannel(InstantiatingGrpcChannelProvider.java:243)
> nifi-1 | at
> com.google.api.gax.grpc.InstantiatingGrpcChannelProvider.getTransportChannel(InstantiatingGrpcChannelProvider.java:237)
> nifi-1 | at
> com.google.api.gax.rpc.ClientContext.create(ClientContext.java:230) nifi-1 |
> at
> com.google.cloud.pubsub.v1.stub.GrpcSubscriberStub.create(GrpcSubscriberStub.java:287)
> nifi-1 | at
> org.apache.nifi.processors.gcp.pubsub.ConsumeGCPubSub.getSubscriber(ConsumeGCPubSub.java:286)
> nifi-1 | at
> org.apache.nifi.processors.gcp.pubsub.ConsumeGCPubSub.onScheduled(ConsumeGCPubSub.java:134)
> nifi-1 | at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> nifi-1 | at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> nifi-1 | at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:145)
> nifi-1 | at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:133)
> nifi-1 | at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:78)
> nifi-1 | at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotation(ReflectionUtils.java:55)
> nifi-1 | at
> org.apache.nifi.controller.StandardProcessorNode.lambda$initiateStart$10(StandardProcessorNode.java:1668)
> nifi-1 | at org.apache.nifi.engine.FlowEngine$3.call(FlowEngine.java:123)
> nifi-1 | at
> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317) nifi-1 |
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> nifi-1 | at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> nifi-1 | at
>
[jira] [Updated] (NIFI-13268) ConsumeGCPPubSub Stopped Working with M3
[
https://issues.apache.org/jira/browse/NIFI-13268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard updated NIFI-13268:
--
Affects Version/s: 2.0.0-M3
> ConsumeGCPPubSub Stopped Working with M3
>
>
> Key: NIFI-13268
> URL: https://issues.apache.org/jira/browse/NIFI-13268
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 2.0.0-M3
>Reporter: Emin
>Assignee: Peter Turcsanyi
>Priority: Major
>
> After updating from 1.26 to 2.0.0M3, getting the following for
> `ConsumeGCPPubSub`
>
> {{nifi-1 | 2024-05-18 23:00:02,157 INFO [NiFi Web Server-405]
> o.a.n.c.s.StandardProcessScheduler Running once
> ConsumeGCPubSub[id=890ffc25-018f-1000-f9bc-b29966db3fc6] nifi-1 | 2024-05-18
> 23:00:02,158 INFO [NiFi Web Server-405]
> o.a.n.controller.StandardProcessorNode Starting
> ConsumeGCPubSub[id=890ffc25-018f-1000-f9bc-b29966db3fc6] nifi-1 | 2024-05-18
> 23:00:02,170 ERROR [Timer-Driven Process Thread-1]
> o.a.n.p.gcp.pubsub.ConsumeGCPubSub
> ConsumeGCPubSub[id=890ffc25-018f-1000-f9bc-b29966db3fc6] Failed to properly
> initialize Processor. If still scheduled to run, NiFi will attempt to
> initialize and run the Processor again after the 'Administrative Yield
> Duration' has elapsed. Failure is due to java.util.ServiceConfigurationError:
> io.grpc.ManagedChannelProvider:
> io.grpc.netty.shaded.io.grpc.netty.UdsNettyChannelProvider Unable to get
> public no-arg constructor nifi-1 | java.util.ServiceConfigurationError:
> io.grpc.ManagedChannelProvider:
> io.grpc.netty.shaded.io.grpc.netty.UdsNettyChannelProvider Unable to get
> public no-arg constructor nifi-1 | at
> java.base/java.util.ServiceLoader.fail(ServiceLoader.java:586) nifi-1 | at
> java.base/java.util.ServiceLoader.getConstructor(ServiceLoader.java:679)
> nifi-1 | at
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1240)
> nifi-1 | at
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1273)
> nifi-1 | at
> java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1309) nifi-1 |
> at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1393)
> nifi-1 | at io.grpc.ServiceProviders.loadAll(ServiceProviders.java:67) nifi-1
> | at
> io.grpc.ManagedChannelRegistry.getDefaultRegistry(ManagedChannelRegistry.java:101)
> nifi-1 | at
> io.grpc.ManagedChannelProvider.provider(ManagedChannelProvider.java:43)
> nifi-1 | at
> io.grpc.ManagedChannelBuilder.forAddress(ManagedChannelBuilder.java:44)
> nifi-1 | at
> com.google.api.gax.grpc.InstantiatingGrpcChannelProvider.createSingleChannel(InstantiatingGrpcChannelProvider.java:404)
> nifi-1 | at com.google.api.gax.grpc.ChannelPool.(ChannelPool.java:107)
> nifi-1 | at com.google.api.gax.grpc.ChannelPool.create(ChannelPool.java:85)
> nifi-1 | at
> com.google.api.gax.grpc.InstantiatingGrpcChannelProvider.createChannel(InstantiatingGrpcChannelProvider.java:243)
> nifi-1 | at
> com.google.api.gax.grpc.InstantiatingGrpcChannelProvider.getTransportChannel(InstantiatingGrpcChannelProvider.java:237)
> nifi-1 | at
> com.google.api.gax.rpc.ClientContext.create(ClientContext.java:230) nifi-1 |
> at
> com.google.cloud.pubsub.v1.stub.GrpcSubscriberStub.create(GrpcSubscriberStub.java:287)
> nifi-1 | at
> org.apache.nifi.processors.gcp.pubsub.ConsumeGCPubSub.getSubscriber(ConsumeGCPubSub.java:286)
> nifi-1 | at
> org.apache.nifi.processors.gcp.pubsub.ConsumeGCPubSub.onScheduled(ConsumeGCPubSub.java:134)
> nifi-1 | at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> nifi-1 | at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> nifi-1 | at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:145)
> nifi-1 | at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:133)
> nifi-1 | at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:78)
> nifi-1 | at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotation(ReflectionUtils.java:55)
> nifi-1 | at
> org.apache.nifi.controller.StandardProcessorNode.lambda$initiateStart$10(StandardProcessorNode.java:1668)
> nifi-1 | at org.apache.nifi.engine.FlowEngine$3.call(FlowEngine.java:123)
> nifi-1 | at
> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317) nifi-1 |
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> nifi-1 | at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> nifi-1 | at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
> nifi-1 | at
[jira] [Updated] (NIFI-13267) Bump NiFi NAR Maven plugin version
[ https://issues.apache.org/jira/browse/NIFI-13267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13267: -- Status: Patch Available (was: Open) > 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: 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] [Updated] (NIFI-13274) Dependencies housekeeping for NiFi NAR Maven plugin
[ https://issues.apache.org/jira/browse/NIFI-13274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13274: -- Status: Patch Available (was: Open) > Dependencies housekeeping for NiFi NAR Maven plugin > --- > > Key: NIFI-13274 > URL: https://issues.apache.org/jira/browse/NIFI-13274 > Project: Apache NiFi > Issue Type: Task >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Fix For: nifi-nar-maven-plugin-2.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Dependencies housekeeping for NiFi NAR Maven plugin > Also fixing the SNAPSHOT version. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13273) Release NiFi NAR Maven Plugin 2.0.0
[ https://issues.apache.org/jira/browse/NIFI-13273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13273: -- Summary: Release NiFi NAR Maven Plugin 2.0.0 (was: Release NiFi NAR Maven Plugin 1.6.0) > Release NiFi NAR Maven Plugin 2.0.0 > --- > > Key: NIFI-13273 > URL: https://issues.apache.org/jira/browse/NIFI-13273 > Project: Apache NiFi > Issue Type: Task > Components: Tools and Build >Affects Versions: nifi-nar-maven-plugin-1.6.0 >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Fix For: nifi-nar-maven-plugin-1.6.0 > > > Release NiFi NAR Maven Plugin 1.6.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13274) Dependencies housekeeping for NiFi NAR Maven plugin
Pierre Villard created NIFI-13274: - Summary: Dependencies housekeeping for NiFi NAR Maven plugin Key: NIFI-13274 URL: https://issues.apache.org/jira/browse/NIFI-13274 Project: Apache NiFi Issue Type: Task Reporter: Pierre Villard Assignee: Pierre Villard Fix For: nifi-nar-maven-plugin-1.6.0 Dependencies housekeeping for NiFi NAR Maven plugin Also fixing the SNAPSHOT version. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13273) Release NiFi NAR Maven Plugin 1.6.0
Pierre Villard created NIFI-13273: - Summary: Release NiFi NAR Maven Plugin 1.6.0 Key: NIFI-13273 URL: https://issues.apache.org/jira/browse/NIFI-13273 Project: Apache NiFi Issue Type: Task Components: Tools and Build Affects Versions: nifi-nar-maven-plugin-1.6.0 Reporter: Pierre Villard Assignee: Pierre Villard Fix For: nifi-nar-maven-plugin-1.6.0 Release NiFi NAR Maven Plugin 1.6.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-13268) ConsumeGCPPubSub Stopped Working with M3
[
https://issues.apache.org/jira/browse/NIFI-13268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847969#comment-17847969
]
Pierre Villard commented on NIFI-13268:
---
The same problem seems to happen across GCP processors. I have the same error
with PutBigQuery.
> ConsumeGCPPubSub Stopped Working with M3
>
>
> Key: NIFI-13268
> URL: https://issues.apache.org/jira/browse/NIFI-13268
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Emin
>Priority: Major
>
> After updating from 1.26 to 2.0.0M3, getting the following for
> `ConsumeGCPPubSub`
>
> {{nifi-1 | 2024-05-18 23:00:02,157 INFO [NiFi Web Server-405]
> o.a.n.c.s.StandardProcessScheduler Running once
> ConsumeGCPubSub[id=890ffc25-018f-1000-f9bc-b29966db3fc6] nifi-1 | 2024-05-18
> 23:00:02,158 INFO [NiFi Web Server-405]
> o.a.n.controller.StandardProcessorNode Starting
> ConsumeGCPubSub[id=890ffc25-018f-1000-f9bc-b29966db3fc6] nifi-1 | 2024-05-18
> 23:00:02,170 ERROR [Timer-Driven Process Thread-1]
> o.a.n.p.gcp.pubsub.ConsumeGCPubSub
> ConsumeGCPubSub[id=890ffc25-018f-1000-f9bc-b29966db3fc6] Failed to properly
> initialize Processor. If still scheduled to run, NiFi will attempt to
> initialize and run the Processor again after the 'Administrative Yield
> Duration' has elapsed. Failure is due to java.util.ServiceConfigurationError:
> io.grpc.ManagedChannelProvider:
> io.grpc.netty.shaded.io.grpc.netty.UdsNettyChannelProvider Unable to get
> public no-arg constructor nifi-1 | java.util.ServiceConfigurationError:
> io.grpc.ManagedChannelProvider:
> io.grpc.netty.shaded.io.grpc.netty.UdsNettyChannelProvider Unable to get
> public no-arg constructor nifi-1 | at
> java.base/java.util.ServiceLoader.fail(ServiceLoader.java:586) nifi-1 | at
> java.base/java.util.ServiceLoader.getConstructor(ServiceLoader.java:679)
> nifi-1 | at
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1240)
> nifi-1 | at
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1273)
> nifi-1 | at
> java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1309) nifi-1 |
> at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1393)
> nifi-1 | at io.grpc.ServiceProviders.loadAll(ServiceProviders.java:67) nifi-1
> | at
> io.grpc.ManagedChannelRegistry.getDefaultRegistry(ManagedChannelRegistry.java:101)
> nifi-1 | at
> io.grpc.ManagedChannelProvider.provider(ManagedChannelProvider.java:43)
> nifi-1 | at
> io.grpc.ManagedChannelBuilder.forAddress(ManagedChannelBuilder.java:44)
> nifi-1 | at
> com.google.api.gax.grpc.InstantiatingGrpcChannelProvider.createSingleChannel(InstantiatingGrpcChannelProvider.java:404)
> nifi-1 | at com.google.api.gax.grpc.ChannelPool.(ChannelPool.java:107)
> nifi-1 | at com.google.api.gax.grpc.ChannelPool.create(ChannelPool.java:85)
> nifi-1 | at
> com.google.api.gax.grpc.InstantiatingGrpcChannelProvider.createChannel(InstantiatingGrpcChannelProvider.java:243)
> nifi-1 | at
> com.google.api.gax.grpc.InstantiatingGrpcChannelProvider.getTransportChannel(InstantiatingGrpcChannelProvider.java:237)
> nifi-1 | at
> com.google.api.gax.rpc.ClientContext.create(ClientContext.java:230) nifi-1 |
> at
> com.google.cloud.pubsub.v1.stub.GrpcSubscriberStub.create(GrpcSubscriberStub.java:287)
> nifi-1 | at
> org.apache.nifi.processors.gcp.pubsub.ConsumeGCPubSub.getSubscriber(ConsumeGCPubSub.java:286)
> nifi-1 | at
> org.apache.nifi.processors.gcp.pubsub.ConsumeGCPubSub.onScheduled(ConsumeGCPubSub.java:134)
> nifi-1 | at
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> nifi-1 | at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> nifi-1 | at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:145)
> nifi-1 | at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:133)
> nifi-1 | at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:78)
> nifi-1 | at
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotation(ReflectionUtils.java:55)
> nifi-1 | at
> org.apache.nifi.controller.StandardProcessorNode.lambda$initiateStart$10(StandardProcessorNode.java:1668)
> nifi-1 | at org.apache.nifi.engine.FlowEngine$3.call(FlowEngine.java:123)
> nifi-1 | at
> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317) nifi-1 |
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> nifi-1 | at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> nifi-1 | at
>
[jira] [Created] (NIFI-13267) Bump NiFi NAR Maven plugin version
Pierre Villard created NIFI-13267: - Summary: 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 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] [Updated] (NIFI-13264) Attach extension-manifest.xml to build as an artifact
[ https://issues.apache.org/jira/browse/NIFI-13264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13264: -- Fix Version/s: nifi-nar-maven-plugin-1.5.2 Resolution: Fixed Status: Resolved (was: Patch Available) > Attach extension-manifest.xml to build as an artifact > - > > Key: NIFI-13264 > URL: https://issues.apache.org/jira/browse/NIFI-13264 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: nifi-nar-maven-plugin-1.5.1 >Reporter: Bryan Bende >Assignee: Bryan Bende >Priority: Minor > Fix For: nifi-nar-maven-plugin-1.5.2 > > Time Spent: 20m > Remaining Estimate: 0h > > The NAR Maven Plugin produces extension-manifest.xml and bundles it into the > resulting NAR file. It would beneficial to directly attach this file to the > build so that it can be published on releases and retrieved from a Maven > repository without retrieving the entire NAR which can be quite large. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-12226) Maven plugin: Add flag to skip doc generation
[ https://issues.apache.org/jira/browse/NIFI-12226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard resolved NIFI-12226. --- Fix Version/s: nifi-nar-maven-plugin-1.5.2 Resolution: Fixed > Maven plugin: Add flag to skip doc generation > - > > Key: NIFI-12226 > URL: https://issues.apache.org/jira/browse/NIFI-12226 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Nicolò Boschi >Priority: Minor > Fix For: nifi-nar-maven-plugin-1.5.2 > > Time Spent: 1h > Remaining Estimate: 0h > > In [LangStream/langstream|https://github.com/LangStream/langstream] we use > this plugin for producing NAR files. The NAR are then ingested by the > LangStream runtime and the documentation is not needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13258) NAR Plugin - add parameter providers and flow analysis rules extension types
[ https://issues.apache.org/jira/browse/NIFI-13258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13258: -- Status: Patch Available (was: Open) > NAR Plugin - add parameter providers and flow analysis rules extension types > > > Key: NIFI-13258 > URL: https://issues.apache.org/jira/browse/NIFI-13258 > Project: Apache NiFi > Issue Type: Improvement > Components: Tools and Build >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Fix For: nifi-nar-maven-plugin-1.5.2 > > Time Spent: 10m > Remaining Estimate: 0h > > Improve the NiFi NAR Maven plugin to add Parameter Providers and Flow > Analysis Rules in the extension types. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13258) NAR Plugin - add parameter providers and flow analysis rules extension types
Pierre Villard created NIFI-13258: - Summary: NAR Plugin - add parameter providers and flow analysis rules extension types Key: NIFI-13258 URL: https://issues.apache.org/jira/browse/NIFI-13258 Project: Apache NiFi Issue Type: Improvement Components: Tools and Build Reporter: Pierre Villard Assignee: Pierre Villard Fix For: nifi-nar-maven-plugin-1.5.2 Improve the NiFi NAR Maven plugin to add Parameter Providers and Flow Analysis Rules in the extension types. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-13256) Python WriteHelloWorld Example has Incorrect Attributes
[ https://issues.apache.org/jira/browse/NIFI-13256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard resolved NIFI-13256. --- Fix Version/s: 2.0.0-M4 Resolution: Fixed > Python WriteHelloWorld Example has Incorrect Attributes > --- > > Key: NIFI-13256 > URL: https://issues.apache.org/jira/browse/NIFI-13256 > Project: Apache NiFi > Issue Type: Bug > Components: Documentation Website >Affects Versions: 2.0.0-M2 >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Fix For: 2.0.0-M4 > > Time Spent: 20m > Remaining Estimate: 0h > > The Python Developer Guide includes an example WriteHelloWorld Processor > which defines a set instead of a dictionary for FlowFile attributes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13238) Checkstyle - rules for whitespace
[ https://issues.apache.org/jira/browse/NIFI-13238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13238: -- Status: Patch Available (was: Open) > Checkstyle - rules for whitespace > - > > Key: NIFI-13238 > URL: https://issues.apache.org/jira/browse/NIFI-13238 > Project: Apache NiFi > Issue Type: Improvement > Components: Tools and Build >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Adding the following rules: > * WhitespaceAfter > * NoWhitespaceAfter > * NoWhitespaceBefore > * WhitespaceAround -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13238) Checkstyle - rules for whitespace
Pierre Villard created NIFI-13238: - Summary: Checkstyle - rules for whitespace Key: NIFI-13238 URL: https://issues.apache.org/jira/browse/NIFI-13238 Project: Apache NiFi Issue Type: Improvement Components: Tools and Build Reporter: Pierre Villard Assignee: Pierre Villard Adding the following rules: * WhitespaceAfter * NoWhitespaceAfter * NoWhitespaceBefore * WhitespaceAround -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13237) Checkstyle improvements
Pierre Villard created NIFI-13237: - Summary: Checkstyle improvements Key: NIFI-13237 URL: https://issues.apache.org/jira/browse/NIFI-13237 Project: Apache NiFi Issue Type: Epic Reporter: Pierre Villard Assignee: Pierre Villard Epic to track the addition of some rules in the checkstyle configuration of the NiFi project. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13210) Add Codecov Token to GitHub Actions
[
https://issues.apache.org/jira/browse/NIFI-13210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard updated NIFI-13210:
--
Fix Version/s: 2.0.0-M3
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Add Codecov Token to GitHub Actions
> ---
>
> Key: NIFI-13210
> URL: https://issues.apache.org/jira/browse/NIFI-13210
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Major
> Fix For: 2.0.0-M3
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Codecov provides free services for unit test code coverage reporting and
> recent versions of the GitHub Action require a Codecov Token for reporting
> status. Apache Infra has assigned the {{CODECOV_TOKEN}} secret to the GitHub
> repository, so it can be used in GitHub workflows.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-12231) Add completion strategy to FetchSmb
[ https://issues.apache.org/jira/browse/NIFI-12231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12231: -- Fix Version/s: (was: 1.27.0) > Add completion strategy to FetchSmb > --- > > Key: NIFI-12231 > URL: https://issues.apache.org/jira/browse/NIFI-12231 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Affects Versions: 1.23.2 >Reporter: Jens M Kofoed >Assignee: Peter Turcsanyi >Priority: Major > Fix For: 2.0.0-M3 > > Time Spent: 40m > Remaining Estimate: 0h > > The newly added ListSmb and FetchSmb has been very much appreciated. But > sadly the FetchSmb does not have the same options like other Fetch processors. > FetchFTP and FetchSFTP process has a Completion Strategy where you can choose > to Move or Delete the file after it has been fetched. > It would be very helpfull if FetchSmb gets the same possibilities -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-13133) Conduct Apache NiFi 1.26.0 Release
[ https://issues.apache.org/jira/browse/NIFI-13133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard resolved NIFI-13133. --- Resolution: Done > Conduct Apache NiFi 1.26.0 Release > -- > > Key: NIFI-13133 > URL: https://issues.apache.org/jira/browse/NIFI-13133 > Project: Apache NiFi > Issue Type: Task >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Fix For: 1.26.0 > > > Conduct Apache NiFi 1.26.0 Release -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12231) Add completion strategy to FetchSmb
[ https://issues.apache.org/jira/browse/NIFI-12231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12231: -- Fix Version/s: 1.27.0 > Add completion strategy to FetchSmb > --- > > Key: NIFI-12231 > URL: https://issues.apache.org/jira/browse/NIFI-12231 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Affects Versions: 1.23.2 >Reporter: Jens M Kofoed >Assignee: Peter Turcsanyi >Priority: Major > Fix For: 2.0.0-M3, 1.27.0 > > Time Spent: 40m > Remaining Estimate: 0h > > The newly added ListSmb and FetchSmb has been very much appreciated. But > sadly the FetchSmb does not have the same options like other Fetch processors. > FetchFTP and FetchSFTP process has a Completion Strategy where you can choose > to Move or Delete the file after it has been fetched. > It would be very helpfull if FetchSmb gets the same possibilities -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12231) Add completion strategy to FetchSmb
[ https://issues.apache.org/jira/browse/NIFI-12231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12231: -- Fix Version/s: 2.0.0-M3 Resolution: Fixed Status: Resolved (was: Patch Available) > Add completion strategy to FetchSmb > --- > > Key: NIFI-12231 > URL: https://issues.apache.org/jira/browse/NIFI-12231 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Affects Versions: 1.23.2 >Reporter: Jens M Kofoed >Assignee: Peter Turcsanyi >Priority: Major > Fix For: 2.0.0-M3 > > Time Spent: 40m > Remaining Estimate: 0h > > The newly added ListSmb and FetchSmb has been very much appreciated. But > sadly the FetchSmb does not have the same options like other Fetch processors. > FetchFTP and FetchSFTP process has a Completion Strategy where you can choose > to Move or Delete the file after it has been fetched. > It would be very helpfull if FetchSmb gets the same possibilities -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-12973) Add Process Group scope to Flow Analysis rules
[ https://issues.apache.org/jira/browse/NIFI-12973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard resolved NIFI-12973. --- Fix Version/s: 2.0.0-M3 Resolution: Fixed > Add Process Group scope to Flow Analysis rules > -- > > Key: NIFI-12973 > URL: https://issues.apache.org/jira/browse/NIFI-12973 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Pierre Villard >Assignee: Tamas Palfy >Priority: Major > Fix For: 2.0.0-M3 > > Time Spent: 50m > Remaining Estimate: 0h > > I think it'd be useful to have an optional property in all Flow Analysis > rules to scope a rule execution to a specific process group (and its embedded > process groups). > Most NiFi users are using NiFi in a multi tenant way and are dedicating a > process group to a given team. Different rules may apply across different > teams hence the advantage of scoping a rule to a process group (when it makes > sense for the rule). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13008) CLI command to upgrade all instances of a versioned flow
[ https://issues.apache.org/jira/browse/NIFI-13008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13008: -- Fix Version/s: 1.27.0 (was: 1.26.0) > CLI command to upgrade all instances of a versioned flow > > > Key: NIFI-13008 > URL: https://issues.apache.org/jira/browse/NIFI-13008 > Project: Apache NiFi > Issue Type: Improvement > Components: Tools and Build >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Labels: backport-needed > Fix For: 2.0.0-M3, 1.27.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Add a CLI command allowing someone to upgrade all the instances of a given > versioned flow. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13138) Add extensions name and description in NiFi Registry
[ https://issues.apache.org/jira/browse/NIFI-13138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13138: -- Status: Patch Available (was: Open) > Add extensions name and description in NiFi Registry > > > Key: NIFI-13138 > URL: https://issues.apache.org/jira/browse/NIFI-13138 > Project: Apache NiFi > Issue Type: Improvement > Components: NiFi Registry >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Similar to NIFI-13050, it'd be extremely useful, for a given bundle, in NiFi > Registry, to display the included extensions in that bundle. For each > extension, we want to display the name and associated description. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13138) Add extensions name and description in NiFi Registry
Pierre Villard created NIFI-13138: - Summary: Add extensions name and description in NiFi Registry Key: NIFI-13138 URL: https://issues.apache.org/jira/browse/NIFI-13138 Project: Apache NiFi Issue Type: Improvement Components: NiFi Registry Reporter: Pierre Villard Assignee: Pierre Villard Similar to NIFI-13050, it'd be extremely useful, for a given bundle, in NiFi Registry, to display the included extensions in that bundle. For each extension, we want to display the name and associated description. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13137) Switch to Zulu for MacOS Java 8 action
[ https://issues.apache.org/jira/browse/NIFI-13137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13137: -- Status: Patch Available (was: Open) > Switch to Zulu for MacOS Java 8 action > -- > > Key: NIFI-13137 > URL: https://issues.apache.org/jira/browse/NIFI-13137 > Project: Apache NiFi > Issue Type: Task > Components: Tools and Build >Affects Versions: 1.26.0 >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Temurin Java 8 is not available for macOS 14 on AArch64. The most > straightforward solution would be switching to some other JDK, such as Azul. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13137) Switch to Zulu for MacOS Java 8 action
Pierre Villard created NIFI-13137: - Summary: Switch to Zulu for MacOS Java 8 action Key: NIFI-13137 URL: https://issues.apache.org/jira/browse/NIFI-13137 Project: Apache NiFi Issue Type: Task Components: Tools and Build Affects Versions: 1.26.0 Reporter: Pierre Villard Assignee: Pierre Villard Temurin Java 8 is not available for macOS 14 on AArch64. The most straightforward solution would be switching to some other JDK, such as Azul. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13133) Conduct Apache NiFi 1.26.0 Release
Pierre Villard created NIFI-13133: - Summary: Conduct Apache NiFi 1.26.0 Release Key: NIFI-13133 URL: https://issues.apache.org/jira/browse/NIFI-13133 Project: Apache NiFi Issue Type: Task Reporter: Pierre Villard Assignee: Pierre Villard Fix For: 1.26.0 Conduct Apache NiFi 1.26.0 Release -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-13131) Dependency hygiene
[ https://issues.apache.org/jira/browse/NIFI-13131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard resolved NIFI-13131. --- Resolution: Fixed > Dependency hygiene > --- > > Key: NIFI-13131 > URL: https://issues.apache.org/jira/browse/NIFI-13131 > Project: Apache NiFi > Issue Type: Task >Reporter: Joe Witt >Assignee: Joe Witt >Priority: Major > Fix For: 1.26.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Related to NIFI-13108 it was asked to do some similar updates. > I will pick off the safest looking ones. The NiFi 1.x line does not have the > same dependency tree/pom structure protections now established in the 2.x > line from NIFI-12998 so such dependency hygiene efforts will likely require > more and more specific scrutiny and effort going forward. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-12831) Add PutOpenSearchVector and QueryOpenSearchVector processors
[ https://issues.apache.org/jira/browse/NIFI-12831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard resolved NIFI-12831. --- Fix Version/s: 2.0.0-M3 Resolution: Fixed > Add PutOpenSearchVector and QueryOpenSearchVector processors > > > Key: NIFI-12831 > URL: https://issues.apache.org/jira/browse/NIFI-12831 > Project: Apache NiFi > Issue Type: New Feature >Reporter: Mark Bathori >Assignee: Mark Bathori >Priority: Major > Fix For: 2.0.0-M3 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Create vector store specific put and query processors for OpenSearch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-13097) Set Project Version in Python Extension Processors
[
https://issues.apache.org/jira/browse/NIFI-13097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard resolved NIFI-13097.
---
Resolution: Fixed
> Set Project Version in Python Extension Processors
> --
>
> Key: NIFI-13097
> URL: https://issues.apache.org/jira/browse/NIFI-13097
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Major
> Fix For: 2.0.0-M3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Python Processors in the {{nifi-python-extensions}} module have the version
> field set to {{2.0.0-SNAPSHOT}} in the Processor Details section of the
> Python class. Although this works while the main branch remains on the
> snapshot version, it does not support applying the project version to these
> Processors using standard release processes.
> The version field can use a placeholder that will be populated during the
> Maven module build process to align the Processor version field with the
> released Maven module version, without other manual changes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-13079) Is there a roadmap for bundle persistence provider?
[ https://issues.apache.org/jira/browse/NIFI-13079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839763#comment-17839763 ] Pierre Villard commented on NIFI-13079: --- I think it's better to discuss this in the Slack channels or via the email thread. The short answer is that it is absolutely used. I'm actually in the process of adding a lot of things so that it's better represented in the NiFi Registry. There are currently two persistence providers (local file system and S3), I filed a PR a long time ago to support GCS but never got merged, I may refresh that PR since I'm spending time on those topics lately. > Is there a roadmap for bundle persistence provider? > --- > > Key: NIFI-13079 > URL: https://issues.apache.org/jira/browse/NIFI-13079 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Igor Milavec >Priority: Minor > > Hi! > Based on the admin and user guides, it feels to me that the current status of > bundle persistence providers is in limbo? > The functionality is there, but it is not clear how to use it. I have found > documentation about how to configure NiFi Registry and how to upload a bundle > (using curl). I'm left wondering how this affects deployment, what are the > triggers for deployment, does it support SemVer, ... > Also, I could find no future plans for this feature. Is this being used at > all and are there plans to develop/support it in the future? > > Thank you! Igor -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13077) On-demand Extension Provider
Pierre Villard created NIFI-13077:
-
Summary: On-demand Extension Provider
Key: NIFI-13077
URL: https://issues.apache.org/jira/browse/NIFI-13077
Project: Apache NiFi
Issue Type: Epic
Components: Core Framework
Reporter: Pierre Villard
We currently have the concept of ExternalResourceProvider with two
implementations (HDFS and NiFi Registry) that can be configured to list and
download all NARs made available in those locations. Those implementations, if
configured, would get started when NiFi starts and would download ALL of the
available NARs, plus a background thread would check every five minutes for new
NARs to be available and downloaded.
The proposal here is to have a similar concept that would focus on extensions /
components but instead of having a background thread and instead of having all
of the components downloaded, the approach would be to plug this into the
ExtensionBuilder and when a component cannot be instantiated (when loading a
flow definition) with locally available components, then, instead of creating a
ghost component, the Extension Providers would be queried with specific
coordinates and if the provider makes the component available, then the NAR
would be downloaded (alongside required dependencies if the NAR depends on
another NAR).
This approach already exists in the Kafka Connect NiFi plugin with the class
ExtensionClientDefinition. By adopting this approach in NiFi, it’d be much
easier to ship a much smaller version of NiFi and have NiFi download the
required components based on flows that are being instantiated / deployed.
The operation of downloading the NAR would not be blocking, meaning that we
would still create a ghost component but after completion of the NAR(s)
download and the loading of the components, the flows would be fully
operational.
It might be possible to show something similar as for the Python extensions
where we show that the component is still in the process of downloading third
party dependencies.
While this is a great opportunity to reduce the size of the NiFi binary (and
associated container image), it would not be great from a user perspective when
designing flows because all of the NARs removed from the default image would no
longer be visible in the list of available components when adding, for example,
a processor to the canvas.
Longer term we could imagine that the extension providers can also implement a
listing API so that when showing the list of available components, we would
show the list of the components available locally as well as the components
available through the extensions providers. The listing of components could add
another column to indicate the source of the component.
This is something that is exposed for the Extension Bundles in the NiFi
Registry (we also have the information about the NiFi API version that has been
used for building the components so we could use this information to only list
components that should be compatible from an API standpoint - same major
version but lower or equal API version).
The immediate goal though would be to introduce the concept of
ExtensionProvider with the following APIs:
{code:java}
boolean isAvailableExtension(Coordinates)
void downloadExtension(Coordinates)
{code}
Longer term we could also consider something like:
{code:java}
List listExtensions(){code}
But we would need to figure out how a NAR can provide the information about the
components that are inside of it. The NiFi Registry provides this information,
but that would not be the case for a Maven based implementation for example.
In nifi.properties we would have something looking like:
{code:java}
nifi.nar.extension.provider..{code}
And we would loop through all the configured providers to find the appropriate
NAR to download based on provided coordinates in the flow definition that is
being instantiated (either from flow.json.gz, or an uploaded JSON flow
definition, or when checking out a flow from a registry client).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-13077) On-demand Extension Provider
[
https://issues.apache.org/jira/browse/NIFI-13077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard updated NIFI-13077:
--
Description:
We currently have the concept of ExternalResourceProvider with two
implementations (HDFS and NiFi Registry) that can be configured to list and
download all NARs made available in those locations. Those implementations, if
configured, would get started when NiFi starts and would download ALL of the
available NARs, plus a background thread would check every five minutes for new
NARs to be available and downloaded.
The proposal here is to have a similar concept that would focus on extensions /
components but instead of having a background thread and instead of having all
of the components downloaded, the approach would be to plug this into the
ExtensionBuilder and when a component cannot be instantiated (when loading a
flow definition) with locally available components, then, instead of creating a
ghost component, the Extension Providers would be queried with specific
coordinates and if the provider makes the component available, then the NAR
would be downloaded (alongside required dependencies if the NAR depends on
another NAR).
This approach already exists in the Kafka Connect NiFi plugin with the class
ExtensionClientDefinition. By adopting this approach in NiFi, it’d be much
easier to ship a much smaller version of NiFi and have NiFi download the
required components based on flows that are being instantiated / deployed.
The operation of downloading the NAR would not be blocking, meaning that we
would still create a ghost component but after completion of the NAR(s)
download and the loading of the components, the flows would be fully
operational.
It might be possible to show something similar as for the Python extensions
where we show that the component is still in the process of downloading third
party dependencies.
While this is a great opportunity to reduce the size of the NiFi binary (and
associated container image), it would not be great from a user perspective when
designing flows because all of the NARs removed from the default image would no
longer be visible in the list of available components when adding, for example,
a processor to the canvas.
Longer term we could imagine that the extension providers can also implement a
listing API so that when showing the list of available components, we would
show the list of the components available locally as well as the components
available through the extensions providers. The listing of components could add
another column to indicate the source of the component.
This is something that is exposed for the Extension Bundles in the NiFi
Registry (we also have the information about the NiFi API version that has been
used for building the components so we could use this information to only list
components that should be compatible from an API standpoint - same major
version but lower or equal API version).
The immediate goal though would be to introduce the concept of
ExtensionProvider with the following APIs:
{code:java}
boolean isAvailableExtension(Coordinates)
void downloadExtension(Coordinates)
{code}
Longer term we could also consider something like:
{code:java}
List listExtensions(){code}
But we would need to figure out how a NAR can provide the information about the
components that are inside of it. The NiFi Registry provides this information,
but that would not be the case for a Maven based implementation for example.
In nifi.properties we would have something looking like:
{code:java}
nifi.nar.extension.provider..{code}
And we would loop through all the configured providers to find the appropriate
NAR to download based on provided coordinates in the flow definition that is
being instantiated (either from flow.json.gz, or an uploaded JSON flow
definition, or when checking out a flow from a registry client).
was:
We currently have the concept of ExternalResourceProvider with two
implementations (HDFS and NiFi Registry) that can be configured to list and
download all NARs made available in those locations. Those implementations, if
configured, would get started when NiFi starts and would download ALL of the
available NARs, plus a background thread would check every five minutes for new
NARs to be available and downloaded.
The proposal here is to have a similar concept that would focus on extensions /
components but instead of having a background thread and instead of having all
of the components downloaded, the approach would be to plug this into the
ExtensionBuilder and when a component cannot be instantiated (when loading a
flow definition) with locally available components, then, instead of creating a
ghost component, the Extension Providers would be queried with specific
coordinates and if the provider makes the component available, then the NAR
would be downloaded
[jira] [Updated] (NIFI-12858) Processor change history on property hover
[ https://issues.apache.org/jira/browse/NIFI-12858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12858: -- Fix Version/s: 2.0.0-M3 1.26.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Processor change history on property hover > -- > > Key: NIFI-12858 > URL: https://issues.apache.org/jira/browse/NIFI-12858 > Project: Apache NiFi > Issue Type: Bug > Components: Core UI >Affects Versions: 2.0.0-M1, 1.24.0, 1.25.0, 2.0.0-M2 >Reporter: Chris Conklin >Assignee: David Handermann >Priority: Minor > Labels: backport-needed > Fix For: 2.0.0-M3, 1.26.0 > > Attachments: nifi1.23.2.png, nifi1.24.png > > Time Spent: 20m > Remaining Estimate: 0h > > The history details list on processors changed order after release 1.23.2. > Previous sort on history upon hovering over some property was latest update > first. > Starting with release 1.24 this order changed to oldest change first. > Since only 5 history lines appear this makes the feature not very useful. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13070) Upgrade Netty to 4.1.109
[ https://issues.apache.org/jira/browse/NIFI-13070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13070: -- Fix Version/s: 2.0.0-M3 1.26.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Netty to 4.1.109 > > > Key: NIFI-13070 > URL: https://issues.apache.org/jira/browse/NIFI-13070 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: backport-needed > Fix For: 2.0.0-M3, 1.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Netty dependencies should be upgraded to > [4.1.109|https://netty.io/news/2024/04/15/4-1-109-Final.html] to incorporate > several bug fixes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13067) Upgrade Spring Security to 6.2.4
[ https://issues.apache.org/jira/browse/NIFI-13067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13067: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Spring Security to 6.2.4 > > > Key: NIFI-13067 > URL: https://issues.apache.org/jira/browse/NIFI-13067 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework, NiFi Registry >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 2.0.0-M3 > > Time Spent: 10m > Remaining Estimate: 0h > > Spring Security dependencies should be upgraded to > [6.2.4|https://github.com/spring-projects/spring-security/releases/tag/6.2.4] > to incorporate several minor bug fixes and transitive dependency upgrades. As > part of the upgrade, OpenSAML dependencies should be upgraded to 4.3.1 and > AspectJ should be upgraded to 1.9.22. > Spring Boot for Registry can also be incremented to > [3.2.5|https://github.com/spring-projects/spring-boot/releases/tag/v3.2.5] to > align with Spring Security 6.2.4 and Spring Framework 6.1.6. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13066) Upgrade Bouncy Castle to 1.78.1
[ https://issues.apache.org/jira/browse/NIFI-13066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13066: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Bouncy Castle to 1.78.1 > --- > > Key: NIFI-13066 > URL: https://issues.apache.org/jira/browse/NIFI-13066 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework, Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 2.0.0-M3, 1.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Bouncy Castle libraries should be upgraded to version > [1.78.1|https://www.bouncycastle.org/releasenotes.html#r1rv78] to incorporate > several bug fixes, which include resolving several vulnerabilities that apply > to usage patterns outside of NiFi integration points. > Bouncy Castle 1.78.1 corrects a dependency relationship issue with bcpg and > bcutil that caused issues with OpenPGP usage in version 1.78. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13052) CRON Driven components should be searchable
[ https://issues.apache.org/jira/browse/NIFI-13052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13052: -- Fix Version/s: 1.26.0 > CRON Driven components should be searchable > --- > > Key: NIFI-13052 > URL: https://issues.apache.org/jira/browse/NIFI-13052 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: Michael W Moser >Assignee: Michael W Moser >Priority: Minor > Fix For: 2.0.0-M3, 1.26.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > By entering the keyword "timer" in the Search Bar, you can locate all > components with "Scheduling Strategy: Timer driven". > We should also be able to locate all components that have "Scheduling > Strategy: CRON driven". > This feature is documented in the User Guide under the "Search Components in > DataFlow" section. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13052) CRON Driven components should be searchable
[ https://issues.apache.org/jira/browse/NIFI-13052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13052: -- Fix Version/s: 2.0.0-M3 Resolution: Fixed Status: Resolved (was: Patch Available) > CRON Driven components should be searchable > --- > > Key: NIFI-13052 > URL: https://issues.apache.org/jira/browse/NIFI-13052 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: Michael W Moser >Assignee: Michael W Moser >Priority: Minor > Fix For: 2.0.0-M3 > > Time Spent: 0.5h > Remaining Estimate: 0h > > By entering the keyword "timer" in the Search Bar, you can locate all > components with "Scheduling Strategy: Timer driven". > We should also be able to locate all components that have "Scheduling > Strategy: CRON driven". > This feature is documented in the User Guide under the "Search Components in > DataFlow" section. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13050) Add bundle dependencies info in NiFi Registry
[
https://issues.apache.org/jira/browse/NIFI-13050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard updated NIFI-13050:
--
Status: Patch Available (was: Open)
> Add bundle dependencies info in NiFi Registry
> -
>
> Key: NIFI-13050
> URL: https://issues.apache.org/jira/browse/NIFI-13050
> Project: Apache NiFi
> Issue Type: Improvement
> Components: NiFi Registry
>Reporter: Pierre Villard
>Assignee: Pierre Villard
>Priority: Major
>
> Follow-up improvement after NIFI-13048
> It'd be useful to display the dependencies for the bundles in NiFi Registry.
> The API endpoint is already exposed:
> {code:java}
> .../nifi-registry-api/bundles//versions/{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (NIFI-13050) Add bundle dependencies info in NiFi Registry
Pierre Villard created NIFI-13050:
-
Summary: Add bundle dependencies info in NiFi Registry
Key: NIFI-13050
URL: https://issues.apache.org/jira/browse/NIFI-13050
Project: Apache NiFi
Issue Type: Improvement
Components: NiFi Registry
Reporter: Pierre Villard
Assignee: Pierre Villard
Follow-up improvement after NIFI-13048
It'd be useful to display the dependencies for the bundles in NiFi Registry.
The API endpoint is already exposed:
{code:java}
.../nifi-registry-api/bundles//versions/{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-13048) Add bundle build info in NiFi Registry
[ https://issues.apache.org/jira/browse/NIFI-13048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13048: -- Status: Patch Available (was: Open) > Add bundle build info in NiFi Registry > -- > > Key: NIFI-13048 > URL: https://issues.apache.org/jira/browse/NIFI-13048 > Project: Apache NiFi > Issue Type: Improvement > Components: NiFi Registry >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > When dealing with bundles, we should display the build info as well as the > size of the bundle and the NiFi API version that has been used to build it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13048) Add bundle build info in NiFi Registry
[ https://issues.apache.org/jira/browse/NIFI-13048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13048: -- Description: When dealing with bundles, we should display the build info as well as the size of the bundle and the NiFi API version that has been used to build it. (was: When dealing with bundles, we should display the build info as well as the size of the bundle and the NiFi API version that has been used to build the it.) > Add bundle build info in NiFi Registry > -- > > Key: NIFI-13048 > URL: https://issues.apache.org/jira/browse/NIFI-13048 > Project: Apache NiFi > Issue Type: Improvement > Components: NiFi Registry >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > > When dealing with bundles, we should display the build info as well as the > size of the bundle and the NiFi API version that has been used to build it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13048) Add bundle build info in NiFi Registry
Pierre Villard created NIFI-13048: - Summary: Add bundle build info in NiFi Registry Key: NIFI-13048 URL: https://issues.apache.org/jira/browse/NIFI-13048 Project: Apache NiFi Issue Type: Improvement Components: NiFi Registry Reporter: Pierre Villard Assignee: Pierre Villard When dealing with bundles, we should display the build info as well as the size of the bundle and the NiFi API version that has been used to build the it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-13046) Upgrade Solr dependencies to 8.11.3
[ https://issues.apache.org/jira/browse/NIFI-13046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard resolved NIFI-13046. --- Fix Version/s: 1.26.0 Resolution: Fixed > Upgrade Solr dependencies to 8.11.3 > --- > > Key: NIFI-13046 > URL: https://issues.apache.org/jira/browse/NIFI-13046 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Mark Bathori >Assignee: Mark Bathori >Priority: Major > Fix For: 1.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Upgrade Solr dependencies to 8.11.3. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13038) Upgrade Groovy to 4.0.21
[ https://issues.apache.org/jira/browse/NIFI-13038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13038: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Groovy to 4.0.21 > > > Key: NIFI-13038 > URL: https://issues.apache.org/jira/browse/NIFI-13038 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 2.0.0-M3 > > Time Spent: 20m > Remaining Estimate: 0h > > Groovy dependencies should be upgraded to > [4.0.21|http://groovy-lang.org/changelogs/changelog-4.0.21.html] to > incorporate several transitive dependency upgrades. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13037) Upgrade Spring Framework to 5.3.34 on Support Branch
[ https://issues.apache.org/jira/browse/NIFI-13037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13037: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Spring Framework to 5.3.34 on Support Branch > > > Key: NIFI-13037 > URL: https://issues.apache.org/jira/browse/NIFI-13037 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework, MiNiFi, NiFi Registry >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 1.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Spring Framework dependencies on the support branch should be upgraded to > version > [5.3.34|https://github.com/spring-projects/spring-framework/releases/tag/v5.3.34] > to resolve several flagged vulnerabilities. Spring Security should be > upgraded to 5.8.11 and Jetty should be upgraded to > [9.4.54|https://github.com/jetty/jetty.project/releases/tag/jetty-9.4.54.v20240208] > to resolve CVE-2024-22201 related to HTTP/2 connection closing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13040) Upgrade Commons IO to 2.16.1
[ https://issues.apache.org/jira/browse/NIFI-13040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13040: -- Fix Version/s: 2.0.0-M3 1.26.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Commons IO to 2.16.1 > > > Key: NIFI-13040 > URL: https://issues.apache.org/jira/browse/NIFI-13040 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework, Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: backport-needed > Fix For: 2.0.0-M3, 1.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Apache Commons IO should be upgraded to > [2.16.1|https://commons.apache.org/proper/commons-io/changes-report.html#a2.16.1] > to incorporate a number of bug fixes and improvements. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-13036) Upgrade Logback to 1.5.5 and SLF4J to 2.0.13
[
https://issues.apache.org/jira/browse/NIFI-13036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard resolved NIFI-13036.
---
Resolution: Fixed
> Upgrade Logback to 1.5.5 and SLF4J to 2.0.13
>
>
> Key: NIFI-13036
> URL: https://issues.apache.org/jira/browse/NIFI-13036
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework, MiNiFi, NiFi Registry
>Reporter: David Handermann
>Priority: Major
> Fix For: 2.0.0-M3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Logback dependencies should be upgraded to
> [1.5.5|https://logback.qos.ch/news.html#1.5.5] and SLF4J should be upgraded
> to [2.0.13|https://www.slf4j.org/news.html#2.0.13] to incorporate several
> minor improvements.
> The Logback 1.5 release series requires Java 11, so it applies only to the
> main branch of Apache NiFi and cannot be backported to the support branch.
> Logback 1.5 decouples the core implementation from the {{logback-access}}
> module, which NiFi does not use, and is otherwise compatible with Logback 1.4.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-13033) Upgrade Jetty to 12.0.8
[ https://issues.apache.org/jira/browse/NIFI-13033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13033: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Jetty to 12.0.8 > --- > > Key: NIFI-13033 > URL: https://issues.apache.org/jira/browse/NIFI-13033 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework, Extensions, NiFi Registry >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 2.0.0-M3 > > Time Spent: 20m > Remaining Estimate: 0h > > Jetty dependencies should be upgraded to > [12.0.8|https://github.com/jetty/jetty.project/releases/tag/jetty-12.0.8] to > incorporate various bug fixes and feature improvements. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13032) Upgrade Spring Framework to 6.1.6
[
https://issues.apache.org/jira/browse/NIFI-13032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard updated NIFI-13032:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Upgrade Spring Framework to 6.1.6
> -
>
> Key: NIFI-13032
> URL: https://issues.apache.org/jira/browse/NIFI-13032
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework, MiNiFi, NiFi Registry
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Major
> Fix For: 2.0.0-M3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Spring Framework dependencies should be upgraded to
> [6.1.6|https://github.com/spring-projects/spring-framework/releases/tag/v6.1.6]
> to incorporate several bug fixes and improvements. Bug fixes include a
> resolution for CVE-2024-22262, which relates to parsing URLs using the Spring
> {{UriComponentsBuilder}} class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-13026) Add a read only mode to non secured NiFi Registry
[ https://issues.apache.org/jira/browse/NIFI-13026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13026: -- Resolution: Won't Do Status: Resolved (was: Patch Available) > Add a read only mode to non secured NiFi Registry > - > > Key: NIFI-13026 > URL: https://issues.apache.org/jira/browse/NIFI-13026 > Project: Apache NiFi > Issue Type: Improvement > Components: NiFi Registry >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Labels: backport-needed > Time Spent: 50m > Remaining Estimate: 0h > > There are scenarios where NiFi Registry may be deployed in a non secured way. > When doing so, as of now, all users access would be anonymous and all > permissions would be granted. This improvement is to allow for a read-only > mode when NiFi Registry is not secured so that all users can access NiFi > Registry but only perform READ actions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13027) Warn users for small files processing in PutIceberg
[ https://issues.apache.org/jira/browse/NIFI-13027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13027: -- Status: Patch Available (was: Open) > Warn users for small files processing in PutIceberg > --- > > Key: NIFI-13027 > URL: https://issues.apache.org/jira/browse/NIFI-13027 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Labels: backport-needed > > While it can be a valid use case, it is a very bad idea to send a lot of > small flow files via the PutIceberg processor as it will generate a massive > amount of snapshot files. The recommendation is clearly to use a > MergeContent/MergeRecord processor before the PutIceberg processor to make > sure we limit the amount of individual files being sent to an Iceberg table. > While we can't force a user (this could be a flow analysis rule though) we > should let them know very clearly that what they're doing is likely a bad > idea and let them know what is the recommended way. However if the user is > sure they know what they're doing, they should be able to disable the warning. > This Jira is about adding: > * a property "Warn for small flow files" set to true by default > * a property "Minimum recommended file size" set to 10MB (depending on the > previous property, if set to true) > And if the warning is enabled and a processed flow file is below the limit, > then log a warning with the recommendation of using a Merge processor so that > a bulletin is generated and shown to the user. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13027) Warn users for small files processing in PutIceberg
Pierre Villard created NIFI-13027: - Summary: Warn users for small files processing in PutIceberg Key: NIFI-13027 URL: https://issues.apache.org/jira/browse/NIFI-13027 Project: Apache NiFi Issue Type: Improvement Components: Extensions Reporter: Pierre Villard Assignee: Pierre Villard While it can be a valid use case, it is a very bad idea to send a lot of small flow files via the PutIceberg processor as it will generate a massive amount of snapshot files. The recommendation is clearly to use a MergeContent/MergeRecord processor before the PutIceberg processor to make sure we limit the amount of individual files being sent to an Iceberg table. While we can't force a user (this could be a flow analysis rule though) we should let them know very clearly that what they're doing is likely a bad idea and let them know what is the recommended way. However if the user is sure they know what they're doing, they should be able to disable the warning. This Jira is about adding: * a property "Warn for small flow files" set to true by default * a property "Minimum recommended file size" set to 10MB (depending on the previous property, if set to true) And if the warning is enabled and a processed flow file is below the limit, then log a warning with the recommendation of using a Merge processor so that a bulletin is generated and shown to the user. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13026) Add a read only mode to non secured NiFi Registry
[ https://issues.apache.org/jira/browse/NIFI-13026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13026: -- Status: Patch Available (was: Open) > Add a read only mode to non secured NiFi Registry > - > > Key: NIFI-13026 > URL: https://issues.apache.org/jira/browse/NIFI-13026 > Project: Apache NiFi > Issue Type: Improvement > Components: NiFi Registry >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Labels: backport-needed > > There are scenarios where NiFi Registry may be deployed in a non secured way. > When doing so, as of now, all users access would be anonymous and all > permissions would be granted. This improvement is to allow for a read-only > mode when NiFi Registry is not secured so that all users can access NiFi > Registry but only perform READ actions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13026) Add a read only mode to non secured NiFi Registry
Pierre Villard created NIFI-13026: - Summary: Add a read only mode to non secured NiFi Registry Key: NIFI-13026 URL: https://issues.apache.org/jira/browse/NIFI-13026 Project: Apache NiFi Issue Type: Improvement Components: NiFi Registry Reporter: Pierre Villard Assignee: Pierre Villard There are scenarios where NiFi Registry may be deployed in a non secured way. When doing so, as of now, all users access would be anonymous and all permissions would be granted. This improvement is to allow for a read-only mode when NiFi Registry is not secured so that all users can access NiFi Registry but only perform READ actions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13025) NifiRegistryFlowRegistryClient to allow for truststore only SSL Context Service
[ https://issues.apache.org/jira/browse/NIFI-13025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13025: -- Status: Patch Available (was: Open) > NifiRegistryFlowRegistryClient to allow for truststore only SSL Context > Service > --- > > Key: NIFI-13025 > URL: https://issues.apache.org/jira/browse/NIFI-13025 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Labels: backport-needed > > Right now the NifiRegistryFlowRegistryClient Registry Client, when configured > with an SSL Context Service, requires the SSL CS to be configured with both a > keystore and a truststore. However, there are valid deployment scenarios > where only a truststore should be configured in case anonymous access to the > Registry is desired. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13025) NifiRegistryFlowRegistryClient to allow for truststore only SSL Context Service
Pierre Villard created NIFI-13025: - Summary: NifiRegistryFlowRegistryClient to allow for truststore only SSL Context Service Key: NIFI-13025 URL: https://issues.apache.org/jira/browse/NIFI-13025 Project: Apache NiFi Issue Type: Improvement Components: Extensions Reporter: Pierre Villard Assignee: Pierre Villard Right now the NifiRegistryFlowRegistryClient Registry Client, when configured with an SSL Context Service, requires the SSL CS to be configured with both a keystore and a truststore. However, there are valid deployment scenarios where only a truststore should be configured in case anonymous access to the Registry is desired. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12889) Retry Kerberos Login on auth failures in HDFS processors
[ https://issues.apache.org/jira/browse/NIFI-12889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12889: -- Fix Version/s: 1.26.0 > Retry Kerberos Login on auth failures in HDFS processors > > > Key: NIFI-12889 > URL: https://issues.apache.org/jira/browse/NIFI-12889 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Matt Burgess >Assignee: Matt Burgess >Priority: Major > Fix For: 2.0.0-M3, 1.26.0 > > Time Spent: 4h > Remaining Estimate: 0h > > Currently if a Kerberos authentication failure happens (during ticket > relogin, e.g.) in the HDFS processors, the controller service must be > restarted manually in order for the processors to execute correctly. From the > processors we should reset the HDFS resources on auth failure to simulate a > "restart" of the controller service so relogin can occur correctly. > At a minimum this includes the following processors: > FetchHDFS > GetHDFS > GetHDFSFileInfo > PutHDFS > ListHDFS -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-13010) UpdateDatabaseTable Processor cannot use DBCPConnectionPoolLookup
[ https://issues.apache.org/jira/browse/NIFI-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard resolved NIFI-13010. --- Fix Version/s: 2.0.0-M3 1.26.0 Resolution: Fixed > UpdateDatabaseTable Processor cannot use DBCPConnectionPoolLookup > - > > Key: NIFI-13010 > URL: https://issues.apache.org/jira/browse/NIFI-13010 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.25.0, 2.0.0-M2 >Reporter: Jim Steinebrey >Assignee: Jim Steinebrey >Priority: Minor > Fix For: 2.0.0-M3, 1.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The UpdateDatabaseTable processor fails to execute when it is configured to > use a DBCP Connection Pool Lookup. The flow file has database.name attribute, > However, when the processor runs, it gets the following error: > org.apache.nifi.processor.exception.ProcessException: > java.lang.UnsupportedOperationException: Cannot lookup DBCPConnectionPool > without attributes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-10977) Add Documentation for Kubernetes Cluster Deployments
[ https://issues.apache.org/jira/browse/NIFI-10977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-10977: -- Fix Version/s: 2.0.0-M3 Resolution: Fixed Status: Resolved (was: Patch Available) > Add Documentation for Kubernetes Cluster Deployments > > > Key: NIFI-10977 > URL: https://issues.apache.org/jira/browse/NIFI-10977 > Project: Apache NiFi > Issue Type: Improvement >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 2.0.0-M3 > > Time Spent: 40m > Remaining Estimate: 0h > > Project documentation should be expanded to describe the basic features and > implementation of Kubernetes Leader Election and State Management. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12837) Add DFS setting to smb processors
[
https://issues.apache.org/jira/browse/NIFI-12837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard updated NIFI-12837:
--
Fix Version/s: 1.26.0
> Add DFS setting to smb processors
> -
>
> Key: NIFI-12837
> URL: https://issues.apache.org/jira/browse/NIFI-12837
> Project: Apache NiFi
> Issue Type: Improvement
>Affects Versions: 1.25.0, 2.0.0-M2
>Reporter: Anders
>Assignee: Peter Turcsanyi
>Priority: Major
> Fix For: 2.0.0-M3, 1.26.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The hierynomus/smbj library has a setting for enabling DFS which is disabled
> by default:
> https://github.com/hierynomus/smbj/blob/f25d5c5478a5b73e9ba4202dcfb365974e15367e/src/main/java/com/hierynomus/smbj/SmbConfig.java#L106C17-L106C39
> This appears to cause problems in some SMB configurations.
> Patched
> https://github.com/apache/nifi/blob/main/nifi-nar-bundles/nifi-smb-bundle/nifi-smb-smbj-common/src/main/java/org/apache/nifi/smb/common/SmbUtils.java
> to test in my environment with:
> {code}
> $ git diff
> nifi-smb-smbj-common/src/main/java/org/apache/nifi/smb/common/SmbUtils.java
> diff --git
> a/nifi-nar-bundles/nifi-smb-bundle/nifi-smb-smbj-common/src/main/java/org/apache/nifi/smb/common/SmbUtils.java
>
> b/nifi-nar-bundles/nifi-smb-bundle/nifi-smb-smbj-common/src/main/java/org/apache/nifi/smb/common/SmbUtils.java
> index 0895abfae0..eac765 100644
> ---
> a/nifi-nar-bundles/nifi-smb-bundle/nifi-smb-smbj-common/src/main/java/org/apache/nifi/smb/common/SmbUtils.java
> +++
> b/nifi-nar-bundles/nifi-smb-bundle/nifi-smb-smbj-common/src/main/java/org/apache/nifi/smb/common/SmbUtils.java
> @@ -46,6 +46,8 @@ public final class SmbUtils {
> }
> }
> +configBuilder.withDfsEnabled(true);
> +
> if (context.getProperty(USE_ENCRYPTION).isSet()) {
>
> configBuilder.withEncryptData(context.getProperty(USE_ENCRYPTION).asBoolean());
> }
> {code}
> This appeared to resolve the issue.
> It would be very useful if this setting was available to toggle in the UI for
> all SMB processors.
> Without this setting, I get a *STATUS_PATH_NOT_COVERED* error.
> Somewhat related hierynomus/smbj github issues:
> https://github.com/hierynomus/smbj/issues/152
> https://github.com/hierynomus/smbj/issues/419
> This setting should be made available in the following processors and
> services:
> * GetSmbFile
> * PutSmbFile
> * SmbjClientProviderService
> Edit: It might require some more changes to handle the connections and
> sessions correctly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-12837) Add DFS setting to smb processors
[
https://issues.apache.org/jira/browse/NIFI-12837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard updated NIFI-12837:
--
Fix Version/s: 2.0.0-M3
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Add DFS setting to smb processors
> -
>
> Key: NIFI-12837
> URL: https://issues.apache.org/jira/browse/NIFI-12837
> Project: Apache NiFi
> Issue Type: Improvement
>Affects Versions: 1.25.0, 2.0.0-M2
>Reporter: Anders
>Assignee: Peter Turcsanyi
>Priority: Major
> Fix For: 2.0.0-M3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The hierynomus/smbj library has a setting for enabling DFS which is disabled
> by default:
> https://github.com/hierynomus/smbj/blob/f25d5c5478a5b73e9ba4202dcfb365974e15367e/src/main/java/com/hierynomus/smbj/SmbConfig.java#L106C17-L106C39
> This appears to cause problems in some SMB configurations.
> Patched
> https://github.com/apache/nifi/blob/main/nifi-nar-bundles/nifi-smb-bundle/nifi-smb-smbj-common/src/main/java/org/apache/nifi/smb/common/SmbUtils.java
> to test in my environment with:
> {code}
> $ git diff
> nifi-smb-smbj-common/src/main/java/org/apache/nifi/smb/common/SmbUtils.java
> diff --git
> a/nifi-nar-bundles/nifi-smb-bundle/nifi-smb-smbj-common/src/main/java/org/apache/nifi/smb/common/SmbUtils.java
>
> b/nifi-nar-bundles/nifi-smb-bundle/nifi-smb-smbj-common/src/main/java/org/apache/nifi/smb/common/SmbUtils.java
> index 0895abfae0..eac765 100644
> ---
> a/nifi-nar-bundles/nifi-smb-bundle/nifi-smb-smbj-common/src/main/java/org/apache/nifi/smb/common/SmbUtils.java
> +++
> b/nifi-nar-bundles/nifi-smb-bundle/nifi-smb-smbj-common/src/main/java/org/apache/nifi/smb/common/SmbUtils.java
> @@ -46,6 +46,8 @@ public final class SmbUtils {
> }
> }
> +configBuilder.withDfsEnabled(true);
> +
> if (context.getProperty(USE_ENCRYPTION).isSet()) {
>
> configBuilder.withEncryptData(context.getProperty(USE_ENCRYPTION).asBoolean());
> }
> {code}
> This appeared to resolve the issue.
> It would be very useful if this setting was available to toggle in the UI for
> all SMB processors.
> Without this setting, I get a *STATUS_PATH_NOT_COVERED* error.
> Somewhat related hierynomus/smbj github issues:
> https://github.com/hierynomus/smbj/issues/152
> https://github.com/hierynomus/smbj/issues/419
> This setting should be made available in the following processors and
> services:
> * GetSmbFile
> * PutSmbFile
> * SmbjClientProviderService
> Edit: It might require some more changes to handle the connections and
> sessions correctly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-12889) Retry Kerberos Login on auth failures in HDFS processors
[ https://issues.apache.org/jira/browse/NIFI-12889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12889: -- Fix Version/s: 2.0.0-M3 Resolution: Fixed Status: Resolved (was: Patch Available) Marked as fixed for 2.0-M3 but we also want a backport into 1.x > Retry Kerberos Login on auth failures in HDFS processors > > > Key: NIFI-12889 > URL: https://issues.apache.org/jira/browse/NIFI-12889 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Matt Burgess >Assignee: Matt Burgess >Priority: Major > Fix For: 2.0.0-M3 > > Time Spent: 3h 50m > Remaining Estimate: 0h > > Currently if a Kerberos authentication failure happens (during ticket > relogin, e.g.) in the HDFS processors, the controller service must be > restarted manually in order for the processors to execute correctly. From the > processors we should reset the HDFS resources on auth failure to simulate a > "restart" of the controller service so relogin can occur correctly. > At a minimum this includes the following processors: > FetchHDFS > GetHDFS > GetHDFSFileInfo > PutHDFS > ListHDFS -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13008) CLI command to upgrade all instances of a versioned flow
[ https://issues.apache.org/jira/browse/NIFI-13008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13008: -- Status: Patch Available (was: In Progress) > CLI command to upgrade all instances of a versioned flow > > > Key: NIFI-13008 > URL: https://issues.apache.org/jira/browse/NIFI-13008 > Project: Apache NiFi > Issue Type: Improvement > Components: Tools and Build >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Labels: backport-needed > > Add a CLI command allowing someone to upgrade all the instances of a given > versioned flow. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13008) CLI command to upgrade all instances of a versioned flow
[ https://issues.apache.org/jira/browse/NIFI-13008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13008: -- Labels: backport-needed (was: ) > CLI command to upgrade all instances of a versioned flow > > > Key: NIFI-13008 > URL: https://issues.apache.org/jira/browse/NIFI-13008 > Project: Apache NiFi > Issue Type: Improvement > Components: Tools and Build >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Labels: backport-needed > > Add a CLI command allowing someone to upgrade all the instances of a given > versioned flow. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13008) CLI command to upgrade all instances of a versioned flow
Pierre Villard created NIFI-13008: - Summary: CLI command to upgrade all instances of a versioned flow Key: NIFI-13008 URL: https://issues.apache.org/jira/browse/NIFI-13008 Project: Apache NiFi Issue Type: Improvement Components: Tools and Build Reporter: Pierre Villard Assignee: Pierre Villard Add a CLI command allowing someone to upgrade all the instances of a given versioned flow. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-12994) Fix NPE when requesting Flow Analysis Results for a Process Group
[ https://issues.apache.org/jira/browse/NIFI-12994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard resolved NIFI-12994. --- Fix Version/s: 2.0.0-M3 Resolution: Fixed > Fix NPE when requesting Flow Analysis Results for a Process Group > - > > Key: NIFI-12994 > URL: https://issues.apache.org/jira/browse/NIFI-12994 > Project: Apache NiFi > Issue Type: Bug >Reporter: Tamas Palfy >Assignee: Tamas Palfy >Priority: Major > Fix For: 2.0.0-M3 > > Time Spent: 20m > Remaining Estimate: 0h > > When requesting Flow Analysis Results for a Process Group the underlying Rule > Violations are checked if registered for the same group id. That group id is > the group id of the violating component. However there can be components that > don't belong to a Process Group, in which case this group id is going to be > null. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12987) Controller Service type should be searchable
[ https://issues.apache.org/jira/browse/NIFI-12987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12987: -- Fix Version/s: 2.0.0-M3 1.26.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Controller Service type should be searchable > > > Key: NIFI-12987 > URL: https://issues.apache.org/jira/browse/NIFI-12987 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Affects Versions: 1.25.0 >Reporter: Michael W Moser >Assignee: Michael W Moser >Priority: Minor > Labels: backport-needed > Fix For: 2.0.0-M3, 1.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently controller service name, uuid, property name, property value and > comments are all searchable. However you cannot search by controller service > type (class name) like you can with other components. Allow the search to > find controller services by type. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12988) Streamline Iceberg Test Utils Dependencies
[
https://issues.apache.org/jira/browse/NIFI-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard updated NIFI-12988:
--
Fix Version/s: 2.0.0-M3
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Streamline Iceberg Test Utils Dependencies
> --
>
> Key: NIFI-12988
> URL: https://issues.apache.org/jira/browse/NIFI-12988
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Minor
> Fix For: 2.0.0-M3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Following the move of {{nifi-hive-test-utils}} to
> {{{}nifi-iceberg-test-utils{}}}, several of the dependencies and exclusions
> can be streamlined to reduce duplication and unnecessary references.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-12984) Bump Snowflake Ingest SDK to 2.1.0
[ https://issues.apache.org/jira/browse/NIFI-12984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12984: -- Status: Patch Available (was: Open) > Bump Snowflake Ingest SDK to 2.1.0 > -- > > Key: NIFI-12984 > URL: https://issues.apache.org/jira/browse/NIFI-12984 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Labels: backport-needed > > Bump Snowflake Ingest SDK to 2.1.0. We keep the JDBC version as-is given the > release notes. See: > [https://docs.snowflake.com/en/release-notes/clients-drivers/ingest-java-sdk-2024] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12984) Bump Snowflake Ingest SDK to 2.1.0
[ https://issues.apache.org/jira/browse/NIFI-12984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12984: -- Labels: backport-needed (was: ) > Bump Snowflake Ingest SDK to 2.1.0 > -- > > Key: NIFI-12984 > URL: https://issues.apache.org/jira/browse/NIFI-12984 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Labels: backport-needed > > Bump Snowflake Ingest SDK to 2.1.0. We keep the JDBC version as-is given the > release notes. See: > [https://docs.snowflake.com/en/release-notes/clients-drivers/ingest-java-sdk-2024] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-12984) Bump Snowflake Ingest SDK to 2.1.0
Pierre Villard created NIFI-12984: - Summary: Bump Snowflake Ingest SDK to 2.1.0 Key: NIFI-12984 URL: https://issues.apache.org/jira/browse/NIFI-12984 Project: Apache NiFi Issue Type: Improvement Components: Extensions Reporter: Pierre Villard Assignee: Pierre Villard Bump Snowflake Ingest SDK to 2.1.0. We keep the JDBC version as-is given the release notes. See: [https://docs.snowflake.com/en/release-notes/clients-drivers/ingest-java-sdk-2024] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12981) Remove Hive 3 Components
[ https://issues.apache.org/jira/browse/NIFI-12981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12981: -- Fix Version/s: 2.0.0-M3 Resolution: Fixed Status: Resolved (was: Patch Available) > Remove Hive 3 Components > > > Key: NIFI-12981 > URL: https://issues.apache.org/jira/browse/NIFI-12981 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 2.0.0-M3 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Following the release of Apache Hive 4.0.0, Apache NiFi components support > Hive 3 should be removed from the main branch. NiFi 2.0.0 Milestone 1 and > Milestone 2 bundles remain available in Maven Central. Future support for > Hive 4 can be considered separately. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12980) Deprecate Hive 3 Components for Removal
[ https://issues.apache.org/jira/browse/NIFI-12980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12980: -- Fix Version/s: 1.26.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Deprecate Hive 3 Components for Removal > --- > > Key: NIFI-12980 > URL: https://issues.apache.org/jira/browse/NIFI-12980 > Project: Apache NiFi > Issue Type: Improvement >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 1.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Apache Hive has released version 4.0.0 incorporating a number changes from > the previous version. Following the NiFI 2.0 Release Goals of removing > support for previous major versions of various components, Hive 3 Processors > should be deprecated on the support branch for subsequent removal from the > main branch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-12975) Limit number of POST on /subjects for Confluent Schema Registry
Pierre Villard created NIFI-12975:
-
Summary: Limit number of POST on /subjects for Confluent Schema
Registry
Key: NIFI-12975
URL: https://issues.apache.org/jira/browse/NIFI-12975
Project: Apache NiFi
Issue Type: Improvement
Components: Extensions
Reporter: Pierre Villard
Right now, when retrieving a schema by ID, we first do
{code:java}
// GET /schemas/ids/{int: id}{code}
but that does not give us everything, so... we get the subjects associated
{code:java}
// GET /schemas/ids/{int: id}/subjects{code}
which is a list of -key or -value depending on what the schema is
associated with for the topic
Then, we recursively use the subjects calling
{code:java}
// POST /subjects/(string: subject){code}
until we get one 200 response. From this response we get all the information we
want.
While this is working, the problem is that NiFi may not be authorized to call
this API for some subjects. So depending on the order of the list of subjects,
we may be causing a lot of 403 errors on the Schema Registry side and its audit
logs.
When the reader is called from a Kafka processor, we may be able to pass the
topic name information that would give us a way to be smarter about which
subjects to call and avoid the 403 errors. That would not solve the problem in
all possible scenarios but that would likely help in most cases.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-12969) Under heavy load, nifi node unable to rejoin cluster, graph modified with temp funnel
[
https://issues.apache.org/jira/browse/NIFI-12969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832247#comment-17832247
]
Pierre Villard commented on NIFI-12969:
---
That is interesting, I'll definitely be extremely interested in whatever you
find to solve this issue.
> Under heavy load, nifi node unable to rejoin cluster, graph modified with
> temp funnel
> -
>
> Key: NIFI-12969
> URL: https://issues.apache.org/jira/browse/NIFI-12969
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.24.0, 2.0.0-M2
>Reporter: Nissim Shiman
>Assignee: Nissim Shiman
>Priority: Major
>
> Under heavy load, if a node leaves the cluster (due to heartbeat time out),
> many times it is unable to rejoin the cluster.
> The nodes' graph will have been modified with a temp-funnel as well.
> Appears to be some sort of [timing
> issue|https://github.com/apache/nifi/blob/rel/nifi-2.0.0-M2/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-components/src/main/java/org/apache/nifi/connectable/StandardConnection.java#L298]
> # To reproduce, on a nifi cluster of three nodes, set up:
> 2 GenerateFlowFile processors -> PG
> Inside PG:
> inputPort -> UpdateAttribute
> # Keep all defaults except for the following:
> For UpdateAttribute terminate the success relationship
> One of the GenerateFlowFile processors can be disabled,
> the other one should have Run Schedule to be 0 min (this will allow for the
> heavy load)
> # In nifi.properties (on all 3 nodes) to allow for nodes to fall out of the
> cluster, set: nifi.cluster.protocol.heartbeat.interval=2 sec (default is 5)
> nifi.cluster.protocol.heartbeat.missable.max=1 (default is 8)
> Restart nifi. Start flow. The nodes will quickly fall out and rejoin cluster.
> After a few minutes one will likely not be able to rejoin. The graph for
> that node will have the disabled GenerateFlowFile now pointing to a funnel (a
> temp-funnel) instead of the PG
> Stack trace on that nodes nifi-app.log will look like this: (this is from
> 2.0.0-M2):
> {code:java}
> 2024-03-28 13:55:19,395 INFO [Reconnect to Cluster]
> o.a.nifi.controller.StandardFlowService Node disconnected due to Failed to
> properly handle Reconnection request due to org.apache.nifi.control
> ler.serialization.FlowSynchronizationException: Failed to connect node to
> cluster because local flow controller partially updated. Administrator should
> disconnect node and review flow for corrup
> tion.
> 2024-03-28 13:55:19,395 ERROR [Reconnect to Cluster]
> o.a.nifi.controller.StandardFlowService Handling reconnection request failed
> due to: org.apache.nifi.controller.serialization.FlowSynchroniza
> tionException: Failed to connect node to cluster because local flow
> controller partially updated. Administrator should disconnect node and review
> flow for corruption.
> org.apache.nifi.controller.serialization.FlowSynchronizationException: Failed
> to connect node to cluster because local flow controller partially updated.
> Administrator should disconnect node and
> review flow for corruption.
> at
> org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:985)
> at
> org.apache.nifi.controller.StandardFlowService.handleReconnectionRequest(StandardFlowService.java:655)
> at
> org.apache.nifi.controller.StandardFlowService$1.run(StandardFlowService.java:384)
> at java.base/java.lang.Thread.run(Thread.java:1583)
> Caused by:
> org.apache.nifi.controller.serialization.FlowSynchronizationException:
> java.lang.IllegalStateException: Cannot change destination of Connection
> because FlowFiles from this Connection
> are currently held by LocalPort[id=99213c00-78ca-4848-112f-5454cc20656b,
> type=INPUT_PORT, name=inputPort, group=innerPG]
> at
> org.apache.nifi.controller.serialization.VersionedFlowSynchronizer.synchronizeFlow(VersionedFlowSynchronizer.java:472)
> at
> org.apache.nifi.controller.serialization.VersionedFlowSynchronizer.sync(VersionedFlowSynchronizer.java:223)
> at
> org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1740)
> at
> org.apache.nifi.persistence.StandardFlowConfigurationDAO.load(StandardFlowConfigurationDAO.java:91)
> at
> org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:805)
> at
> org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:954)
> ... 3 common frames omitted
> Caused by: java.lang.IllegalStateException: Cannot change destination of
> Connection because FlowFiles from this Connection are currently held by
> LocalPort[id=99213c00-78ca-4848-112f-5454cc20656b
> ,
[jira] [Commented] (NIFI-12969) Under heavy load, nifi node unable to rejoin cluster, graph modified with temp funnel
[
https://issues.apache.org/jira/browse/NIFI-12969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832223#comment-17832223
]
Pierre Villard commented on NIFI-12969:
---
[~Nissim Shiman] - I think there may be good chances that this is solved with
NIFI-12232
> Under heavy load, nifi node unable to rejoin cluster, graph modified with
> temp funnel
> -
>
> Key: NIFI-12969
> URL: https://issues.apache.org/jira/browse/NIFI-12969
> Project: Apache NiFi
> Issue Type: Bug
>Affects Versions: 1.24.0, 2.0.0-M2
>Reporter: Nissim Shiman
>Assignee: Nissim Shiman
>Priority: Major
>
> Under heavy load, if a node leaves the cluster (due to heartbeat time out),
> many times it is unable to rejoin the cluster.
> The nodes' graph will have been modified with a temp-funnel as well.
> Appears to be some sort of [timing
> issue|https://github.com/apache/nifi/blob/rel/nifi-2.0.0-M2/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-components/src/main/java/org/apache/nifi/connectable/StandardConnection.java#L298]
> # To reproduce, on a nifi cluster of three nodes, set up:
> 2 GenerateFlowFile processors -> PG
> Inside PG:
> inputPort -> UpdateAttribute
> # Keep all defaults except for the following:
> For UpdateAttribute terminate the success relationship
> One of the GenerateFlowFile processors can be disabled,
> the other one should have Run Schedule to be 0 min (this will allow for the
> heavy load)
> # In nifi.properties (on all 3 nodes) to allow for nodes to fall out of the
> cluster, set: nifi.cluster.protocol.heartbeat.interval=2 sec (default is 5)
> nifi.cluster.protocol.heartbeat.missable.max=1 (default is 8)
> Restart nifi. Start flow. The nodes will quickly fall out and rejoin cluster.
> After a few minutes one will likely not be able to rejoin. The graph for
> that node will have the disabled GenerateFlowFile now pointing to a funnel (a
> temp-funnel) instead of the PG
> Stack trace on that nodes nifi-app.log will look like this: (this is from
> 2.0.0-M2):
> {code:java}
> 2024-03-28 13:55:19,395 INFO [Reconnect to Cluster]
> o.a.nifi.controller.StandardFlowService Node disconnected due to Failed to
> properly handle Reconnection request due to org.apache.nifi.control
> ler.serialization.FlowSynchronizationException: Failed to connect node to
> cluster because local flow controller partially updated. Administrator should
> disconnect node and review flow for corrup
> tion.
> 2024-03-28 13:55:19,395 ERROR [Reconnect to Cluster]
> o.a.nifi.controller.StandardFlowService Handling reconnection request failed
> due to: org.apache.nifi.controller.serialization.FlowSynchroniza
> tionException: Failed to connect node to cluster because local flow
> controller partially updated. Administrator should disconnect node and review
> flow for corruption.
> org.apache.nifi.controller.serialization.FlowSynchronizationException: Failed
> to connect node to cluster because local flow controller partially updated.
> Administrator should disconnect node and
> review flow for corruption.
> at
> org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:985)
> at
> org.apache.nifi.controller.StandardFlowService.handleReconnectionRequest(StandardFlowService.java:655)
> at
> org.apache.nifi.controller.StandardFlowService$1.run(StandardFlowService.java:384)
> at java.base/java.lang.Thread.run(Thread.java:1583)
> Caused by:
> org.apache.nifi.controller.serialization.FlowSynchronizationException:
> java.lang.IllegalStateException: Cannot change destination of Connection
> because FlowFiles from this Connection
> are currently held by LocalPort[id=99213c00-78ca-4848-112f-5454cc20656b,
> type=INPUT_PORT, name=inputPort, group=innerPG]
> at
> org.apache.nifi.controller.serialization.VersionedFlowSynchronizer.synchronizeFlow(VersionedFlowSynchronizer.java:472)
> at
> org.apache.nifi.controller.serialization.VersionedFlowSynchronizer.sync(VersionedFlowSynchronizer.java:223)
> at
> org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1740)
> at
> org.apache.nifi.persistence.StandardFlowConfigurationDAO.load(StandardFlowConfigurationDAO.java:91)
> at
> org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:805)
> at
> org.apache.nifi.controller.StandardFlowService.loadFromConnectionResponse(StandardFlowService.java:954)
> ... 3 common frames omitted
> Caused by: java.lang.IllegalStateException: Cannot change destination of
> Connection because FlowFiles from this Connection are currently held by
> LocalPort[id=99213c00-78ca-4848-112f-5454cc20656b
> , type=INPUT_PORT,
[jira] [Created] (NIFI-12973) Add Process Group scope to Flow Analysis rules
Pierre Villard created NIFI-12973: - Summary: Add Process Group scope to Flow Analysis rules Key: NIFI-12973 URL: https://issues.apache.org/jira/browse/NIFI-12973 Project: Apache NiFi Issue Type: Improvement Components: Extensions Reporter: Pierre Villard I think it'd be useful to have an optional property in all Flow Analysis rules to scope a rule execution to a specific process group (and its embedded process groups). Most NiFi users are using NiFi in a multi tenant way and are dedicating a process group to a given team. Different rules may apply across different teams hence the advantage of scoping a rule to a process group (when it makes sense for the rule). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-12924) FlowAnalysis streamline
[ https://issues.apache.org/jira/browse/NIFI-12924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard resolved NIFI-12924. --- Fix Version/s: 2.0.0-M3 Resolution: Fixed > FlowAnalysis streamline > --- > > Key: NIFI-12924 > URL: https://issues.apache.org/jira/browse/NIFI-12924 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Tamas Palfy >Assignee: Tamas Palfy >Priority: Major > Fix For: 2.0.0-M3 > > Time Spent: 20m > Remaining Estimate: 0h > > Have flow analysis occur as needed instead of as demanded or regularly. When > the flow is modified occurs or there are changes among the rules a background > thread will run a flow analysis within 5 seconds. Otherwise no analysis > occurs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12972) UI - Improve listing of relationships for a connection
[ https://issues.apache.org/jira/browse/NIFI-12972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12972: -- Status: Patch Available (was: Open) > UI - Improve listing of relationships for a connection > -- > > Key: NIFI-12972 > URL: https://issues.apache.org/jira/browse/NIFI-12972 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > > Consider a RouteOnAttribute processor with "Route to Property name" with many > dynamic properties. This will lead to many relationships (r1, r2, r3, etc). > Now consider an UpdateAttribute processor. > Connect RouteOnAttribute to this UpdateAttribute processor and select r1 and > r3. > If the two processors are stopped, opening the configuration of the > connection will show an alphabetically sorted list of the ALL the > relationships (of the RouteOnAttribute processor) with checkboxes and r1/r3 > will show as checked. > Now, if one of the two processors is started, opening the configuration of > the connection will show an alphabetically sorted list of the ALL the > relationships (of the RouteOnAttribute processor) and the only distinction > will be that r1 and r3 will be in bold. > When having many connections (think 50+), just showing the selected > relationships in bold is not super user friendly. It's really hard to > distinguish the bold names in a very long list of names. > When one of the processors is running and we're just showing the details of > the connection without the option to change the list of selected > relationships for that connection, I suggest that we only display the list of > the selected relationships. > For reference, the related code is here: > https://github.com/apache/nifi/blob/main/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui/src/main/webapp/js/nf/nf-connection-details.js#L520 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (NIFI-12972) UI - Improve listing of relationships for a connection
[ https://issues.apache.org/jira/browse/NIFI-12972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard reassigned NIFI-12972: - Assignee: Pierre Villard > UI - Improve listing of relationships for a connection > -- > > Key: NIFI-12972 > URL: https://issues.apache.org/jira/browse/NIFI-12972 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > > Consider a RouteOnAttribute processor with "Route to Property name" with many > dynamic properties. This will lead to many relationships (r1, r2, r3, etc). > Now consider an UpdateAttribute processor. > Connect RouteOnAttribute to this UpdateAttribute processor and select r1 and > r3. > If the two processors are stopped, opening the configuration of the > connection will show an alphabetically sorted list of the ALL the > relationships (of the RouteOnAttribute processor) with checkboxes and r1/r3 > will show as checked. > Now, if one of the two processors is started, opening the configuration of > the connection will show an alphabetically sorted list of the ALL the > relationships (of the RouteOnAttribute processor) and the only distinction > will be that r1 and r3 will be in bold. > When having many connections (think 50+), just showing the selected > relationships in bold is not super user friendly. It's really hard to > distinguish the bold names in a very long list of names. > When one of the processors is running and we're just showing the details of > the connection without the option to change the list of selected > relationships for that connection, I suggest that we only display the list of > the selected relationships. > For reference, the related code is here: > https://github.com/apache/nifi/blob/main/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui/src/main/webapp/js/nf/nf-connection-details.js#L520 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12972) UI - Improve listing of relationships for a connection
[ https://issues.apache.org/jira/browse/NIFI-12972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12972: -- Description: Consider a RouteOnAttribute processor with "Route to Property name" with many dynamic properties. This will lead to many relationships (r1, r2, r3, etc). Now consider an UpdateAttribute processor. Connect RouteOnAttribute to this UpdateAttribute processor and select r1 and r3. If the two processors are stopped, opening the configuration of the connection will show an alphabetically sorted list of the ALL the relationships (of the RouteOnAttribute processor) with checkboxes and r1/r3 will show as checked. Now, if one of the two processors is started, opening the configuration of the connection will show an alphabetically sorted list of the ALL the relationships (of the RouteOnAttribute processor) and the only distinction will be that r1 and r3 will be in bold. When having many connections (think 50+), just showing the selected relationships in bold is not super user friendly. It's really hard to distinguish the bold names in a very long list of names. When one of the processors is running and we're just showing the details of the connection without the option to change the list of selected relationships for that connection, I suggest that we only display the list of the selected relationships. For reference, the related code is here: https://github.com/apache/nifi/blob/main/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui/src/main/webapp/js/nf/nf-connection-details.js#L520 was: Consider a RouteOnAttribute processor with "Route to Property name" with many dynamic properties. This will lead to many relationships (r1, r2, r3, etc). Now consider an UpdateAttribute processor. Connect RouteOnAttribute to this UpdateAttribute processor and select r1 and r3. If the two processors are stopped, opening the configuration of the connection will show an alphabetically sorted list of the ALL the relationships (of the RouteOnAttribute processor) with checkboxes and r1/r3 will show as checked. Now, if one of the two processors is started, opening the configuration of the connection will show an alphabetically sorted list of the ALL the relationships (of the RouteOnAttribute processor) and the only distinction will be that r1 and r3 will be in bold. When having many connections (think 50+), just showing the selected relationships in bold is not super user friendly. It's really hard to distinguish the bold names in a very long list of names. When one of the processors is running and we're just showing the details of the connection without the option to change the list of selected relationships for that connection, I suggest that we only display the list of the selected relationships. > UI - Improve listing of relationships for a connection > -- > > Key: NIFI-12972 > URL: https://issues.apache.org/jira/browse/NIFI-12972 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Reporter: Pierre Villard >Priority: Major > > Consider a RouteOnAttribute processor with "Route to Property name" with many > dynamic properties. This will lead to many relationships (r1, r2, r3, etc). > Now consider an UpdateAttribute processor. > Connect RouteOnAttribute to this UpdateAttribute processor and select r1 and > r3. > If the two processors are stopped, opening the configuration of the > connection will show an alphabetically sorted list of the ALL the > relationships (of the RouteOnAttribute processor) with checkboxes and r1/r3 > will show as checked. > Now, if one of the two processors is started, opening the configuration of > the connection will show an alphabetically sorted list of the ALL the > relationships (of the RouteOnAttribute processor) and the only distinction > will be that r1 and r3 will be in bold. > When having many connections (think 50+), just showing the selected > relationships in bold is not super user friendly. It's really hard to > distinguish the bold names in a very long list of names. > When one of the processors is running and we're just showing the details of > the connection without the option to change the list of selected > relationships for that connection, I suggest that we only display the list of > the selected relationships. > For reference, the related code is here: > https://github.com/apache/nifi/blob/main/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui/src/main/webapp/js/nf/nf-connection-details.js#L520 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-12972) UI - Improve listing of relationships for a connection
Pierre Villard created NIFI-12972: - Summary: UI - Improve listing of relationships for a connection Key: NIFI-12972 URL: https://issues.apache.org/jira/browse/NIFI-12972 Project: Apache NiFi Issue Type: Improvement Components: Core UI Affects Versions: 2.0.0-M2, 1.25.0 Reporter: Pierre Villard Consider a RouteOnAttribute processor with "Route to Property name" with many dynamic properties. This will lead to many relationships (r1, r2, r3, etc). Now consider an UpdateAttribute processor. Connect RouteOnAttribute to this UpdateAttribute processor and select r1 and r3. If the two processors are stopped, opening the configuration of the connection will show an alphabetically sorted list of the ALL the relationships (of the RouteOnAttribute processor) with checkboxes and r1/r3 will show as checked. Now, if one of the two processors is started, opening the configuration of the connection will show an alphabetically sorted list of the ALL the relationships (of the RouteOnAttribute processor) and the only distinction will be that r1 and r3 will be in bold. When having many connections (think 50+), just showing the selected relationships in bold is not super user friendly. It's really hard to distinguish the bold names in a very long list of names. When one of the processors is running and we're just showing the details of the connection without the option to change the list of selected relationships for that connection, I suggest that we only display the list of the selected relationships. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12972) UI - Improve listing of relationships for a connection
[ https://issues.apache.org/jira/browse/NIFI-12972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12972: -- Affects Version/s: (was: 1.25.0) (was: 2.0.0-M2) > UI - Improve listing of relationships for a connection > -- > > Key: NIFI-12972 > URL: https://issues.apache.org/jira/browse/NIFI-12972 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Reporter: Pierre Villard >Priority: Major > > Consider a RouteOnAttribute processor with "Route to Property name" with many > dynamic properties. This will lead to many relationships (r1, r2, r3, etc). > Now consider an UpdateAttribute processor. > Connect RouteOnAttribute to this UpdateAttribute processor and select r1 and > r3. > If the two processors are stopped, opening the configuration of the > connection will show an alphabetically sorted list of the ALL the > relationships (of the RouteOnAttribute processor) with checkboxes and r1/r3 > will show as checked. > Now, if one of the two processors is started, opening the configuration of > the connection will show an alphabetically sorted list of the ALL the > relationships (of the RouteOnAttribute processor) and the only distinction > will be that r1 and r3 will be in bold. > When having many connections (think 50+), just showing the selected > relationships in bold is not super user friendly. It's really hard to > distinguish the bold names in a very long list of names. > When one of the processors is running and we're just showing the details of > the connection without the option to change the list of selected > relationships for that connection, I suggest that we only display the list of > the selected relationships. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12966) Upgrade Netty to 4.1.108
[ https://issues.apache.org/jira/browse/NIFI-12966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12966: -- Fix Version/s: 2.0.0-M3 1.26.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Netty to 4.1.108 > > > Key: NIFI-12966 > URL: https://issues.apache.org/jira/browse/NIFI-12966 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Labels: backport-needed > Fix For: 2.0.0-M3, 1.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Netty dependencies should be upgraded to > [4.1.108|https://netty.io/news/2024/03/21/4-1-108-Final.html] to incorporate > several improvements and a resolution for CVE-2024-29025 related to HTTP POST > request decoding. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12965) Upgrade Guava to 33.1.0
[ https://issues.apache.org/jira/browse/NIFI-12965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12965: -- Fix Version/s: 2.0.0-M3 Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Guava to 33.1.0 > --- > > Key: NIFI-12965 > URL: https://issues.apache.org/jira/browse/NIFI-12965 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Labels: dependency-upgrade > Fix For: 2.0.0-M3 > > Time Spent: 20m > Remaining Estimate: 0h > > Google Guava dependencies should be upgraded to > [33.1.0|https://github.com/google/guava/releases/tag/v33.1.0] to incorporate > bug fixes and improvements. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12945) Upgrade Commons Configuration and Guava Transitive Dependencies
[ https://issues.apache.org/jira/browse/NIFI-12945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12945: -- Fix Version/s: 2.0.0-M3 Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Commons Configuration and Guava Transitive Dependencies > --- > > Key: NIFI-12945 > URL: https://issues.apache.org/jira/browse/NIFI-12945 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 2.0.0-M3 > > Time Spent: 20m > Remaining Estimate: 0h > > Recent upgrades to Apache Commons Configuration 2.10.1 and should be > propagated to transitive dependencies in several extension modules. The > extension modules with transitive dependencies include Hadoop and Hive > components. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12955) Update Dependency Check Suppressions
[ https://issues.apache.org/jira/browse/NIFI-12955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12955: -- Fix Version/s: 2.0.0-M3 Resolution: Fixed Status: Resolved (was: Patch Available) > Update Dependency Check Suppressions > > > Key: NIFI-12955 > URL: https://issues.apache.org/jira/browse/NIFI-12955 > Project: Apache NiFi > Issue Type: Improvement > Components: Tools and Build >Reporter: David Handermann >Assignee: David Handermann >Priority: Minor > Fix For: 2.0.0-M3 > > Time Spent: 20m > Remaining Estimate: 0h > > The OWASP Dependency Check suppressions configuration includes a number of > items that no longer apply based on library upgrades and improvements to the > scanner itself. Unused suppressions should be removed and others should be > added as needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12957) Upgrade Azure SDK BOM to 1.2.21
[ https://issues.apache.org/jira/browse/NIFI-12957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12957: -- Fix Version/s: 2.0.0-M3 1.26.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Azure SDK BOM to 1.2.21 > --- > > Key: NIFI-12957 > URL: https://issues.apache.org/jira/browse/NIFI-12957 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Labels: backport-needed > Fix For: 2.0.0-M3, 1.26.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The Azure SDK BOM dependency should be upgraded to > [1.2.21|https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/boms/azure-sdk-bom/CHANGELOG.md] > to incorporate the latest set of Azure libraries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12962) Upgrade Spring Framework to 6.1.5
[ https://issues.apache.org/jira/browse/NIFI-12962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12962: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Upgrade Spring Framework to 6.1.5 > - > > Key: NIFI-12962 > URL: https://issues.apache.org/jira/browse/NIFI-12962 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 2.0.0-M3 > > Time Spent: 20m > Remaining Estimate: 0h > > Spring Framework dependencies should be upgraded to > [6.1.5|https://github.com/spring-projects/spring-framework/releases/tag/v6.1.5] > to align both NiFi and NiFi Registry on the same version. > Spring 6.1.0 introduced changes in AspectJ annotation expression parsing, > resulting in test failures for Auditor classes. Enabling parameters during > Java compilation as described in [explicit argument > names|https://docs.spring.io/spring-framework/reference/core/aop/ataspectj/advice.html#aop-ataspectj-advice-params-names-explicit] > documentation for Spring Framework resolves expression parsing and allows > the AspectJ annotations to work without changes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-12888) OAuth2 token refresh doesn't work in Email processors
[ https://issues.apache.org/jira/browse/NIFI-12888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard resolved NIFI-12888. --- Fix Version/s: 2.0.0-M3 1.26.0 Resolution: Fixed > OAuth2 token refresh doesn't work in Email processors > - > > Key: NIFI-12888 > URL: https://issues.apache.org/jira/browse/NIFI-12888 > Project: Apache NiFi > Issue Type: Bug >Reporter: Tamas Palfy >Assignee: Tamas Palfy >Priority: Major > Fix For: 2.0.0-M3, 1.26.0 > > Time Spent: 1h > Remaining Estimate: 0h > > ConsumeIMAP and ConsumePOP3 both inherit the AbstractEmailProcessor in which > the OAuth2 token refresh handling is not handled properly. > The object that is receiving the emails is created and finalized only once. > When the token expires, nothing makes to refresh logic to run. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12954) Upgrade AWS BOM references
[ https://issues.apache.org/jira/browse/NIFI-12954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12954: -- Status: Patch Available (was: Open) > Upgrade AWS BOM references > -- > > Key: NIFI-12954 > URL: https://issues.apache.org/jira/browse/NIFI-12954 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > > Upgrade AWS BOM references > * 1.x from 1.12.637 to 1.12.686 > * 2.x from 2.23.3 to 2.25.16 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-12954) Upgrade AWS BOM references
Pierre Villard created NIFI-12954: - Summary: Upgrade AWS BOM references Key: NIFI-12954 URL: https://issues.apache.org/jira/browse/NIFI-12954 Project: Apache NiFi Issue Type: Improvement Components: Extensions Reporter: Pierre Villard Assignee: Pierre Villard Upgrade AWS BOM references * 1.x from 1.12.637 to 1.12.686 * 2.x from 2.23.3 to 2.25.16 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-12953) Upgrade AWS Kinesis client to 2.5.7
[ https://issues.apache.org/jira/browse/NIFI-12953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-12953: -- Status: Patch Available (was: Open) > Upgrade AWS Kinesis client to 2.5.7 > --- > > Key: NIFI-12953 > URL: https://issues.apache.org/jira/browse/NIFI-12953 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Upgrade AWS Kinesis client to 2.5.7 -- This message was sent by Atlassian Jira (v8.20.10#820010)
