[jira] [Created] (NIFI-7671) Support Message Selector in ConsumeJMS processor
Marc Recht created NIFI-7671: Summary: Support Message Selector in ConsumeJMS processor Key: NIFI-7671 URL: https://issues.apache.org/jira/browse/NIFI-7671 Project: Apache NiFi Issue Type: Improvement Components: Extensions Reporter: Marc Recht The _ConsumeJMS_ processor currently does not support having a message selector. Unlike, the (deprecated) _GetJMSQueue_ processor. In my opinion message selector support would be a valuable improvement to _ConsumeJMS._ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [nifi] kent-nguyen commented on pull request #4422: NIFI-6332 - Add Cache Control property to PutS3Object processor
kent-nguyen commented on pull request #4422: URL: https://github.com/apache/nifi/pull/4422#issuecomment-663342359 Apologies for the force push, realise now that wasn't a good idea. Was trying to trigger CI again since it looks to have encountered a transient error, but I'll ignore that in future. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi] kent-nguyen commented on a change in pull request #4422: NIFI-6332 - Add Cache Control property to PutS3Object processor
kent-nguyen commented on a change in pull request #4422:
URL: https://github.com/apache/nifi/pull/4422#discussion_r459806345
##
File path:
nifi-nar-bundles/nifi-aws-bundle/nifi-aws-processors/src/main/java/org/apache/nifi/processors/aws/s3/PutS3Object.java
##
@@ -152,6 +153,14 @@
.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
.build();
+public static final PropertyDescriptor CACHE_CONTROL = new
PropertyDescriptor.Builder()
+.name("Cache Control")
+.displayName("Cache Control")
+.description("Sets the Cache-Control HTTP header. Multiple
directives are comma-separated.")
Review comment:
Hi @turcsanyip Thank you for checking my PR. It's great to hear you ran
the tests on it. I had carefully tested it on my local too.
In contrast to the Content Type property, which can get the MIME string from
the flow file itself, the flow file metadata wouldn't normally be relevant for
the Cache Control property. I felt this was similar in nature to properties
like Storage Class and Server Side Encryption, which are on set on the
processor and do not support expression language.
I have updated the description as your suggestion. Thank you again.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi] alopresto opened a new pull request #4427: NIFI-7638 Added PBE AEAD algorithm for flow sensitive properties
alopresto opened a new pull request #4427:
URL: https://github.com/apache/nifi/pull/4427
## This PR is dependent on PR 4421 and should not be merged until that one is
### The actual changes are only in `StringEncryptor`, `StringEncryptorTest`,
a single method scope change in `RandomIVPBECipherProvider`, and
`administration-guide.adoc`.
Thank you for submitting a contribution to Apache NiFi.
Please provide a short description of the PR here:
Description of PR
_Adds a new algorithm for `nifi.sensitive.props.algorithm` to support robust
encryption of sensitive flow values._
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?
- [x] Does your PR title start with **NIFI-** where is the JIRA
number you are trying to resolve? Pay particular attention to the hyphen "-"
character.
- [x] Has your PR been rebased against the latest commit within the target
branch (typically `main`)?
- [x] Is your initial contribution a single, squashed commit? _Additional
commits in response to PR reviewer feedback should be made on this branch and
pushed to allow change tracking. Do not `squash` or use `--force` when pushing
to allow for clean monitoring of changes._
### For code changes:
- [x] Have you ensured that the full suite of tests is executed via `mvn
-Pcontrib-check clean install` at the root `nifi` folder?
- [x] Have you written or updated unit tests to verify your changes?
- [ ] Have you verified that the full build is successful on JDK 8?
- [x] Have you verified that the full build is successful on JDK 11?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] If applicable, have you updated the `LICENSE` file, including the main
`LICENSE` file under `nifi-assembly`?
- [ ] If applicable, have you updated the `NOTICE` file, including the main
`NOTICE` file found under `nifi-assembly`?
- [ ] If adding new Properties, have you added `.displayName` in addition to
.name (programmatic access) for each of the new properties?
### For documentation related changes:
- [x] Have you ensured that format looks appropriate for the output in which
it is rendered?
### Note:
Please ensure that once the PR is submitted, you check GitHub Actions CI for
build issues and submit an update to your PR as soon as possible.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Created] (NIFI-7670) Implement flow migration for PBE AEAD algorithms in Encrypt-Config toolkit
Andy LoPresto created NIFI-7670: --- Summary: Implement flow migration for PBE AEAD algorithms in Encrypt-Config toolkit Key: NIFI-7670 URL: https://issues.apache.org/jira/browse/NIFI-7670 Project: Apache NiFi Issue Type: Improvement Components: Tools and Build Affects Versions: 1.12.0 Reporter: Andy LoPresto Assignee: Andy LoPresto The toolkit does not support the new PBE AEAD algorithm because it is not a standard JCE algorithm (it is a custom combination of a KDF and cipher algorithm). The toolkit should be enhanced to support the full range of new algorithms introduced by NIFI-7668 (or at a minimum the custom algorithm introduced in NIFI-7638). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7668) Add configurable PBE AEAD algorithms to flow encryption
[
https://issues.apache.org/jira/browse/NIFI-7668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-7668:
Affects Version/s: (was: 1.11.4)
1.12.0
> Add configurable PBE AEAD algorithms to flow encryption
> ---
>
> Key: NIFI-7668
> URL: https://issues.apache.org/jira/browse/NIFI-7668
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Configuration, Core Framework
>Affects Versions: 1.12.0
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>Priority: Major
> Labels: aead, configuration, encryption, pbe, security
>
> NIFI-7638 introduced a single custom PBE algorithm (pair for 128/256-bit
> keys) which provided AEAD semantics using Argon2 for key derivation and
> AES-G/CM for authenticated encryption. This solution was a stop gap to allow
> more robust encryption than AES-CBC without modifying the
> {{EncryptionMethod}}, which is a single definition of encryption algorithms
> and (supposed) KDFs referenced throughout the codebase.
> Introducing changes to {{EncryptionMethod}} would have required massive
> regression testing, further support changes to {{EncryptContent}}, encrypted
> repository implementations, multiple documentation changes, etc. This change
> allows for a single custom algorithm which makes reasonable default decisions
> around cost parameters and algorithm selection, meeting the user requirements
> without demanding far-reaching changes.
> Instead, this ticket proposes an intentional enhancement to the
> {{nifi.properties}} structure to add a new {{nifi.sensitive.props.kdf}}
> property to complement the existing {{nifi.sensitive.props.algorithm}}
> property. This will allow arbitrary secure KDFs (Argon2, bcrypt, scrypt,
> PBKDF2) to be specified with custom cost parameters and combined with any
> keyed encryption algorithm (AES-CBC, AES-G/CM, AES-CTR) to derive a key and
> encrypt the flow sensitive properties.
> For backward compatibility, as this is likely to go in a 1.13.0 release, not
> a major release, an existing {{nifi.properties}} file will work fine. If the
> {{nifi.sensitive.props.kdf}} value is not specified, it will not be used,
> which is acceptable for all existing {{EncryptionMethod}} values which are
> already supported by the {{StringEncryptor}} class. If a _new_ algorithm is
> specified (e.g. one of the raw keyed algorithms), the KDF will need to be
> present and will be checked for appropriateness and cost parameter validity.
> No default value changes will be made. Thus, this will only affect
> security-conscious users who explicitly change those values to reflect more
> robust key derivation and data protection algorithm choices.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (NIFI-7669) Add flow protection key caching mechanism for derived keys
Andy LoPresto created NIFI-7669: --- Summary: Add flow protection key caching mechanism for derived keys Key: NIFI-7669 URL: https://issues.apache.org/jira/browse/NIFI-7669 Project: Apache NiFi Issue Type: Improvement Components: Configuration, Core Framework Affects Versions: 1.12.0 Reporter: Andy LoPresto Assignee: Andy LoPresto The specific algorithm introduced in NIFI-7638 introduces a ~1 sec delay in every encryption operation (which occurs during every flow synchronization and serialization to disk) due to the Argon2 KDF process. This is an acceptable tradeoff for security-conscious users at this time, but can be improved through a key caching mechanism in memory. Deriving the key once at application startup and using it directly will remove this delay, and the key cannot change without an application restart. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-7668) Add configurable PBE AEAD algorithms to flow encryption
[
https://issues.apache.org/jira/browse/NIFI-7668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17164087#comment-17164087
]
Andy LoPresto commented on NIFI-7668:
-
The specific algorithm introduced in NIFI-7638 also introduces a ~1 sec delay
in every encryption operation (which occurs during every flow synchronization
and serialization to disk) due to the Argon2 KDF process. This is an acceptable
tradeoff for security-conscious users at this time, but can be improved through
a key caching mechanism in memory TBA.
> Add configurable PBE AEAD algorithms to flow encryption
> ---
>
> Key: NIFI-7668
> URL: https://issues.apache.org/jira/browse/NIFI-7668
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Configuration, Core Framework
>Affects Versions: 1.11.4
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
>Priority: Major
> Labels: aead, configuration, encryption, pbe, security
>
> NIFI-7638 introduced a single custom PBE algorithm (pair for 128/256-bit
> keys) which provided AEAD semantics using Argon2 for key derivation and
> AES-G/CM for authenticated encryption. This solution was a stop gap to allow
> more robust encryption than AES-CBC without modifying the
> {{EncryptionMethod}}, which is a single definition of encryption algorithms
> and (supposed) KDFs referenced throughout the codebase.
> Introducing changes to {{EncryptionMethod}} would have required massive
> regression testing, further support changes to {{EncryptContent}}, encrypted
> repository implementations, multiple documentation changes, etc. This change
> allows for a single custom algorithm which makes reasonable default decisions
> around cost parameters and algorithm selection, meeting the user requirements
> without demanding far-reaching changes.
> Instead, this ticket proposes an intentional enhancement to the
> {{nifi.properties}} structure to add a new {{nifi.sensitive.props.kdf}}
> property to complement the existing {{nifi.sensitive.props.algorithm}}
> property. This will allow arbitrary secure KDFs (Argon2, bcrypt, scrypt,
> PBKDF2) to be specified with custom cost parameters and combined with any
> keyed encryption algorithm (AES-CBC, AES-G/CM, AES-CTR) to derive a key and
> encrypt the flow sensitive properties.
> For backward compatibility, as this is likely to go in a 1.13.0 release, not
> a major release, an existing {{nifi.properties}} file will work fine. If the
> {{nifi.sensitive.props.kdf}} value is not specified, it will not be used,
> which is acceptable for all existing {{EncryptionMethod}} values which are
> already supported by the {{StringEncryptor}} class. If a _new_ algorithm is
> specified (e.g. one of the raw keyed algorithms), the KDF will need to be
> present and will be checked for appropriateness and cost parameter validity.
> No default value changes will be made. Thus, this will only affect
> security-conscious users who explicitly change those values to reflect more
> robust key derivation and data protection algorithm choices.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (NIFI-7668) Add configurable PBE AEAD algorithms to flow encryption
Andy LoPresto created NIFI-7668:
---
Summary: Add configurable PBE AEAD algorithms to flow encryption
Key: NIFI-7668
URL: https://issues.apache.org/jira/browse/NIFI-7668
Project: Apache NiFi
Issue Type: Improvement
Components: Configuration, Core Framework
Affects Versions: 1.11.4
Reporter: Andy LoPresto
Assignee: Andy LoPresto
NIFI-7638 introduced a single custom PBE algorithm (pair for 128/256-bit keys)
which provided AEAD semantics using Argon2 for key derivation and AES-G/CM for
authenticated encryption. This solution was a stop gap to allow more robust
encryption than AES-CBC without modifying the {{EncryptionMethod}}, which is a
single definition of encryption algorithms and (supposed) KDFs referenced
throughout the codebase.
Introducing changes to {{EncryptionMethod}} would have required massive
regression testing, further support changes to {{EncryptContent}}, encrypted
repository implementations, multiple documentation changes, etc. This change
allows for a single custom algorithm which makes reasonable default decisions
around cost parameters and algorithm selection, meeting the user requirements
without demanding far-reaching changes.
Instead, this ticket proposes an intentional enhancement to the
{{nifi.properties}} structure to add a new {{nifi.sensitive.props.kdf}}
property to complement the existing {{nifi.sensitive.props.algorithm}}
property. This will allow arbitrary secure KDFs (Argon2, bcrypt, scrypt,
PBKDF2) to be specified with custom cost parameters and combined with any keyed
encryption algorithm (AES-CBC, AES-G/CM, AES-CTR) to derive a key and encrypt
the flow sensitive properties.
For backward compatibility, as this is likely to go in a 1.13.0 release, not a
major release, an existing {{nifi.properties}} file will work fine. If the
{{nifi.sensitive.props.kdf}} value is not specified, it will not be used, which
is acceptable for all existing {{EncryptionMethod}} values which are already
supported by the {{StringEncryptor}} class. If a _new_ algorithm is specified
(e.g. one of the raw keyed algorithms), the KDF will need to be present and
will be checked for appropriateness and cost parameter validity. No default
value changes will be made. Thus, this will only affect security-conscious
users who explicitly change those values to reflect more robust key derivation
and data protection algorithm choices.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [nifi] mtien-apache commented on pull request #4421: NIFI-7122 Introduced improvements to EncryptContent processor.
mtien-apache commented on pull request #4421: URL: https://github.com/apache/nifi/pull/4421#issuecomment-663317004 +1 Looks good to me - ran full build, confirmed EncryptContent processor has new additions. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi] kent-nguyen commented on a change in pull request #4422: NIFI-6332 - Add Cache Control property to PutS3Object processor
kent-nguyen commented on a change in pull request #4422:
URL: https://github.com/apache/nifi/pull/4422#discussion_r459806345
##
File path:
nifi-nar-bundles/nifi-aws-bundle/nifi-aws-processors/src/main/java/org/apache/nifi/processors/aws/s3/PutS3Object.java
##
@@ -152,6 +153,14 @@
.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
.build();
+public static final PropertyDescriptor CACHE_CONTROL = new
PropertyDescriptor.Builder()
+.name("Cache Control")
+.displayName("Cache Control")
+.description("Sets the Cache-Control HTTP header. Multiple
directives are comma-separated.")
Review comment:
Hi @turcsanyip Thank you for checking my PR. It's great to hear you ran
the tests on it. I had carefully tested it on my local too.
In contrast to Content Type property, which can properly get MIME string
from the flow file itself, the Cache Control is not relevant to flow file meta
data, it is purely set to the processor itself.
Other similar properties such as Storage Class, Server Side Encryption ...
are purely set to the processor and does not support expression language either.
I have updated the description as your suggestion. Thank you again.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi] FerrelBurn opened a new pull request #4426: Nifi 1.11.4 fix corrupt flow.xml.gz and add thread priority
FerrelBurn opened a new pull request #4426:
URL: https://github.com/apache/nifi/pull/4426
Thank you for submitting a contribution to Apache NiFi.
Please provide a short description of the PR here:
Description of PR
fix corrupt flow.xml.gz and add thread priority; fixes an unreported bug
Delegate writing flow.xml.gz to FlowConfigurationDAO …
Before initial synchronizing flow.xml.gz, check for valid local …
Lower thread priority of timer-driven and event-driven data thread pool …
Add isValidXml to validate flow.xml.gz
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [NO] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?
- [NO] Does your PR title start with **NIFI-** where is the JIRA
number you are trying to resolve? Pay particular attention to the hyphen "-"
character.
- [YES] Has your PR been rebased against the latest commit within the target
branch (typically `main`)?
- [NO] Is your initial contribution a single, squashed commit? _Additional
commits in response to PR reviewer feedback should be made on this branch and
pushed to allow change tracking. Do not `squash` or use `--force` when pushing
to allow for clean monitoring of changes._
### For code changes:
- [YES] Have you ensured that the full suite of tests is executed via `mvn
-Pcontrib-check clean install` at the root `nifi` folder?
- [NO] Have you written or updated unit tests to verify your changes?
- [YES] Have you verified that the full build is successful on JDK 8?
- [YES] Have you verified that the full build is successful on JDK 11?
- [NA] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [NA] If applicable, have you updated the `LICENSE` file, including the
main `LICENSE` file under `nifi-assembly`?
- [NA] If applicable, have you updated the `NOTICE` file, including the main
`NOTICE` file found under `nifi-assembly`?
- [NO] If adding new Properties, have you added `.displayName` in addition
to .name (programmatic access) for each of the new properties?
### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in which
it is rendered?
### Note:
Please ensure that once the PR is submitted, you check GitHub Actions CI for
build issues and submit an update to your PR as soon as possible.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi] turcsanyip commented on a change in pull request #4422: NIFI-6332 - Add Cache Control property to PutS3Object processor
turcsanyip commented on a change in pull request #4422:
URL: https://github.com/apache/nifi/pull/4422#discussion_r459726996
##
File path:
nifi-nar-bundles/nifi-aws-bundle/nifi-aws-processors/src/main/java/org/apache/nifi/processors/aws/s3/PutS3Object.java
##
@@ -152,6 +153,14 @@
.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
.build();
+public static final PropertyDescriptor CACHE_CONTROL = new
PropertyDescriptor.Builder()
+.name("Cache Control")
+.displayName("Cache Control")
+.description("Sets the Cache-Control HTTP header. Multiple
directives are comma-separated.")
Review comment:
Could you please add a similar explanation as in case of Content Type:
"Sets the Cache-Control HTTP header _indicating the caching directives of
the associated object_." (or similar)
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (NIFI-2072) Support named captures in ExtractText
[ https://issues.apache.org/jira/browse/NIFI-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163937#comment-17163937 ] Pierre Villard commented on NIFI-2072: -- I might be able to have a look over the WE but if someone can give it a try, that would be helpful. > Support named captures in ExtractText > - > > Key: NIFI-2072 > URL: https://issues.apache.org/jira/browse/NIFI-2072 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Joey Frazee >Assignee: Otto Fowler >Priority: Major > Labels: extracttext > > ExtractText currently captures and creates attributes using numeric indices > (e.g, attribute.name.0, attribute.name.1, etc.) whether or not the capture > groups are named, i.e., patterns like (?\w+). > In addition to being more faithful to the provided regexes, named captures > could help simplify data flows because you wouldn't have to add superfluous > UpdateAttribute steps which are just renaming the indexed captures to more > interpretable names. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-7600) Defining JMS attribute types breaks due to invalid characters
[ https://issues.apache.org/jira/browse/NIFI-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163932#comment-17163932 ] Darren Hitchman commented on NIFI-7600: --- Thanks Bryan Our NIFI code in production is broken due to this issue so I have had to patch it using the fix in INFI-7600. Do you know how I can help get this PR progressed ? It seems everyone is very busy atm with 1.12 Thanks Darren > Defining JMS attribute types breaks due to invalid characters > - > > Key: NIFI-7600 > URL: https://issues.apache.org/jira/browse/NIFI-7600 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.11.4 >Reporter: Darren Hitchman >Assignee: Darren Hitchman >Priority: Major > Labels: JMS > Original Estimate: 4h > Time Spent: 40m > Remaining Estimate: 3h 20m > > JMSPublisher causes Exception when setting attributes in the JMS message due > to invalid characters. When defining types to be used when sending JMS > attributes (e.g. JMS_IBM_Encoding.type=integer) , the JMSPublishercorrectly > sets the type but also adds the '.type' attribute into the message, causing > an Exception as JMS doesnt support a dot character in attribute names. > NIFI-6957 was suppose to fix this however the change in JMSPublish was > removed. > There is an option to 'allowIllegalChars' in PublishJMS however '.type' > attributes are passed along regardless of this setting. > > The JMSPublisher should ignore message attributes ending with '.type' when > there is a matching attribute without the '.type' suffix > > example exception. > > com.ibm.msg.client.jms.DetailedMessageFormatException: JMSCC0049: The > property name 'JMS_IBM_Encoding.type' is not a valid Java(tm) identifier. > The supplied property name does not conform to the allowed format described > in the JMS specification. > Check the characters used in the property name and modify as necessary. > at > java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) > at > com.ibm.msg.client.commonservices.j2se.NLSServices.createException(NLSServices.java:319) > at > com.ibm.msg.client.commonservices.nls.NLSServices.createException(NLSServices.java:226) > at > com.ibm.msg.client.jms.internal.JmsErrorUtils.createException(JmsErrorUtils.java:126) > at > com.ibm.msg.client.jms.internal.JmsMessageImpl.checkPropName(JmsMessageImpl.java:2595) > at > com.ibm.msg.client.jms.internal.JmsMessageImpl.setStringProperty(JmsMessageImpl.java:1997) > at > com.ibm.jms.JMSMessage.setStringProperty(JMSMessage.java:1516) > at > jdk.internal.reflect.GeneratedMethodAccessor198.invoke(Unknown Source) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at > org.apache.nifi.controller.service.StandardControllerServiceInvocationHandler.invoke(StandardControllerServiceInvocationHandler.java:254) > at > org.apache.nifi.controller.service.StandardControllerServiceInvocationHandler$ProxiedReturnObjectInvocationHandler.invoke(StandardControllerServiceInvocationHandler.java:240) > at com.sun.proxy.$Proxy145.setStringProperty(Unknown Source) > at > org.apache.nifi.jms.processors.JMSPublisher$JmsPropertySetterEnum.lambda$static$7(JMSPublisher.java:196) > at > org.apache.nifi.jms.processors.JMSPublisher$JmsPropertySetterEnum.setProperty(JMSPublisher.java:205) > at > org.apache.nifi.jms.processors.JMSPublisher.setMessageHeaderAndProperties(JMSPublisher.java:123) > at > org.apache.nifi.jms.processors.JMSPublisher$1.createMessage(JMSPublisher.java:59) > at > org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:593) > at > org.springframework.jms.core.JmsTemplate$4.doInJms(JmsTemplate.java:574) > at > org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:484) > at > org.springframework.jms.core.JmsTemplate.send(JmsTemplate.java:570) > at >
[GitHub] [nifi] markap14 commented on a change in pull request #4376: NIFI-7592: Allow NiFi to be started without a GUI/REST interface
markap14 commented on a change in pull request #4376:
URL: https://github.com/apache/nifi/pull/4376#discussion_r459715604
##
File path:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/minifi-server/src/main/java/org/apache/nifi/minifi/MiNiFiServer.java
##
@@ -0,0 +1,211 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.minifi;
+
+import org.apache.nifi.NiFiServer;
+import org.apache.nifi.admin.service.AuditService;
+import org.apache.nifi.admin.service.impl.StandardAuditService;
+import org.apache.nifi.authorization.AuthorizationRequest;
+import org.apache.nifi.authorization.AuthorizationResult;
+import org.apache.nifi.authorization.Authorizer;
+import org.apache.nifi.authorization.AuthorizerConfigurationContext;
+import org.apache.nifi.authorization.AuthorizerInitializationContext;
+import org.apache.nifi.authorization.exception.AuthorizationAccessException;
+import org.apache.nifi.authorization.exception.AuthorizerCreationException;
+import org.apache.nifi.authorization.exception.AuthorizerDestructionException;
+import org.apache.nifi.bundle.Bundle;
+import org.apache.nifi.controller.FlowController;
+import org.apache.nifi.controller.StandardFlowService;
+import org.apache.nifi.controller.flow.FlowManager;
+import org.apache.nifi.controller.repository.FlowFileEventRepository;
+import org.apache.nifi.controller.repository.metrics.RingBufferEventRepository;
+import org.apache.nifi.diagnostics.DiagnosticsFactory;
+import org.apache.nifi.encrypt.StringEncryptor;
+import org.apache.nifi.events.VolatileBulletinRepository;
+import org.apache.nifi.nar.ExtensionDiscoveringManager;
+import org.apache.nifi.nar.ExtensionManagerHolder;
+import org.apache.nifi.nar.ExtensionMapping;
+import org.apache.nifi.nar.StandardExtensionDiscoveringManager;
+import org.apache.nifi.registry.VariableRegistry;
+import org.apache.nifi.registry.flow.StandardFlowRegistryClient;
+import org.apache.nifi.registry.variable.FileBasedVariableRegistry;
+import org.apache.nifi.reporting.BulletinRepository;
+import org.apache.nifi.services.FlowService;
+import org.apache.nifi.util.NiFiProperties;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import java.util.List;
+import java.util.Set;
+
+/**
+ */
+public class MiNiFiServer implements NiFiServer {
+
+private static final Logger logger =
LoggerFactory.getLogger(MiNiFiServer.class);
+private NiFiProperties props;
+private Bundle systemBundle;
+private Set bundles;
+private ExtensionMapping extensionMapping;
+private FlowService flowService;
+
+private static final String DEFAULT_SENSITIVE_PROPS_KEY = "nififtw!";
+
+/**
+ * Default constructor
+ */
+public MiNiFiServer() {
+}
+
+public void start() {
+try {
+
+// Create a standard extension manager and discover extensions
+final ExtensionDiscoveringManager extensionManager = new
StandardExtensionDiscoveringManager();
+extensionManager.discoverExtensions(systemBundle, bundles);
+extensionManager.logClassLoaderMapping();
+
+// Set the extension manager into the holder which makes it
available to the Spring context via a factory bean
+ExtensionManagerHolder.init(extensionManager);
+
+// Enrich the flow xml using the Extension Manager mapping
+final FlowParser flowParser = new FlowParser();
+final FlowEnricher flowEnricher = new FlowEnricher(this,
flowParser, props);
+flowEnricher.enrichFlowWithBundleInformation();
+logger.info("Loading Flow...");
+
+FlowFileEventRepository flowFileEventRepository = new
RingBufferEventRepository(5);
+AuditService auditService = new StandardAuditService();
+Authorizer authorizer = new Authorizer() {
+@Override
+public AuthorizationResult authorize(AuthorizationRequest
request) throws AuthorizationAccessException {
+return AuthorizationResult.approved();
+}
+
+@Override
+public void initialize(AuthorizerInitializationContext
initializationContext) throws
[jira] [Commented] (NIFI-2072) Support named captures in ExtractText
[ https://issues.apache.org/jira/browse/NIFI-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163925#comment-17163925 ] Otto Fowler commented on NIFI-2072: --- The PR is up for review. The next step is that somebody reviews it. And if that person is a committer then they can +1 it and merge it. [~pvillard] is pretty busy. You are welcome to review and try etc. If that is in the realm of things you are comfortable doing > Support named captures in ExtractText > - > > Key: NIFI-2072 > URL: https://issues.apache.org/jira/browse/NIFI-2072 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Joey Frazee >Assignee: Otto Fowler >Priority: Major > Labels: extracttext > > ExtractText currently captures and creates attributes using numeric indices > (e.g, attribute.name.0, attribute.name.1, etc.) whether or not the capture > groups are named, i.e., patterns like (?\w+). > In addition to being more faithful to the provided regexes, named captures > could help simplify data flows because you wouldn't have to add superfluous > UpdateAttribute steps which are just renaming the indexed captures to more > interpretable names. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [nifi] markap14 commented on a change in pull request #4376: NIFI-7592: Allow NiFi to be started without a GUI/REST interface
markap14 commented on a change in pull request #4376:
URL: https://github.com/apache/nifi/pull/4376#discussion_r459702685
##
File path:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-nar-utils/src/main/java/org/apache/nifi/nar/NarClassLoaders.java
##
@@ -262,6 +263,15 @@ private InitContext load(final ClassLoader rootClassloader,
narDirectoryBundleLookup.put(narDetail.getWorkingDirectory().getCanonicalPath(),
new Bundle(narDetail, bundleClassLoader));
narCoordinateClassLoaderLookup.put(narDetail.getCoordinate().getCoordinate(),
narClassLoader);
narDetailsIter.remove();
+// Search for a NiFiServer implementation
+ServiceLoader niFiServerServiceLoader =
ServiceLoader.load(NiFiServer.class, narClassLoader);
+for(NiFiServer server : niFiServerServiceLoader) {
+if(serverInstance == null) {
+serverInstance = server;
+} else {
+throw new IOException("Multiple
implementations of NiFiServer found, there must be exactly one
implementation.");
Review comment:
I tried adding both nifi-server-nar and minifi-server-nar into the lib/
directory. Indeed, I ran into this. But this error can probably be made a bit
clearer, by listing the classnames of the NiFiServer implementations and the
associated NAR's. For example:
`Expected exactly one implementation of NiFiServer but found 2: JettyServer
from nifi-server-nar-1.12.0-SNAPSHOT.nar, MiNiFiServer from
minifi-server-nar-1.12.0-SNAPSHOT.nar`
Or something to that effect.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (NIFI-2072) Support named captures in ExtractText
[ https://issues.apache.org/jira/browse/NIFI-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163913#comment-17163913 ] Malthe Borch commented on NIFI-2072: [~otto] Nice work. I think this is ready for the next step (not sure who/how that works). > Support named captures in ExtractText > - > > Key: NIFI-2072 > URL: https://issues.apache.org/jira/browse/NIFI-2072 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Joey Frazee >Assignee: Otto Fowler >Priority: Major > Labels: extracttext > > ExtractText currently captures and creates attributes using numeric indices > (e.g, attribute.name.0, attribute.name.1, etc.) whether or not the capture > groups are named, i.e., patterns like (?\w+). > In addition to being more faithful to the provided regexes, named captures > could help simplify data flows because you wouldn't have to add superfluous > UpdateAttribute steps which are just renaming the indexed captures to more > interpretable names. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [nifi] thenatog commented on a change in pull request #4416: NIFI-7568 - Ensure Kerberos mappings are applied correctly
thenatog commented on a change in pull request #4416:
URL: https://github.com/apache/nifi/pull/4416#discussion_r459659479
##
File path:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-administration/src/main/java/org/apache/nifi/admin/service/impl/StandardKeyService.java
##
@@ -118,11 +118,16 @@ public void deleteKey(String identity) {
transaction = transactionBuilder.start();
// delete the keys
-DeleteKeysAction deleteKeys = new DeleteKeysAction(identity);
-transaction.execute(deleteKeys);
-
-// commit the transaction
-transaction.commit();
+DeleteKeyAction deleteKey = new DeleteKeyAction(keyId);
+Integer rowsDeleted = transaction.execute(deleteKey);
+
+// commit the transaction if we found one and only one matching
keyId/user identity
+if (rowsDeleted == 1) {
Review comment:
I don't believe there was a specific condition I knew of, I just wasn't
sure. I think the naming and possibly a comment had implied to me it was
possible to delete multiple rows using the identity. Sounds like that's not an
issue. As such, the method can remain as shown.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi] mcgilman commented on a change in pull request #4416: NIFI-7568 - Ensure Kerberos mappings are applied correctly
mcgilman commented on a change in pull request #4416:
URL: https://github.com/apache/nifi/pull/4416#discussion_r459640917
##
File path:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-administration/src/main/java/org/apache/nifi/admin/service/impl/StandardKeyService.java
##
@@ -118,11 +118,16 @@ public void deleteKey(String identity) {
transaction = transactionBuilder.start();
// delete the keys
-DeleteKeysAction deleteKeys = new DeleteKeysAction(identity);
-transaction.execute(deleteKeys);
-
-// commit the transaction
-transaction.commit();
+DeleteKeyAction deleteKey = new DeleteKeyAction(keyId);
+Integer rowsDeleted = transaction.execute(deleteKey);
+
+// commit the transaction if we found one and only one matching
keyId/user identity
+if (rowsDeleted == 1) {
Review comment:
I believe that the identity is marked as unique [1]. What condition
resulted in deleting multiple rows?
[1]
https://github.com/apache/nifi/blob/main/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-administration/src/main/java/org/apache/nifi/admin/KeyDataSourceFactoryBean.java#L47
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi] thenatog commented on a change in pull request #4416: NIFI-7568 - Ensure Kerberos mappings are applied correctly
thenatog commented on a change in pull request #4416:
URL: https://github.com/apache/nifi/pull/4416#discussion_r459635228
##
File path:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-administration/src/main/java/org/apache/nifi/admin/service/impl/StandardKeyService.java
##
@@ -118,11 +118,16 @@ public void deleteKey(String identity) {
transaction = transactionBuilder.start();
// delete the keys
-DeleteKeysAction deleteKeys = new DeleteKeysAction(identity);
-transaction.execute(deleteKeys);
-
-// commit the transaction
-transaction.commit();
+DeleteKeyAction deleteKey = new DeleteKeyAction(keyId);
+Integer rowsDeleted = transaction.execute(deleteKey);
+
+// commit the transaction if we found one and only one matching
keyId/user identity
+if (rowsDeleted == 1) {
Review comment:
@mcgilman
This method previously deleted by 'identity', which could potentially delete
multiple rows. I've changed it to delete by row/key ID. Could there be side
effects for this?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi] markap14 commented on a change in pull request #4376: NIFI-7592: Allow NiFi to be started without a GUI/REST interface
markap14 commented on a change in pull request #4376:
URL: https://github.com/apache/nifi/pull/4376#discussion_r459535677
##
File path:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/minifi-server/src/main/java/org/apache/nifi/minifi/FlowParser.java
##
@@ -0,0 +1,156 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.minifi;
+
+import org.apache.commons.io.IOUtils;
+import org.apache.nifi.util.LoggingXmlParserErrorHandler;
+import org.apache.nifi.util.file.FileUtils;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+import org.w3c.dom.Document;
+import org.w3c.dom.Element;
+import org.w3c.dom.Node;
+import org.w3c.dom.NodeList;
+import org.xml.sax.SAXException;
+
+import javax.xml.XMLConstants;
+import javax.xml.parsers.DocumentBuilder;
+import javax.xml.parsers.DocumentBuilderFactory;
+import javax.xml.parsers.ParserConfigurationException;
+import javax.xml.transform.Result;
+import javax.xml.transform.Source;
+import javax.xml.transform.TransformerException;
+import javax.xml.transform.TransformerFactory;
+import javax.xml.transform.dom.DOMSource;
+import javax.xml.transform.stream.StreamResult;
+import java.io.ByteArrayInputStream;
+import java.io.ByteArrayOutputStream;
+import java.io.File;
+import java.io.IOException;
+import java.io.InputStream;
+import java.io.OutputStream;
+import java.nio.file.Files;
+import java.nio.file.Path;
+import java.nio.file.StandardOpenOption;
+import java.util.ArrayList;
+import java.util.List;
+import java.util.zip.GZIPInputStream;
+import java.util.zip.GZIPOutputStream;
+
+/**
+ * Parses a flow from its xml.gz format into an XML {@link Document}. This
class is primarily toward utilities for assisting
+ * with the handling of component bundles.
+ *
+ * Provides auxiliary methods to aid in evaluating and manipulating the flow.
+ */
+public class FlowParser {
+
+private static final Logger logger =
LoggerFactory.getLogger(FlowParser.class);
+
+/**
+ * Generates a {@link Document} from the flow configuration file provided
+ */
+public Document parse(final File flowConfigurationFile) {
+if (flowConfigurationFile == null) {
+logger.debug("Flow Configuration file was null");
+return null;
+}
+
+// if the flow doesn't exist or is 0 bytes, then return null
+final Path flowPath = flowConfigurationFile.toPath();
+try {
+if (!Files.exists(flowPath) || Files.size(flowPath) == 0) {
+logger.warn("Flow Configuration does not exist or was empty");
+return null;
+}
+} catch (IOException e) {
+logger.error("An error occurred determining the size of the Flow
Configuration file");
+return null;
+}
+
+// otherwise create the appropriate input streams to read the file
+try (final InputStream in = Files.newInputStream(flowPath,
StandardOpenOption.READ);
+ final InputStream gzipIn = new GZIPInputStream(in)) {
+
+final byte[] flowBytes = IOUtils.toByteArray(gzipIn);
+if (flowBytes == null || flowBytes.length == 0) {
+logger.warn("Could not extract root group id because Flow
Configuration File was empty");
+return null;
+}
+
+final DocumentBuilderFactory docFactory =
DocumentBuilderFactory.newInstance();
Review comment:
Should use the `SafeXMLConfiguration` class defined in
`nifi-security-utils`, if adding that dependency is okay here. Otherwise,
should at least ensure that we are setting all of the appropriate flags in the
way that is handled there.
##
File path:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-nar-utils/src/main/java/org/apache/nifi/nar/NarUnpacker.java
##
@@ -243,7 +243,9 @@ private static void mapExtensions(final Map unpackedNars
public static void mapExtension(final File unpackedNar, final
BundleCoordinate bundleCoordinate, final File docsDirectory, final
ExtensionMapping mapping) throws IOException {
final File bundledDependencies = new File(unpackedNar,
BUNDLED_DEPENDENCIES_DIRECTORY);
-
[jira] [Commented] (NIFI-2072) Support named captures in ExtractText
[ https://issues.apache.org/jira/browse/NIFI-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163793#comment-17163793 ] Otto Fowler commented on NIFI-2072: --- [~malthe] I just pushed validation support > Support named captures in ExtractText > - > > Key: NIFI-2072 > URL: https://issues.apache.org/jira/browse/NIFI-2072 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Joey Frazee >Assignee: Otto Fowler >Priority: Major > Labels: extracttext > > ExtractText currently captures and creates attributes using numeric indices > (e.g, attribute.name.0, attribute.name.1, etc.) whether or not the capture > groups are named, i.e., patterns like (?\w+). > In addition to being more faithful to the provided regexes, named captures > could help simplify data flows because you wouldn't have to add superfluous > UpdateAttribute steps which are just renaming the indexed captures to more > interpretable names. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [nifi] tpalfy opened a new pull request #4425: NIFI-7663 Allow user to empty all queues in a Process Group
tpalfy opened a new pull request #4425: URL: https://github.com/apache/nifi/pull/4425 https://issues.apache.org/jira/browse/NIFI-7663 Added option for emptying all queues in a process group. Available from context menu. ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Does your PR title start with **NIFI-** where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [ ] Has your PR been rebased against the latest commit within the target branch (typically `main`)? - [ ] Is your initial contribution a single, squashed commit? _Additional commits in response to PR reviewer feedback should be made on this branch and pushed to allow change tracking. Do not `squash` or use `--force` when pushing to allow for clean monitoring of changes._ ### For code changes: - [ ] Have you ensured that the full suite of tests is executed via `mvn -Pcontrib-check clean install` at the root `nifi` folder? - [ ] Have you written or updated unit tests to verify your changes? - [ ] Have you verified that the full build is successful on JDK 8? - [ ] Have you verified that the full build is successful on JDK 11? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [ ] If applicable, have you updated the `LICENSE` file, including the main `LICENSE` file under `nifi-assembly`? - [ ] If applicable, have you updated the `NOTICE` file, including the main `NOTICE` file found under `nifi-assembly`? - [ ] If adding new Properties, have you added `.displayName` in addition to .name (programmatic access) for each of the new properties? ### For documentation related changes: - [ ] Have you ensured that format looks appropriate for the output in which it is rendered? ### Note: Please ensure that once the PR is submitted, you check GitHub Actions CI for build issues and submit an update to your PR as soon as possible. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (NIFI-7543) Authorize requests for download-token
[ https://issues.apache.org/jira/browse/NIFI-7543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Bende updated NIFI-7543: -- Fix Version/s: (was: 1.12.0) > Authorize requests for download-token > - > > Key: NIFI-7543 > URL: https://issues.apache.org/jira/browse/NIFI-7543 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.12.0 >Reporter: Nathan Gough >Assignee: Nathan Gough >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > The download-token and ui-extension-token endpoints should authorize requests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [nifi-minifi-cpp] hunyadi-dev commented on pull request #846: MINIFICPP-1291 - Work in Progress
hunyadi-dev commented on pull request #846: URL: https://github.com/apache/nifi-minifi-cpp/pull/846#issuecomment-663053043 Implementation has been cancelled. See Jira ticket for details. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi-minifi-cpp] hunyadi-dev closed pull request #846: MINIFICPP-1291 - Work in Progress
hunyadi-dev closed pull request #846: URL: https://github.com/apache/nifi-minifi-cpp/pull/846 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MINIFICPP-1305) Create integration tests for MQTT processors using a dockerized MQTT broker
Adam Hunyadi created MINIFICPP-1305: --- Summary: Create integration tests for MQTT processors using a dockerized MQTT broker Key: MINIFICPP-1305 URL: https://issues.apache.org/jira/browse/MINIFICPP-1305 Project: Apache NiFi MiNiFi C++ Issue Type: Task Affects Versions: 0.7.0 Reporter: Adam Hunyadi Assignee: Adam Hunyadi Fix For: 1.0.0 *Background:* The MQTT processors are untested and known to be unstable. We suspect, that setting up secure connections is currently broken and it is quite likely that there are other problems as well. As we do not know much about what potential use-cases there are for MQTT, my recommendation is that whoever starts with the implementations first spends a considerable amount of time on understanding this protocol and its use-cases, finding a containerized solution for a broker implementation that adheres to them and plans the potential tests before even touching the code. Also starting with compatibility (platform for the docker frame/CI job) tests and checks before writing the tests is recommended. Acceptance criteria: The person picking up this task should investigate and propose tests and verify it with [~aboda]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MINIFICPP-1305) Create integration tests for MQTT processors using a dockerized MQTT broker
[ https://issues.apache.org/jira/browse/MINIFICPP-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Hunyadi reassigned MINIFICPP-1305: --- Assignee: (was: Adam Hunyadi) > Create integration tests for MQTT processors using a dockerized MQTT broker > --- > > Key: MINIFICPP-1305 > URL: https://issues.apache.org/jira/browse/MINIFICPP-1305 > Project: Apache NiFi MiNiFi C++ > Issue Type: Task >Affects Versions: 0.7.0 >Reporter: Adam Hunyadi >Priority: Major > Labels: MiNiFi-CPP-Hygiene > Fix For: 1.0.0 > > > *Background:* > The MQTT processors are untested and known to be unstable. We suspect, that > setting up secure connections is currently broken and it is quite likely that > there are other problems as well. > As we do not know much about what potential use-cases there are for MQTT, my > recommendation is that whoever starts with the implementations first spends a > considerable amount of time on understanding this protocol and its use-cases, > finding a containerized solution for a broker implementation that adheres to > them and plans the potential tests before even touching the code. Also > starting with compatibility (platform for the docker frame/CI job) tests and > checks before writing the tests is recommended. > *Acceptance criteria:* > The person picking up this task should investigate and propose tests and > verify it with [~aboda]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MINIFICPP-1305) Create integration tests for MQTT processors using a dockerized MQTT broker
[ https://issues.apache.org/jira/browse/MINIFICPP-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Hunyadi updated MINIFICPP-1305: Description: *Background:* The MQTT processors are untested and known to be unstable. We suspect, that setting up secure connections is currently broken and it is quite likely that there are other problems as well. As we do not know much about what potential use-cases there are for MQTT, my recommendation is that whoever starts with the implementations first spends a considerable amount of time on understanding this protocol and its use-cases, finding a containerized solution for a broker implementation that adheres to them and plans the potential tests before even touching the code. Also starting with compatibility (platform for the docker frame/CI job) tests and checks before writing the tests is recommended. *Acceptance criteria:* The person picking up this task should investigate and propose tests and verify it with [~aboda]. was: *Background:* The MQTT processors are untested and known to be unstable. We suspect, that setting up secure connections is currently broken and it is quite likely that there are other problems as well. As we do not know much about what potential use-cases there are for MQTT, my recommendation is that whoever starts with the implementations first spends a considerable amount of time on understanding this protocol and its use-cases, finding a containerized solution for a broker implementation that adheres to them and plans the potential tests before even touching the code. Also starting with compatibility (platform for the docker frame/CI job) tests and checks before writing the tests is recommended. Acceptance criteria: The person picking up this task should investigate and propose tests and verify it with [~aboda]. > Create integration tests for MQTT processors using a dockerized MQTT broker > --- > > Key: MINIFICPP-1305 > URL: https://issues.apache.org/jira/browse/MINIFICPP-1305 > Project: Apache NiFi MiNiFi C++ > Issue Type: Task >Affects Versions: 0.7.0 >Reporter: Adam Hunyadi >Assignee: Adam Hunyadi >Priority: Major > Labels: MiNiFi-CPP-Hygiene > Fix For: 1.0.0 > > > *Background:* > The MQTT processors are untested and known to be unstable. We suspect, that > setting up secure connections is currently broken and it is quite likely that > there are other problems as well. > As we do not know much about what potential use-cases there are for MQTT, my > recommendation is that whoever starts with the implementations first spends a > considerable amount of time on understanding this protocol and its use-cases, > finding a containerized solution for a broker implementation that adheres to > them and plans the potential tests before even touching the code. Also > starting with compatibility (platform for the docker frame/CI job) tests and > checks before writing the tests is recommended. > *Acceptance criteria:* > The person picking up this task should investigate and propose tests and > verify it with [~aboda]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MINIFICPP-1228) MergeContent doesn't respect min entry count.
[ https://issues.apache.org/jira/browse/MINIFICPP-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Debreceni resolved MINIFICPP-1228. --- Resolution: Fixed > MergeContent doesn't respect min entry count. > - > > Key: MINIFICPP-1228 > URL: https://issues.apache.org/jira/browse/MINIFICPP-1228 > Project: Apache NiFi MiNiFi C++ > Issue Type: Bug >Reporter: Adam Debreceni >Assignee: Adam Debreceni >Priority: Major > Time Spent: 9h 20m > Remaining Estimate: 0h > > The MergeContent processor's "Minimum Number of Entries" property is not > taken into account when files are merged. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [nifi] thenatog commented on a change in pull request #4416: NIFI-7568 - Ensure Kerberos mappings are applied correctly
thenatog commented on a change in pull request #4416:
URL: https://github.com/apache/nifi/pull/4416#discussion_r459495155
##
File path:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-administration/src/main/java/org/apache/nifi/admin/service/impl/StandardKeyService.java
##
@@ -118,11 +118,20 @@ public void deleteKey(String identity) {
transaction = transactionBuilder.start();
// delete the keys
-DeleteKeysAction deleteKeys = new DeleteKeysAction(identity);
-transaction.execute(deleteKeys);
-
-// commit the transaction
-transaction.commit();
+DeleteKeyAction deleteKey = new DeleteKeyAction(keyId);
+Integer rowsDeleted = transaction.execute(deleteKey);
+
+// commit the transaction if we found one and only one matching
user identity
+
+if (rowsDeleted == 0) {
+rollback(transaction);
+throw new AdministrationException("Unable to find user key for
key ID " + keyId + " to remove token.");
+} else if (rowsDeleted > 1) {
Review comment:
Yeah this is true, keyId refers to the ID column, whereas previously the
delete used the identity which theoretically could have been multiple rows.
@mcgilman, was there any specific need for the DeleteKey(s) mechanism to delete
multiple rows/identities? See changes to StandardKeyDao.java.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Resolved] (MINIFICPP-1291) Update MQTT processors so that they use the Mosquitto third-party
[ https://issues.apache.org/jira/browse/MINIFICPP-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Hunyadi resolved MINIFICPP-1291. - Resolution: Won't Do See description on details. > Update MQTT processors so that they use the Mosquitto third-party > - > > Key: MINIFICPP-1291 > URL: https://issues.apache.org/jira/browse/MINIFICPP-1291 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Arpad Boda >Assignee: Adam Hunyadi >Priority: Major > Labels: MiNiFi-CPP-Hygiene > Time Spent: 10m > Remaining Estimate: 0h > > MQTT processors are untested and unstable (based on the latest commit fixing > them). > A 3rd party should be found to act as other end of the mqtt communication > and verify the processors. > *Update 1:* > [[Mosquitto]|https://github.com/eclipse/mosquitto] should be a good candidate > as a third-party handling MQTT communication. It is licensed under the > [[Eclipse Public License 1.0]|https://www.eclipse.org/legal/epl-v10.html] > which is [[compatible with the Apache > License]|https://www.apache.org/legal/resolved.html]. > *Update 2:* > Seems like mosquitto does not actually provide an c++ library interface for > running a broker, only clients are available. I misunderstood "is an > opensource MQTT broker and provides client library implementation for MQTT." > for "is an opensource MQTT broker and client library implementation. Marton > is completely right with his comment. > However, this means that we could not find any candidate library that allows > us testing from within our c++ integration tests only. We should find a > dockerized broker container and use that instead. *Closing this ticket as > "Won't do" and will open a new one for using a docker based solution.* -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MINIFICPP-1291) Update MQTT processors so that they use the Mosquitto third-party
[ https://issues.apache.org/jira/browse/MINIFICPP-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Hunyadi updated MINIFICPP-1291: Description: MQTT processors are untested and unstable (based on the latest commit fixing them). A 3rd party should be found to act as other end of the mqtt communication and verify the processors. *Update 1:* [[Mosquitto]|https://github.com/eclipse/mosquitto] should be a good candidate as a third-party handling MQTT communication. It is licensed under the [[Eclipse Public License 1.0]|https://www.eclipse.org/legal/epl-v10.html] which is [[compatible with the Apache License]|https://www.apache.org/legal/resolved.html]. *Update 2:* Seems like mosquitto does not actually provide an c++ library interface for running a broker, only clients are available. I misunderstood "is an opensource MQTT broker and provides client library implementation for MQTT." for "is an opensource MQTT broker and client library implementation. Marton is completely right with his comment. However, this means that we could not find any candidate library that allows us testing from within our c++ integration tests only. We should find a dockerized broker container and use that instead. *Closing this ticket as "Won't do" and will open a new one for using a docker based solution.* was: MQTT processors are untested and unstable (based on the latest commit fixing them). A 3rd party should be found to act as other end of the mqtt communication and verify the processors. *Update 1:* [[Mosquitto]|https://github.com/eclipse/mosquitto] should be a good candidate as a third-party handling MQTT communication. It is licensed under the [[Eclipse Public License 1.0]|https://www.eclipse.org/legal/epl-v10.html] which is [[compatible with the Apache License]|https://www.apache.org/legal/resolved.html]. *Update 2:* Seems like mosquitto does not actually provide an c++ library interface for running a broker, only clients are available. I misunderstood "is an opensource MQTT broker and provides client library implementation for MQTT." for "is an opensource MQTT broker and client library implementation. Marton is completely right with his comment. However, this means that we could not find any candidate library that allows us testing from within our c++ integration tests only. We should find a dockerized broker container and use that instead. Closing this ticket and > Update MQTT processors so that they use the Mosquitto third-party > - > > Key: MINIFICPP-1291 > URL: https://issues.apache.org/jira/browse/MINIFICPP-1291 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Arpad Boda >Assignee: Adam Hunyadi >Priority: Major > Labels: MiNiFi-CPP-Hygiene > Time Spent: 10m > Remaining Estimate: 0h > > MQTT processors are untested and unstable (based on the latest commit fixing > them). > A 3rd party should be found to act as other end of the mqtt communication > and verify the processors. > *Update 1:* > [[Mosquitto]|https://github.com/eclipse/mosquitto] should be a good candidate > as a third-party handling MQTT communication. It is licensed under the > [[Eclipse Public License 1.0]|https://www.eclipse.org/legal/epl-v10.html] > which is [[compatible with the Apache > License]|https://www.apache.org/legal/resolved.html]. > *Update 2:* > Seems like mosquitto does not actually provide an c++ library interface for > running a broker, only clients are available. I misunderstood "is an > opensource MQTT broker and provides client library implementation for MQTT." > for "is an opensource MQTT broker and client library implementation. Marton > is completely right with his comment. > However, this means that we could not find any candidate library that allows > us testing from within our c++ integration tests only. We should find a > dockerized broker container and use that instead. *Closing this ticket as > "Won't do" and will open a new one for using a docker based solution.* -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [nifi-minifi-cpp] arpadboda closed pull request #807: MINIFICPP-1228 - Resource ownership refactor + flowFile-owning processors.
arpadboda closed pull request #807: URL: https://github.com/apache/nifi-minifi-cpp/pull/807 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MINIFICPP-1291) Update MQTT processors so that they use the Mosquitto third-party
[ https://issues.apache.org/jira/browse/MINIFICPP-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Hunyadi updated MINIFICPP-1291: Description: MQTT processors are untested and unstable (based on the latest commit fixing them). A 3rd party should be found to act as other end of the mqtt communication and verify the processors. *Update 1:* [[Mosquitto]|https://github.com/eclipse/mosquitto] should be a good candidate as a third-party handling MQTT communication. It is licensed under the [[Eclipse Public License 1.0]|https://www.eclipse.org/legal/epl-v10.html] which is [[compatible with the Apache License]|https://www.apache.org/legal/resolved.html]. *Update 2:* Seems like mosquitto does not actually provide an c++ library interface for running a broker, only clients are available. I misunderstood "is an opensource MQTT broker and provides client library implementation for MQTT." for "is an opensource MQTT broker and client library implementation. Marton is completely right with his comment. However, this means that we could not find any candidate library that allows us testing from within our c++ integration tests only. We should find a dockerized broker container and use that instead. Closing this ticket and was: MQTT processors are untested and unstable (based on the latest commit fixing them). A 3rd party should be found to act as other end of the mqtt communication and verify the processors. *Update 1:* [[Mosquitto]|https://github.com/eclipse/mosquitto] should be a good candidate as a third-party handling MQTT communication. It is licensed under the [[Eclipse Public License 1.0]|https://www.eclipse.org/legal/epl-v10.html] which is [[compatible with the Apache License]|https://www.apache.org/legal/resolved.html]. *Update 2:* Seems like mosquitto does not actually provide an c++ library interface for running a broker, only clients are available. I misunderstood "is an opensource MQTT broker and provides client library implementation for MQTT." for "is an opensource MQTT broker and client library implementation. Marton is completely right with his comment. However, this means that we could not find any candidate library that allows us testing > Update MQTT processors so that they use the Mosquitto third-party > - > > Key: MINIFICPP-1291 > URL: https://issues.apache.org/jira/browse/MINIFICPP-1291 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Arpad Boda >Assignee: Adam Hunyadi >Priority: Major > Labels: MiNiFi-CPP-Hygiene > Time Spent: 10m > Remaining Estimate: 0h > > MQTT processors are untested and unstable (based on the latest commit fixing > them). > A 3rd party should be found to act as other end of the mqtt communication > and verify the processors. > *Update 1:* > [[Mosquitto]|https://github.com/eclipse/mosquitto] should be a good candidate > as a third-party handling MQTT communication. It is licensed under the > [[Eclipse Public License 1.0]|https://www.eclipse.org/legal/epl-v10.html] > which is [[compatible with the Apache > License]|https://www.apache.org/legal/resolved.html]. > *Update 2:* > Seems like mosquitto does not actually provide an c++ library interface for > running a broker, only clients are available. I misunderstood "is an > opensource MQTT broker and provides client library implementation for MQTT." > for "is an opensource MQTT broker and client library implementation. Marton > is completely right with his comment. > However, this means that we could not find any candidate library that allows > us testing from within our c++ integration tests only. We should find a > dockerized broker container and use that instead. Closing this ticket and -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MINIFICPP-1291) Update MQTT processors so that they use the Mosquitto third-party
[ https://issues.apache.org/jira/browse/MINIFICPP-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Hunyadi updated MINIFICPP-1291: Description: MQTT processors are untested and unstable (based on the latest commit fixing them). A 3rd party should be found to act as other end of the mqtt communication and verify the processors. *Update 1:* [[Mosquitto]|https://github.com/eclipse/mosquitto] should be a good candidate as a third-party handling MQTT communication. It is licensed under the [[Eclipse Public License 1.0]|https://www.eclipse.org/legal/epl-v10.html] which is [[compatible with the Apache License]|https://www.apache.org/legal/resolved.html]. *Update 2:* Seems like mosquitto does not actually provide an c++ library interface for running a broker, only clients are available. I misunderstood "is an opensource MQTT broker and provides client library implementation for MQTT." for "is an opensource MQTT broker and client library implementation. Marton is completely right with his comment. However, this means that we could not find any candidate library that allows us testing was: MQTT processors are untested and unstable (based on the latest commit fixing them). A 3rd party should be found to act as other end of the mqtt communication and verify the processors. *Update:* [[Mosquitto]|https://github.com/eclipse/mosquitto] should be a good candidate as a third-party handling MQTT communication. It is licensed under the [[Eclipse Public License 1.0]|https://www.eclipse.org/legal/epl-v10.html] which is [[compatible with the Apache License]|https://www.apache.org/legal/resolved.html]. > Update MQTT processors so that they use the Mosquitto third-party > - > > Key: MINIFICPP-1291 > URL: https://issues.apache.org/jira/browse/MINIFICPP-1291 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Arpad Boda >Assignee: Adam Hunyadi >Priority: Major > Labels: MiNiFi-CPP-Hygiene > Time Spent: 10m > Remaining Estimate: 0h > > MQTT processors are untested and unstable (based on the latest commit fixing > them). > A 3rd party should be found to act as other end of the mqtt communication > and verify the processors. > *Update 1:* > [[Mosquitto]|https://github.com/eclipse/mosquitto] should be a good candidate > as a third-party handling MQTT communication. It is licensed under the > [[Eclipse Public License 1.0]|https://www.eclipse.org/legal/epl-v10.html] > which is [[compatible with the Apache > License]|https://www.apache.org/legal/resolved.html]. > *Update 2:* > Seems like mosquitto does not actually provide an c++ library interface for > running a broker, only clients are available. I misunderstood "is an > opensource MQTT broker and provides client library implementation for MQTT." > for "is an opensource MQTT broker and client library implementation. Marton > is completely right with his comment. > However, this means that we could not find any candidate library that allows > us testing -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [nifi] bbende commented on a change in pull request #4416: NIFI-7568 - Ensure Kerberos mappings are applied correctly
bbende commented on a change in pull request #4416:
URL: https://github.com/apache/nifi/pull/4416#discussion_r459480827
##
File path:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-administration/src/main/java/org/apache/nifi/admin/service/impl/StandardKeyService.java
##
@@ -118,11 +118,20 @@ public void deleteKey(String identity) {
transaction = transactionBuilder.start();
// delete the keys
-DeleteKeysAction deleteKeys = new DeleteKeysAction(identity);
-transaction.execute(deleteKeys);
-
-// commit the transaction
-transaction.commit();
+DeleteKeyAction deleteKey = new DeleteKeyAction(keyId);
+Integer rowsDeleted = transaction.execute(deleteKey);
+
+// commit the transaction if we found one and only one matching
user identity
+
+if (rowsDeleted == 0) {
+rollback(transaction);
+throw new AdministrationException("Unable to find user key for
key ID " + keyId + " to remove token.");
+} else if (rowsDeleted > 1) {
Review comment:
The key table has the following schema:
```
CREATE TABLE KEY (
ID INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
IDENTITY VARCHAR2(4096) NOT NULL UNIQUE,
KEY VARCHAR2(100) NOT NULL"
)
```
Does `keyId` here refer to the `ID` column in this table?
If so, then there could never be multiple rows with the same ID since that
column is the primary key of the table.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi] bbende commented on pull request #4401: NIFI-7622 Use param context name from inside nested versioned PG when…
bbende commented on pull request #4401: URL: https://github.com/apache/nifi/pull/4401#issuecomment-663014388 I don't think we need to block versioning, but arguably we maybe don't need to store the param-context name on the shell process group that contains the pointer to the nested versioned PG, that is what is causing the issue. Using the correct param context from the actual nested versioned PG during import solves the issue. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (NIFI-7667) Add variable support to GetHBase properties
[ https://issues.apache.org/jira/browse/NIFI-7667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163578#comment-17163578 ] ASF subversion and git services commented on NIFI-7667: --- Commit 4b0d349a49685fa2445a14f6f7b2f0e85c05ea51 in nifi's branch refs/heads/main from Pierre Villard [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=4b0d349 ] NIFI-7667 - add variable support to GetHBase properties (#4424) > Add variable support to GetHBase properties > --- > > Key: NIFI-7667 > URL: https://issues.apache.org/jira/browse/NIFI-7667 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Fix For: 1.12.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Add variable support to GetHBase properties. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-7667) Add variable support to GetHBase properties
[ https://issues.apache.org/jira/browse/NIFI-7667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163577#comment-17163577 ] ASF subversion and git services commented on NIFI-7667: --- Commit 4b0d349a49685fa2445a14f6f7b2f0e85c05ea51 in nifi's branch refs/heads/main from Pierre Villard [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=4b0d349 ] NIFI-7667 - add variable support to GetHBase properties (#4424) > Add variable support to GetHBase properties > --- > > Key: NIFI-7667 > URL: https://issues.apache.org/jira/browse/NIFI-7667 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Fix For: 1.12.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Add variable support to GetHBase properties. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7667) Add variable support to GetHBase properties
[ https://issues.apache.org/jira/browse/NIFI-7667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Bende updated NIFI-7667: -- Fix Version/s: 1.12.0 Resolution: Fixed Status: Resolved (was: Patch Available) > Add variable support to GetHBase properties > --- > > Key: NIFI-7667 > URL: https://issues.apache.org/jira/browse/NIFI-7667 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Fix For: 1.12.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Add variable support to GetHBase properties. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [nifi] bbende merged pull request #4424: NIFI-7667 - add variable support to GetHBase properties
bbende merged pull request #4424: URL: https://github.com/apache/nifi/pull/4424 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi] bbende commented on pull request #4424: NIFI-7667 - add variable support to GetHBase properties
bbende commented on pull request #4424: URL: https://github.com/apache/nifi/pull/4424#issuecomment-663007573 Looks good This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi-minifi-cpp] adamdebreceni commented on a change in pull request #807: MINIFICPP-1228 - Resource ownership refactor + flowFile-owning processors.
adamdebreceni commented on a change in pull request #807: URL: https://github.com/apache/nifi-minifi-cpp/pull/807#discussion_r459426459 ## File path: libminifi/include/core/Repository.h ## @@ -31,6 +31,7 @@ #include #include #include +#include "core/Deprecated.h" Review comment: This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi-minifi-cpp] fgerlits opened a new pull request #848: MINIFICPP-1268 Fix compiler warnings on Windows (VS2017)
fgerlits opened a new pull request #848: URL: https://github.com/apache/nifi-minifi-cpp/pull/848 Change the warning level from W1 (severe warnings only) to W3 (production quality warnings). The largest batch of changes is due to `uint64_t` -> `size_t` conversions, which are narrowing on Windows because we build a 32-bit binary. Almost all changes should have no effect on behavior, except when a narrowing would occur. The two exceptions are: * in `C2Agent::configure()` (C2Agent.cpp:256) the value of the property used to be read and discarded; now it is assigned to a field (the correct one, I hope); * in `WriteCallback::process()` (SiteToSiteClient.h:308) we calculated the number of bytes received, but then we did not log it but always logged 0 instead. I did not deal with warnings related to the min/max macros, as those will be fixed by #837 --- Thank you for submitting a contribution to Apache NiFi - MiNiFi C++. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Does your PR title start with MINIFICPP- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [ ] Has your PR been rebased against the latest commit within the target branch (typically master)? - [ ] Is your initial contribution a single, squashed commit? ### For code changes: - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [ ] If applicable, have you updated the LICENSE file? - [ ] If applicable, have you updated the NOTICE file? ### For documentation related changes: - [ ] Have you ensured that format looks appropriate for the output in which it is rendered? ### Note: Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (NIFI-7569) Evaluate signing key generation
[ https://issues.apache.org/jira/browse/NIFI-7569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163516#comment-17163516 ] Bryan Bende commented on NIFI-7569: --- Going to remove the fix version as this doesn't seem to be a blocker for 1.12.0, please add back if you disagree. > Evaluate signing key generation > --- > > Key: NIFI-7569 > URL: https://issues.apache.org/jira/browse/NIFI-7569 > Project: Apache NiFi > Issue Type: Sub-task >Affects Versions: 1.11.4 >Reporter: Nathan Gough >Assignee: Nathan Gough >Priority: Major > Fix For: 1.12.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7569) Evaluate signing key generation
[ https://issues.apache.org/jira/browse/NIFI-7569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Bende updated NIFI-7569: -- Fix Version/s: (was: 1.12.0) > Evaluate signing key generation > --- > > Key: NIFI-7569 > URL: https://issues.apache.org/jira/browse/NIFI-7569 > Project: Apache NiFi > Issue Type: Sub-task >Affects Versions: 1.11.4 >Reporter: Nathan Gough >Assignee: Nathan Gough >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7634) Add OIDC identity mappings
[ https://issues.apache.org/jira/browse/NIFI-7634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Bende updated NIFI-7634: -- Fix Version/s: (was: 1.12.0) > Add OIDC identity mappings > -- > > Key: NIFI-7634 > URL: https://issues.apache.org/jira/browse/NIFI-7634 > Project: Apache NiFi > Issue Type: New Feature > Components: Security >Affects Versions: 1.11.4 >Reporter: Nathan Gough >Assignee: Nathan Gough >Priority: Major > > Add identity mappings for OIDC identities, such that the user database and > JWT and NiFi will use the mapped identity if configured. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-7634) Add OIDC identity mappings
[ https://issues.apache.org/jira/browse/NIFI-7634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163513#comment-17163513 ] Bryan Bende commented on NIFI-7634: --- Going to remove the fix version as this doesn't seem to be a blocker for 1.12.0, please add back if you disagree. > Add OIDC identity mappings > -- > > Key: NIFI-7634 > URL: https://issues.apache.org/jira/browse/NIFI-7634 > Project: Apache NiFi > Issue Type: New Feature > Components: Security >Affects Versions: 1.11.4 >Reporter: Nathan Gough >Assignee: Nathan Gough >Priority: Major > Fix For: 1.12.0 > > > Add identity mappings for OIDC identities, such that the user database and > JWT and NiFi will use the mapped identity if configured. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [nifi-minifi-cpp] szaszm commented on a change in pull request #807: MINIFICPP-1228 - Resource ownership refactor + flowFile-owning processors.
szaszm commented on a change in pull request #807: URL: https://github.com/apache/nifi-minifi-cpp/pull/807#discussion_r459389896 ## File path: libminifi/include/core/Repository.h ## @@ -31,6 +31,7 @@ #include #include #include +#include "core/Deprecated.h" Review comment: This header is no longer needed This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi-minifi-cpp] arpadboda closed pull request #847: MINIFICPP-1304 - InvokeHTTP can get triggered too frequently in case …
arpadboda closed pull request #847: URL: https://github.com/apache/nifi-minifi-cpp/pull/847 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (NIFI-7549) Addign Hazelcast based implementation for DistributedMapCacheClient
[ https://issues.apache.org/jira/browse/NIFI-7549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163504#comment-17163504 ] Bryan Bende commented on NIFI-7549: --- Removing fix version as this is not a blocker for the 1.12.0 release. > Addign Hazelcast based implementation for DistributedMapCacheClient > --- > > Key: NIFI-7549 > URL: https://issues.apache.org/jira/browse/NIFI-7549 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Reporter: Simon Bence >Assignee: Simon Bence >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Adding Hazelcast support in the same fashion as in case of Redis for example > would be useful. Even further: in order to make it easier to use, embedded > Hazelcast support should be added, which makes it unnecessary to start > Hazelcast cluster manually. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7549) Addign Hazelcast based implementation for DistributedMapCacheClient
[ https://issues.apache.org/jira/browse/NIFI-7549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Bende updated NIFI-7549: -- Fix Version/s: (was: 1.12.0) > Addign Hazelcast based implementation for DistributedMapCacheClient > --- > > Key: NIFI-7549 > URL: https://issues.apache.org/jira/browse/NIFI-7549 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Reporter: Simon Bence >Assignee: Simon Bence >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Adding Hazelcast support in the same fashion as in case of Redis for example > would be useful. Even further: in order to make it easier to use, embedded > Hazelcast support should be added, which makes it unnecessary to start > Hazelcast cluster manually. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7667) Add variable support to GetHBase properties
[ https://issues.apache.org/jira/browse/NIFI-7667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-7667: - Status: Patch Available (was: Open) > Add variable support to GetHBase properties > --- > > Key: NIFI-7667 > URL: https://issues.apache.org/jira/browse/NIFI-7667 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Add variable support to GetHBase properties. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [nifi] pvillard31 opened a new pull request #4424: NIFI-7667 - add variable support to GetHBase properties
pvillard31 opened a new pull request #4424:
URL: https://github.com/apache/nifi/pull/4424
Thank you for submitting a contribution to Apache NiFi.
Please provide a short description of the PR here:
Description of PR
_Enables X functionality; fixes bug NIFI-._
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?
- [ ] Does your PR title start with **NIFI-** where is the JIRA
number you are trying to resolve? Pay particular attention to the hyphen "-"
character.
- [ ] Has your PR been rebased against the latest commit within the target
branch (typically `main`)?
- [ ] Is your initial contribution a single, squashed commit? _Additional
commits in response to PR reviewer feedback should be made on this branch and
pushed to allow change tracking. Do not `squash` or use `--force` when pushing
to allow for clean monitoring of changes._
### For code changes:
- [ ] Have you ensured that the full suite of tests is executed via `mvn
-Pcontrib-check clean install` at the root `nifi` folder?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] Have you verified that the full build is successful on JDK 8?
- [ ] Have you verified that the full build is successful on JDK 11?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] If applicable, have you updated the `LICENSE` file, including the main
`LICENSE` file under `nifi-assembly`?
- [ ] If applicable, have you updated the `NOTICE` file, including the main
`NOTICE` file found under `nifi-assembly`?
- [ ] If adding new Properties, have you added `.displayName` in addition to
.name (programmatic access) for each of the new properties?
### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in which
it is rendered?
### Note:
Please ensure that once the PR is submitted, you check GitHub Actions CI for
build issues and submit an update to your PR as soon as possible.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Created] (NIFI-7667) Add variable support to GetHBase properties
Pierre Villard created NIFI-7667: Summary: Add variable support to GetHBase properties Key: NIFI-7667 URL: https://issues.apache.org/jira/browse/NIFI-7667 Project: Apache NiFi Issue Type: Improvement Components: Extensions Reporter: Pierre Villard Assignee: Pierre Villard Add variable support to GetHBase properties. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-7521) Cleanup nifi.properties
[ https://issues.apache.org/jira/browse/NIFI-7521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163501#comment-17163501 ] ASF subversion and git services commented on NIFI-7521: --- Commit e9a443fe2e1424087fd4063f6d43e55a461ffbcb in nifi's branch refs/heads/main from Bryan Bende [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=e9a443f ] NIFI-7521 Remove additional unused property from nifi proeprties This closes #4327. > Cleanup nifi.properties > --- > > Key: NIFI-7521 > URL: https://issues.apache.org/jira/browse/NIFI-7521 > Project: Apache NiFi > Issue Type: Task > Components: Configuration >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Major > Fix For: 1.12.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > There are a few entries in `nifi.properties` such as the number of threads to > use for swapping data in/out that are no longer used. These properties should > be removed. > There are also properties whose defaults have proven not to be the best > defaults. Better defaults should be set for these. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7521) Cleanup nifi.properties
[ https://issues.apache.org/jira/browse/NIFI-7521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Bende updated NIFI-7521: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Cleanup nifi.properties > --- > > Key: NIFI-7521 > URL: https://issues.apache.org/jira/browse/NIFI-7521 > Project: Apache NiFi > Issue Type: Task > Components: Configuration >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Major > Fix For: 1.12.0 > > Time Spent: 40m > Remaining Estimate: 0h > > There are a few entries in `nifi.properties` such as the number of threads to > use for swapping data in/out that are no longer used. These properties should > be removed. > There are also properties whose defaults have proven not to be the best > defaults. Better defaults should be set for these. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-7521) Cleanup nifi.properties
[ https://issues.apache.org/jira/browse/NIFI-7521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163500#comment-17163500 ] ASF subversion and git services commented on NIFI-7521: --- Commit e371f4ac7ccaa212439f9f0e4b519cfdad0c3af0 in nifi's branch refs/heads/main from Mark Payne [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=e371f4a ] NIFI-7521: Removed unused properties from nifi properties. Updated the defaults to use for File System's archive cleanup, flowfile checkpoint interval > Cleanup nifi.properties > --- > > Key: NIFI-7521 > URL: https://issues.apache.org/jira/browse/NIFI-7521 > Project: Apache NiFi > Issue Type: Task > Components: Configuration >Reporter: Mark Payne >Assignee: Mark Payne >Priority: Major > Fix For: 1.12.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > There are a few entries in `nifi.properties` such as the number of threads to > use for swapping data in/out that are no longer used. These properties should > be removed. > There are also properties whose defaults have proven not to be the best > defaults. Better defaults should be set for these. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [nifi] asfgit closed pull request #4327: NIFI-7521: Removed unused properties from nifi properties. Updated th…
asfgit closed pull request #4327: URL: https://github.com/apache/nifi/pull/4327 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (NIFI-7616) PrometheusReportingTask: Wrong number of processor active threads reported ?
[
https://issues.apache.org/jira/browse/NIFI-7616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Bende updated NIFI-7616:
--
Fix Version/s: (was: 1.12.0)
> PrometheusReportingTask: Wrong number of processor active threads reported ?
>
>
> Key: NIFI-7616
> URL: https://issues.apache.org/jira/browse/NIFI-7616
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Reporter: Benjamin Charron
>Priority: Trivial
> Labels: Metrics, reporting_task
> Attachments: nifi-metrics.diff
>
>
> The number of _processor_ active threads reported by prometheus
> ("nifi_amount_threads_active") seem off.
> I think "{{status.getActiveThreadCount()}}" should be
> "{{processorStatus.getActiveThreadCount()}}" at
> [PrometheusMetricsUtil.java:193|https://github.com/apache/nifi/blob/aa741cc5967f62c3c38c2a47e712b7faa6fe19ff/nifi-nar-bundles/nifi-extension-utils/nifi-prometheus-utils/src/main/java/org/apache/nifi/prometheus/util/PrometheusMetricsUtil.java#L193]
> and :194
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NIFI-7616) PrometheusReportingTask: Wrong number of processor active threads reported ?
[
https://issues.apache.org/jira/browse/NIFI-7616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163498#comment-17163498
]
Bryan Bende commented on NIFI-7616:
---
Thanks for creating this, just needs to get review from someone familiar with
the prometheus reporting task. [~mattyb149] appears to have done work on it,
maybe he can take a look.
In the meantime, I'm going to remove the fix version since this is not a
blocker for the 1.12.0 release.
> PrometheusReportingTask: Wrong number of processor active threads reported ?
>
>
> Key: NIFI-7616
> URL: https://issues.apache.org/jira/browse/NIFI-7616
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Reporter: Benjamin Charron
>Priority: Trivial
> Labels: Metrics, reporting_task
> Fix For: 1.12.0
>
> Attachments: nifi-metrics.diff
>
>
> The number of _processor_ active threads reported by prometheus
> ("nifi_amount_threads_active") seem off.
> I think "{{status.getActiveThreadCount()}}" should be
> "{{processorStatus.getActiveThreadCount()}}" at
> [PrometheusMetricsUtil.java:193|https://github.com/apache/nifi/blob/aa741cc5967f62c3c38c2a47e712b7faa6fe19ff/nifi-nar-bundles/nifi-extension-utils/nifi-prometheus-utils/src/main/java/org/apache/nifi/prometheus/util/PrometheusMetricsUtil.java#L193]
> and :194
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NIFI-7656) TestZooKeeperStateServer fails on Win10 latest Java8
[ https://issues.apache.org/jira/browse/NIFI-7656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Bende updated NIFI-7656: -- Fix Version/s: (was: 1.12.0) > TestZooKeeperStateServer fails on Win10 latest Java8 > > > Key: NIFI-7656 > URL: https://issues.apache.org/jira/browse/NIFI-7656 > Project: Apache NiFi > Issue Type: Test > Components: Tools and Build > Environment: openjdk version "1.8.0_242" > OpenJDK Runtime Environment (build 1.8.0_242-b08) > OpenJDK 64-Bit Server VM (build 25.242-b08, mixed mode) > Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; > 2015-11-10T11:41:47-05:00) > Maven home: C:\development\tools\apache-maven-3.3.9 > Java version: 1.8.0_102, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.8.0_102\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos" >Reporter: Joe Witt >Priority: Major > > [ERROR] > testServerCreatePath(org.apache.nifi.controller.state.server.zookeeper.TestZooKeeperStateServer) > Time elapsed: 0.163 s <<< ERROR! > org.apache.zookeeper.KeeperException$NodeExistsException: KeeperErrorCode = > NodeExists for /test > at > org.apache.nifi.controller.state.server.zookeeper.TestZooKeeperStateServer.testServerCreatePath(TestZooKeeperStateServer.java:130) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-7656) TestZooKeeperStateServer fails on Win10 latest Java8
[ https://issues.apache.org/jira/browse/NIFI-7656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163489#comment-17163489 ] Bryan Bende commented on NIFI-7656: --- I'll remove fix version, please add back if you disagree. > TestZooKeeperStateServer fails on Win10 latest Java8 > > > Key: NIFI-7656 > URL: https://issues.apache.org/jira/browse/NIFI-7656 > Project: Apache NiFi > Issue Type: Test > Components: Tools and Build > Environment: openjdk version "1.8.0_242" > OpenJDK Runtime Environment (build 1.8.0_242-b08) > OpenJDK 64-Bit Server VM (build 25.242-b08, mixed mode) > Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; > 2015-11-10T11:41:47-05:00) > Maven home: C:\development\tools\apache-maven-3.3.9 > Java version: 1.8.0_102, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.8.0_102\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos" >Reporter: Joe Witt >Priority: Major > Fix For: 1.12.0 > > > [ERROR] > testServerCreatePath(org.apache.nifi.controller.state.server.zookeeper.TestZooKeeperStateServer) > Time elapsed: 0.163 s <<< ERROR! > org.apache.zookeeper.KeeperException$NodeExistsException: KeeperErrorCode = > NodeExists for /test > at > org.apache.nifi.controller.state.server.zookeeper.TestZooKeeperStateServer.testServerCreatePath(TestZooKeeperStateServer.java:130) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (NIFI-7666) Allow parametrizing SQL statements based on custom processor fields
Malthe Borch created NIFI-7666:
--
Summary: Allow parametrizing SQL statements based on custom
processor fields
Key: NIFI-7666
URL: https://issues.apache.org/jira/browse/NIFI-7666
Project: Apache NiFi
Issue Type: New Feature
Reporter: Malthe Borch
Today, query processors such as ExecuteSQL allow parametrized SQL statements
based on incoming flow file attributes on the form
"sql.args.N.{type;value;format}".
This is a proposal to add a secondary mode where these parameters are drawn
instead from custom properties.
When the secondary mode (i.e. "Use custom properties to set parameters") is
enabled, custom properties are used instead of flow file attributes.
* The NiFi Expression Language can be used in these properties (will be
evaluated using flow file attributes and variable registry).
* In addition to "sql.args.N.value" there will be a sensitive version
"sql.args.N.sensitive". It's an error to provide both.
That is, in addition to providing improved ergonomics (allowing the processor
to control the parameters, possibly drawing from more human-friendly attribute
names), this also enables the use of sensitive properties. As a specific
example, a database can have a "COPY INTO" statement which supports the
ingestion of data from blob storage requiring an authentication token.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [nifi] bbende commented on a change in pull request #4327: NIFI-7521: Removed unused properties from nifi properties. Updated th…
bbende commented on a change in pull request #4327:
URL: https://github.com/apache/nifi/pull/4327#discussion_r459394258
##
File path:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-resources/src/main/resources/conf/nifi.properties
##
@@ -93,7 +87,6 @@
nifi.content.repository.encryption.key=${nifi.content.repository.encryption.key}
# Provenance Repository Properties
nifi.provenance.repository.implementation=${nifi.provenance.repository.implementation}
-nifi.provenance.repository.debug.frequency=${nifi.provenance.repository.debug.frequency}
Review comment:
Good catch, I'm going to make that update and get this merged
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (NIFI-7118) Create documentation for the new sensitive property providers
[ https://issues.apache.org/jira/browse/NIFI-7118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Bende updated NIFI-7118: -- Fix Version/s: (was: 1.12.0) > Create documentation for the new sensitive property providers > - > > Key: NIFI-7118 > URL: https://issues.apache.org/jira/browse/NIFI-7118 > Project: Apache NiFi > Issue Type: Task > Components: Security >Reporter: Nathan Gough >Priority: Major > > Configuration documentation and examples around using the new sensitive > property providers should be written. > It should also clearly state that these features are experimental. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-7118) Create documentation for the new sensitive property providers
[ https://issues.apache.org/jira/browse/NIFI-7118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163472#comment-17163472 ] Bryan Bende commented on NIFI-7118: --- Going to unset the fix version here since the work for the parent is not complete yet. > Create documentation for the new sensitive property providers > - > > Key: NIFI-7118 > URL: https://issues.apache.org/jira/browse/NIFI-7118 > Project: Apache NiFi > Issue Type: Task > Components: Security >Reporter: Nathan Gough >Priority: Major > Fix For: 1.12.0 > > > Configuration documentation and examples around using the new sensitive > property providers should be written. > It should also clearly state that these features are experimental. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-7600) Defining JMS attribute types breaks due to invalid characters
[ https://issues.apache.org/jira/browse/NIFI-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163470#comment-17163470 ] Bryan Bende commented on NIFI-7600: --- Thanks for submitting this. I'm going to unset the fix version of 1.12.0 since this isn't a blocker for that release. > Defining JMS attribute types breaks due to invalid characters > - > > Key: NIFI-7600 > URL: https://issues.apache.org/jira/browse/NIFI-7600 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.11.4 >Reporter: Darren Hitchman >Assignee: Darren Hitchman >Priority: Major > Labels: JMS > Fix For: 1.12.0 > > Original Estimate: 4h > Time Spent: 40m > Remaining Estimate: 3h 20m > > JMSPublisher causes Exception when setting attributes in the JMS message due > to invalid characters. When defining types to be used when sending JMS > attributes (e.g. JMS_IBM_Encoding.type=integer) , the JMSPublishercorrectly > sets the type but also adds the '.type' attribute into the message, causing > an Exception as JMS doesnt support a dot character in attribute names. > NIFI-6957 was suppose to fix this however the change in JMSPublish was > removed. > There is an option to 'allowIllegalChars' in PublishJMS however '.type' > attributes are passed along regardless of this setting. > > The JMSPublisher should ignore message attributes ending with '.type' when > there is a matching attribute without the '.type' suffix > > example exception. > > com.ibm.msg.client.jms.DetailedMessageFormatException: JMSCC0049: The > property name 'JMS_IBM_Encoding.type' is not a valid Java(tm) identifier. > The supplied property name does not conform to the allowed format described > in the JMS specification. > Check the characters used in the property name and modify as necessary. > at > java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) > at > com.ibm.msg.client.commonservices.j2se.NLSServices.createException(NLSServices.java:319) > at > com.ibm.msg.client.commonservices.nls.NLSServices.createException(NLSServices.java:226) > at > com.ibm.msg.client.jms.internal.JmsErrorUtils.createException(JmsErrorUtils.java:126) > at > com.ibm.msg.client.jms.internal.JmsMessageImpl.checkPropName(JmsMessageImpl.java:2595) > at > com.ibm.msg.client.jms.internal.JmsMessageImpl.setStringProperty(JmsMessageImpl.java:1997) > at > com.ibm.jms.JMSMessage.setStringProperty(JMSMessage.java:1516) > at > jdk.internal.reflect.GeneratedMethodAccessor198.invoke(Unknown Source) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at > org.apache.nifi.controller.service.StandardControllerServiceInvocationHandler.invoke(StandardControllerServiceInvocationHandler.java:254) > at > org.apache.nifi.controller.service.StandardControllerServiceInvocationHandler$ProxiedReturnObjectInvocationHandler.invoke(StandardControllerServiceInvocationHandler.java:240) > at com.sun.proxy.$Proxy145.setStringProperty(Unknown Source) > at > org.apache.nifi.jms.processors.JMSPublisher$JmsPropertySetterEnum.lambda$static$7(JMSPublisher.java:196) > at > org.apache.nifi.jms.processors.JMSPublisher$JmsPropertySetterEnum.setProperty(JMSPublisher.java:205) > at > org.apache.nifi.jms.processors.JMSPublisher.setMessageHeaderAndProperties(JMSPublisher.java:123) > at > org.apache.nifi.jms.processors.JMSPublisher$1.createMessage(JMSPublisher.java:59) > at > org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:593) > at > org.springframework.jms.core.JmsTemplate$4.doInJms(JmsTemplate.java:574) > at > org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:484) > at > org.springframework.jms.core.JmsTemplate.send(JmsTemplate.java:570) > at > org.apache.nifi.jms.processors.JMSPublisher.publish(JMSPublisher.java:54) > at >
[jira] [Updated] (NIFI-7600) Defining JMS attribute types breaks due to invalid characters
[ https://issues.apache.org/jira/browse/NIFI-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Bende updated NIFI-7600: -- Fix Version/s: (was: 1.12.0) > Defining JMS attribute types breaks due to invalid characters > - > > Key: NIFI-7600 > URL: https://issues.apache.org/jira/browse/NIFI-7600 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.11.4 >Reporter: Darren Hitchman >Assignee: Darren Hitchman >Priority: Major > Labels: JMS > Original Estimate: 4h > Time Spent: 40m > Remaining Estimate: 3h 20m > > JMSPublisher causes Exception when setting attributes in the JMS message due > to invalid characters. When defining types to be used when sending JMS > attributes (e.g. JMS_IBM_Encoding.type=integer) , the JMSPublishercorrectly > sets the type but also adds the '.type' attribute into the message, causing > an Exception as JMS doesnt support a dot character in attribute names. > NIFI-6957 was suppose to fix this however the change in JMSPublish was > removed. > There is an option to 'allowIllegalChars' in PublishJMS however '.type' > attributes are passed along regardless of this setting. > > The JMSPublisher should ignore message attributes ending with '.type' when > there is a matching attribute without the '.type' suffix > > example exception. > > com.ibm.msg.client.jms.DetailedMessageFormatException: JMSCC0049: The > property name 'JMS_IBM_Encoding.type' is not a valid Java(tm) identifier. > The supplied property name does not conform to the allowed format described > in the JMS specification. > Check the characters used in the property name and modify as necessary. > at > java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) > at > com.ibm.msg.client.commonservices.j2se.NLSServices.createException(NLSServices.java:319) > at > com.ibm.msg.client.commonservices.nls.NLSServices.createException(NLSServices.java:226) > at > com.ibm.msg.client.jms.internal.JmsErrorUtils.createException(JmsErrorUtils.java:126) > at > com.ibm.msg.client.jms.internal.JmsMessageImpl.checkPropName(JmsMessageImpl.java:2595) > at > com.ibm.msg.client.jms.internal.JmsMessageImpl.setStringProperty(JmsMessageImpl.java:1997) > at > com.ibm.jms.JMSMessage.setStringProperty(JMSMessage.java:1516) > at > jdk.internal.reflect.GeneratedMethodAccessor198.invoke(Unknown Source) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at > org.apache.nifi.controller.service.StandardControllerServiceInvocationHandler.invoke(StandardControllerServiceInvocationHandler.java:254) > at > org.apache.nifi.controller.service.StandardControllerServiceInvocationHandler$ProxiedReturnObjectInvocationHandler.invoke(StandardControllerServiceInvocationHandler.java:240) > at com.sun.proxy.$Proxy145.setStringProperty(Unknown Source) > at > org.apache.nifi.jms.processors.JMSPublisher$JmsPropertySetterEnum.lambda$static$7(JMSPublisher.java:196) > at > org.apache.nifi.jms.processors.JMSPublisher$JmsPropertySetterEnum.setProperty(JMSPublisher.java:205) > at > org.apache.nifi.jms.processors.JMSPublisher.setMessageHeaderAndProperties(JMSPublisher.java:123) > at > org.apache.nifi.jms.processors.JMSPublisher$1.createMessage(JMSPublisher.java:59) > at > org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:593) > at > org.springframework.jms.core.JmsTemplate$4.doInJms(JmsTemplate.java:574) > at > org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:484) > at > org.springframework.jms.core.JmsTemplate.send(JmsTemplate.java:570) > at > org.apache.nifi.jms.processors.JMSPublisher.publish(JMSPublisher.java:54) > at > org.apache.nifi.jms.processors.PublishJMS.rendezvousWithJms(PublishJMS.java:214) > at > org.apache.nifi.jms.processors.PublishJMS.rendezvousWithJms(PublishJMS.java:68) > at >
[jira] [Commented] (NIFI-7656) TestZooKeeperStateServer fails on Win10 latest Java8
[ https://issues.apache.org/jira/browse/NIFI-7656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163467#comment-17163467 ] Bryan Bende commented on NIFI-7656: --- Does this need to be tagged for 1.12.0? > TestZooKeeperStateServer fails on Win10 latest Java8 > > > Key: NIFI-7656 > URL: https://issues.apache.org/jira/browse/NIFI-7656 > Project: Apache NiFi > Issue Type: Test > Components: Tools and Build > Environment: openjdk version "1.8.0_242" > OpenJDK Runtime Environment (build 1.8.0_242-b08) > OpenJDK 64-Bit Server VM (build 25.242-b08, mixed mode) > Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; > 2015-11-10T11:41:47-05:00) > Maven home: C:\development\tools\apache-maven-3.3.9 > Java version: 1.8.0_102, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.8.0_102\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos" >Reporter: Joe Witt >Priority: Major > Fix For: 1.12.0 > > > [ERROR] > testServerCreatePath(org.apache.nifi.controller.state.server.zookeeper.TestZooKeeperStateServer) > Time elapsed: 0.163 s <<< ERROR! > org.apache.zookeeper.KeeperException$NodeExistsException: KeeperErrorCode = > NodeExists for /test > at > org.apache.nifi.controller.state.server.zookeeper.TestZooKeeperStateServer.testServerCreatePath(TestZooKeeperStateServer.java:130) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (NIFI-7432) Replace method in Redis DMC client service does not set TTL
[ https://issues.apache.org/jira/browse/NIFI-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Bende resolved NIFI-7432. --- Fix Version/s: 1.12.0 Resolution: Fixed Resolved as part of NIFI-7373. > Replace method in Redis DMC client service does not set TTL > --- > > Key: NIFI-7432 > URL: https://issues.apache.org/jira/browse/NIFI-7432 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.11.4 >Reporter: Bryan Bende >Assignee: Bryan Bende >Priority: Minor > Fix For: 1.12.0 > > > The Redis DMC client service has a TTL property that was added after the > initial implementation. The "replace" method does not set the TTL, but should > be. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (NIFI-7373) Add a bulk put method to DistributedMapCache
[ https://issues.apache.org/jira/browse/NIFI-7373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Bende resolved NIFI-7373. --- Fix Version/s: 1.12.0 Resolution: Fixed > Add a bulk put method to DistributedMapCache > > > Key: NIFI-7373 > URL: https://issues.apache.org/jira/browse/NIFI-7373 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Mike Thomsen >Assignee: Mike Thomsen >Priority: Major > Fix For: 1.12.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The method should allow you to put a Map of key value pairs into a > distributed map cache. It should provide a default implementation that calls > put() as it iterates over the map. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (NIFI-7432) Replace method in Redis DMC client service does not set TTL
[ https://issues.apache.org/jira/browse/NIFI-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Bende reassigned NIFI-7432: - Assignee: Bryan Bende > Replace method in Redis DMC client service does not set TTL > --- > > Key: NIFI-7432 > URL: https://issues.apache.org/jira/browse/NIFI-7432 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.11.4 >Reporter: Bryan Bende >Assignee: Bryan Bende >Priority: Minor > > The Redis DMC client service has a TTL property that was added after the > initial implementation. The "replace" method does not set the TTL, but should > be. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-7373) Add a bulk put method to DistributedMapCache
[ https://issues.apache.org/jira/browse/NIFI-7373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163462#comment-17163462 ] ASF subversion and git services commented on NIFI-7373: --- Commit 99b3780ad96df3e54584362a5d8edf6967668d2d in nifi's branch refs/heads/main from Bryan Bende [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=99b3780 ] NIFI-7373 Setting TTL on keys in Redis putAll This closes #4217. > Add a bulk put method to DistributedMapCache > > > Key: NIFI-7373 > URL: https://issues.apache.org/jira/browse/NIFI-7373 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Mike Thomsen >Assignee: Mike Thomsen >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > The method should allow you to put a Map of key value pairs into a > distributed map cache. It should provide a default implementation that calls > put() as it iterates over the map. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (NIFI-7373) Add a bulk put method to DistributedMapCache
[ https://issues.apache.org/jira/browse/NIFI-7373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163461#comment-17163461 ] ASF subversion and git services commented on NIFI-7373: --- Commit 0e61dbc9a02801f7bef21b43c3a7bdd644c5b281 in nifi's branch refs/heads/main from Mike Thomsen [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=0e61dbc ] NIFI-7373 Added new methods to DistributedMapCacheClient for bulk get and put. Updated HBase 1.1.2 clients. Added HBase 2 support. Added Redis support. > Add a bulk put method to DistributedMapCache > > > Key: NIFI-7373 > URL: https://issues.apache.org/jira/browse/NIFI-7373 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Mike Thomsen >Assignee: Mike Thomsen >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > The method should allow you to put a Map of key value pairs into a > distributed map cache. It should provide a default implementation that calls > put() as it iterates over the map. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [nifi] asfgit closed pull request #4217: NIFI-7373 - Add putAll method to DistributedMapCacheClient interface
asfgit closed pull request #4217: URL: https://github.com/apache/nifi/pull/4217 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi] kent-nguyen opened a new pull request #4423: NIFI-7664 - Add Content Disposition property to PutS3Object processor
kent-nguyen opened a new pull request #4423: URL: https://github.com/apache/nifi/pull/4423 Add new property 'Content Disposition' to allow user to set the content-disposition http header on the S3 object. Allowed values are 'inline' (default) and 'attachment'. If 'attachment' is selected, the filename will be set to the S3 Object key. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (NIFI-6332) PutS3 Processor adding Cache-Control property
[ https://issues.apache.org/jira/browse/NIFI-6332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163431#comment-17163431 ] Kent Nguyen commented on NIFI-6332: --- Add Cache Control property to PutS3Object processor. > PutS3 Processor adding Cache-Control property > -- > > Key: NIFI-6332 > URL: https://issues.apache.org/jira/browse/NIFI-6332 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Affects Versions: 1.8.0 >Reporter: Dirk Arends >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The PutS3 Processor does not allow you to set the Cache-Control header. > My use case is to be able to control the Cache-Control header on objects > intended to be served via S3 website hosting. After looking at other issues I > found NIFI-2810 which references [Github PR > 1034|https://github.com/apache/nifi/pull/1034] which added the property > Content-Type to the PutS3Object. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (NIFI-7665) StandardSSLContextService in a validating status forever
Maria Garcia created NIFI-7665: -- Summary: StandardSSLContextService in a validating status forever Key: NIFI-7665 URL: https://issues.apache.org/jira/browse/NIFI-7665 Project: Apache NiFi Issue Type: Bug Components: Configuration Affects Versions: 1.11.4, 1.11.0 Reporter: Maria Garcia Attachments: validatingStatus.PNG StandardSSLContextService 1.11.0 remains in a `Validating` status for ever. But everything is working as expected. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [nifi] kent-nguyen opened a new pull request #4422: NIFI-6332 - Add Cache Control property to PutS3Object processor
kent-nguyen opened a new pull request #4422: URL: https://github.com/apache/nifi/pull/4422 Add new property 'Cache Control' to allow user to set the cache-control http header on the S3 object. This property is not required, and has no default value. The implementation is similar to the Content-Type property, except that this property does not allow Expression Language. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi-minifi-cpp] arpadboda commented on pull request #847: MINIFICPP-1304 - InvokeHTTP can get triggered too frequently in case …
arpadboda commented on pull request #847: URL: https://github.com/apache/nifi-minifi-cpp/pull/847#issuecomment-662894573 @szaszm : "Arbitrary methods are also supported. Methods other than POST, PUT and PATCH will be sent without a message body." This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (NIFI-6332) PutS3 Processor adding Cache-Control property
[ https://issues.apache.org/jira/browse/NIFI-6332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Arends updated NIFI-6332: -- Description: The PutS3 Processor does not allow you to set the Cache-Control header. My use case is to be able to control the Cache-Control header on objects intended to be served via S3 website hosting. After looking at other issues I found NIFI-2810 which references [Github PR 1034|https://github.com/apache/nifi/pull/1034] which added the property Content-Type to the PutS3Object. was: The PutS3 Processor does not allow you to set the Cache-Control header. My use case is to be able to control the Cache-Control header objects intended to be served via S3 website hosting. After looking at other issues I found NIFI-2810 which references [Github PR 1034|https://github.com/apache/nifi/pull/1034] which added the property Content-Type to the PutS3Object. > PutS3 Processor adding Cache-Control property > -- > > Key: NIFI-6332 > URL: https://issues.apache.org/jira/browse/NIFI-6332 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Affects Versions: 1.8.0 >Reporter: Dirk Arends >Priority: Major > > The PutS3 Processor does not allow you to set the Cache-Control header. > My use case is to be able to control the Cache-Control header on objects > intended to be served via S3 website hosting. After looking at other issues I > found NIFI-2810 which references [Github PR > 1034|https://github.com/apache/nifi/pull/1034] which added the property > Content-Type to the PutS3Object. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7664) PutS3 Processor adding Content-Disposition property
[ https://issues.apache.org/jira/browse/NIFI-7664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Arends updated NIFI-7664: -- Description: The PutS3 Processor does not allow you to set the Content-Disposition header. My use case is to be able to control the Content-Disposition header on objects intended to be served via S3 website hosting. This is related to NIFI-6332 and both changes can be use NIFI-2810 as an example of how to implement the changes as NIFI-2810 adds the property Content-Type to the PutS3Object. was: The PutS3 Processor does not allow you to set the Content-Disposition header. My use case is to be able to control the Content-Disposition header objects intended to be served via S3 website hosting. This is related to NIFI-6332 and both changes can be use NIFI-2810 as an example of how to implement the changes as NIFI-2810 adds the property Content-Type to the PutS3Object. > PutS3 Processor adding Content-Disposition property > --- > > Key: NIFI-7664 > URL: https://issues.apache.org/jira/browse/NIFI-7664 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Dirk Arends >Priority: Major > > The PutS3 Processor does not allow you to set the Content-Disposition header. > My use case is to be able to control the Content-Disposition header on > objects intended to be served via S3 website hosting. > This is related to NIFI-6332 and both changes can be use NIFI-2810 as an > example of how to implement the changes as NIFI-2810 adds the property > Content-Type to the PutS3Object. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NIFI-7664) PutS3 Processor adding Content-Disposition property
[ https://issues.apache.org/jira/browse/NIFI-7664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Arends updated NIFI-7664: -- Description: The PutS3 Processor does not allow you to set the Content-Disposition header. My use case is to be able to control the Content-Disposition header objects intended to be served via S3 website hosting. This is related to NIFI-6332 and both changes can be use NIFI-2810 as an example of how to implement the changes as NIFI-2810 adds the property Content-Type to the PutS3Object. was: The PutS3 Processor does not allow you to set the Content-Disposition header. My use case is to be able to control the Cache-Control header objects intended to be served via S3 website hosting. This is related to NIFI-6332 and both changes can be use NIFI-2810 as an example of how to implement the changes as NIFI-2810 adds the property Content-Type to the PutS3Object. > PutS3 Processor adding Content-Disposition property > --- > > Key: NIFI-7664 > URL: https://issues.apache.org/jira/browse/NIFI-7664 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Dirk Arends >Priority: Major > > The PutS3 Processor does not allow you to set the Content-Disposition header. > My use case is to be able to control the Content-Disposition header objects > intended to be served via S3 website hosting. > This is related to NIFI-6332 and both changes can be use NIFI-2810 as an > example of how to implement the changes as NIFI-2810 adds the property > Content-Type to the PutS3Object. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (NIFI-7664) PutS3 Processor adding Content-Disposition property
Dirk Arends created NIFI-7664: - Summary: PutS3 Processor adding Content-Disposition property Key: NIFI-7664 URL: https://issues.apache.org/jira/browse/NIFI-7664 Project: Apache NiFi Issue Type: Improvement Reporter: Dirk Arends The PutS3 Processor does not allow you to set the Content-Disposition header. My use case is to be able to control the Cache-Control header objects intended to be served via S3 website hosting. This is related to NIFI-6332 and both changes can be use NIFI-2810 as an example of how to implement the changes as NIFI-2810 adds the property Content-Type to the PutS3Object. -- This message was sent by Atlassian Jira (v8.3.4#803005)
