[jira] [Commented] (NIFI-3983) Support ability to make JMS 2.0 durable subscriptions on Topic
[
https://issues.apache.org/jira/browse/NIFI-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065976#comment-16065976
]
ASF GitHub Bot commented on NIFI-3983:
--
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1863#discussion_r124459881
--- Diff:
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/AbstractJMSProcessor.java
---
@@ -196,7 +207,10 @@ private void buildTargetResource(ProcessContext
context) {
this.cachingConnectionFactory = new
CachingConnectionFactory(cfCredentialsAdapter);
this.cachingConnectionFactory.setSessionCacheSize(Integer.parseInt(context.getProperty(SESSION_CACHE_SIZE).getValue()));
-
+String clientId = context.getProperty(CLIENT_ID).getValue();
--- End diff --
just added evaluateAttributeExpressions() to the call chain. i assume this
is what is needed (sorry not a nifi code expert)
> Support ability to make JMS 2.0 durable subscriptions on Topic
> --
>
> Key: NIFI-3983
> URL: https://issues.apache.org/jira/browse/NIFI-3983
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Michael Andre Pearce
>
> Currently the jms consumer, only supports standard queue consumption and
> topic subscription. For topics, in JMS 2.0 you can make shared durable
> subscribers which gives a subscription semantic similar to queue per
> subscription name, meaning message is delivered once per subscription. This
> is very useful in setups using JMS 2.0.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] nifi pull request #1863: NIFI-3983 - Support ability to make JMS 2.0 durable...
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1863#discussion_r124459881
--- Diff:
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/AbstractJMSProcessor.java
---
@@ -196,7 +207,10 @@ private void buildTargetResource(ProcessContext
context) {
this.cachingConnectionFactory = new
CachingConnectionFactory(cfCredentialsAdapter);
this.cachingConnectionFactory.setSessionCacheSize(Integer.parseInt(context.getProperty(SESSION_CACHE_SIZE).getValue()));
-
+String clientId = context.getProperty(CLIENT_ID).getValue();
--- End diff --
just added evaluateAttributeExpressions() to the call chain. i assume this
is what is needed (sorry not a nifi code expert)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Updated] (NIFI-4135) RangerNiFiAuthorizer should support storing audit info to HDFS
[ https://issues.apache.org/jira/browse/NIFI-4135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yolanda M. Davis updated NIFI-4135: --- Affects Version/s: 1.3.0 Status: Patch Available (was: In Progress) PR is available at https://github.com/apache/nifi/pull/1956 > RangerNiFiAuthorizer should support storing audit info to HDFS > -- > > Key: NIFI-4135 > URL: https://issues.apache.org/jira/browse/NIFI-4135 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Affects Versions: 1.3.0 >Reporter: Yolanda M. Davis >Assignee: Yolanda M. Davis > > When using Ranger to support authorization an option to log auditing > information to HDFS can be supported. The RangerNiFiAuthorizer should be > prepared to communicate with a hadoop cluster in order to support this > feature. In it's current implementation the authorizer does not have the > hadoop-client jars available as a dependency nor does it support the ability > to refer to the required *.site.xml files in order to communicate without > using the default configuration. Both of these changes are needed in order > to send audit info to HDFS. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4135) RangerNiFiAuthorizer should support storing audit info to HDFS
[ https://issues.apache.org/jira/browse/NIFI-4135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065964#comment-16065964 ] ASF GitHub Bot commented on NIFI-4135: -- GitHub user YolandaMDavis opened a pull request: https://github.com/apache/nifi/pull/1956 NIFI-4135 - added hadoop-client and enhanced Authorizers entity to su… …pport classpath for resources entry Thank you for submitting a contribution to Apache 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 master)? - [ ] Is your initial contribution a single, squashed commit? ### 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? - [ ] 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 travis-ci for build issues and submit an update to your PR as soon as possible. You can merge this pull request into a Git repository by running: $ git pull https://github.com/YolandaMDavis/nifi NIFI-4135 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/1956.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1956 commit ade54f9104186e1adf81875a8b777594a5aa7fe8 Author: Yolanda M. Davis Date: 2017-06-28T03:24:04Z NIFI-4135 - added hadoop-client and enhanced Authorizers entity to support classpath for resources entry > RangerNiFiAuthorizer should support storing audit info to HDFS > -- > > Key: NIFI-4135 > URL: https://issues.apache.org/jira/browse/NIFI-4135 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions >Reporter: Yolanda M. Davis >Assignee: Yolanda M. Davis > > When using Ranger to support authorization an option to log auditing > information to HDFS can be supported. The RangerNiFiAuthorizer should be > prepared to communicate with a hadoop cluster in order to support this > feature. In it's current implementation the authorizer does not have the > hadoop-client jars available as a dependency nor does it support the ability > to refer to the required *.site.xml files in order to communicate without > using the default configuration. Both of these changes are needed in order > to send audit info to HDFS. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi pull request #1956: NIFI-4135 - added hadoop-client and enhanced Author...
GitHub user YolandaMDavis opened a pull request: https://github.com/apache/nifi/pull/1956 NIFI-4135 - added hadoop-client and enhanced Authorizers entity to su⦠â¦pport classpath for resources entry Thank you for submitting a contribution to Apache 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 master)? - [ ] Is your initial contribution a single, squashed commit? ### 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? - [ ] 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 travis-ci for build issues and submit an update to your PR as soon as possible. You can merge this pull request into a Git repository by running: $ git pull https://github.com/YolandaMDavis/nifi NIFI-4135 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/1956.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1956 commit ade54f9104186e1adf81875a8b777594a5aa7fe8 Author: Yolanda M. Davis Date: 2017-06-28T03:24:04Z NIFI-4135 - added hadoop-client and enhanced Authorizers entity to support classpath for resources entry --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-3983) Support ability to make JMS 2.0 durable subscriptions on Topic
[
https://issues.apache.org/jira/browse/NIFI-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065931#comment-16065931
]
ASF GitHub Bot commented on NIFI-3983:
--
Github user ijokarumawak commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1863#discussion_r124452787
--- Diff:
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/AbstractJMSProcessor.java
---
@@ -196,7 +207,10 @@ private void buildTargetResource(ProcessContext
context) {
this.cachingConnectionFactory = new
CachingConnectionFactory(cfCredentialsAdapter);
this.cachingConnectionFactory.setSessionCacheSize(Integer.parseInt(context.getProperty(SESSION_CACHE_SIZE).getValue()));
-
+String clientId = context.getProperty(CLIENT_ID).getValue();
--- End diff --
We'd like to evaluate expression here. Currently unit test fails because it
doesn't evaluate expression even if it supports EL.
> Support ability to make JMS 2.0 durable subscriptions on Topic
> --
>
> Key: NIFI-3983
> URL: https://issues.apache.org/jira/browse/NIFI-3983
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Michael Andre Pearce
>
> Currently the jms consumer, only supports standard queue consumption and
> topic subscription. For topics, in JMS 2.0 you can make shared durable
> subscribers which gives a subscription semantic similar to queue per
> subscription name, meaning message is delivered once per subscription. This
> is very useful in setups using JMS 2.0.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] nifi pull request #1863: NIFI-3983 - Support ability to make JMS 2.0 durable...
Github user ijokarumawak commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1863#discussion_r124452787
--- Diff:
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/AbstractJMSProcessor.java
---
@@ -196,7 +207,10 @@ private void buildTargetResource(ProcessContext
context) {
this.cachingConnectionFactory = new
CachingConnectionFactory(cfCredentialsAdapter);
this.cachingConnectionFactory.setSessionCacheSize(Integer.parseInt(context.getProperty(SESSION_CACHE_SIZE).getValue()));
-
+String clientId = context.getProperty(CLIENT_ID).getValue();
--- End diff --
We'd like to evaluate expression here. Currently unit test fails because it
doesn't evaluate expression even if it supports EL.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (NIFI-3983) Support ability to make JMS 2.0 durable subscriptions on Topic
[
https://issues.apache.org/jira/browse/NIFI-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065905#comment-16065905
]
ASF GitHub Bot commented on NIFI-3983:
--
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1863#discussion_r124448868
--- Diff:
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
---
@@ -86,6 +86,31 @@
.defaultValue(CLIENT_ACK.getValue())
.build();
+static final PropertyDescriptor DURABLE_SUBSCRIBER = new
PropertyDescriptor.Builder()
+
.name("Durable subscription")
+
.description("If destination is Topic if present then make it the consumer
durable. " +
+
"@see
https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createDurableConsumer-javax.jms.Topic-java.lang.String-";)
+
.required(false)
+
.expressionLanguageSupported(true)
+
.defaultValue("true")
--- End diff --
corrected, just pushed
> Support ability to make JMS 2.0 durable subscriptions on Topic
> --
>
> Key: NIFI-3983
> URL: https://issues.apache.org/jira/browse/NIFI-3983
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Michael Andre Pearce
>
> Currently the jms consumer, only supports standard queue consumption and
> topic subscription. For topics, in JMS 2.0 you can make shared durable
> subscribers which gives a subscription semantic similar to queue per
> subscription name, meaning message is delivered once per subscription. This
> is very useful in setups using JMS 2.0.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (NIFI-3983) Support ability to make JMS 2.0 durable subscriptions on Topic
[
https://issues.apache.org/jira/browse/NIFI-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065904#comment-16065904
]
ASF GitHub Bot commented on NIFI-3983:
--
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1863#discussion_r124448857
--- Diff:
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
---
@@ -86,6 +86,31 @@
.defaultValue(CLIENT_ACK.getValue())
.build();
+static final PropertyDescriptor DURABLE_SUBSCRIBER = new
PropertyDescriptor.Builder()
+
.name("Durable subscription")
+
.description("If destination is Topic if present then make it the consumer
durable. " +
+
"@see
https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createDurableConsumer-javax.jms.Topic-java.lang.String-";)
+
.required(false)
+
.expressionLanguageSupported(true)
+
.defaultValue("true")
+
.allowableValues("true", "false")
+ .build();
+static final PropertyDescriptor SHARED_SUBSCRIBER = new
PropertyDescriptor.Builder()
+.name("Shared
subscription")
+
.description("If destination is Topic if present then make it the consumer
shared. " +
+
"@see
https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createSharedConsumer-javax.jms.Topic-java.lang.String-";)
+
.required(false)
+
.expressionLanguageSupported(true)
+
.defaultValue("false")
+
.allowableValues("true", "false")
+.build();
+static final PropertyDescriptor SUBSCRIPTION_NAME = new
PropertyDescriptor.Builder()
+
.name("Subscription Name")
+
.description("The name of the subscription to use if destination is Topic and
is shared or durable.")
+
.required(false)
+
.expressionLanguageSupported(true)
+.build();
--- End diff --
added, just pushed.
> Support ability to make JMS 2.0 durable subscriptions on Topic
> --
>
> Key: NIFI-3983
> URL: https://issues.apache.org/jira/browse/NIFI-3983
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Michael Andre Pearce
>
> Currently the jms consumer, only supports standard queue consumption and
> topic subscription. For topics, in JMS 2.0 you can make shared durable
> subscribers which gives a subscription semantic similar to queue per
> subscription name, meaning message is delivered once per subscription. This
> is very useful in setups using JMS 2.0.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] nifi pull request #1863: NIFI-3983 - Support ability to make JMS 2.0 durable...
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1863#discussion_r124448868
--- Diff:
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
---
@@ -86,6 +86,31 @@
.defaultValue(CLIENT_ACK.getValue())
.build();
+static final PropertyDescriptor DURABLE_SUBSCRIBER = new
PropertyDescriptor.Builder()
+
.name("Durable subscription")
+
.description("If destination is Topic if present then make it the consumer
durable. " +
+
"@see
https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createDurableConsumer-javax.jms.Topic-java.lang.String-";)
+
.required(false)
+
.expressionLanguageSupported(true)
+
.defaultValue("true")
--- End diff --
corrected, just pushed
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] nifi pull request #1863: NIFI-3983 - Support ability to make JMS 2.0 durable...
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1863#discussion_r124448857
--- Diff:
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
---
@@ -86,6 +86,31 @@
.defaultValue(CLIENT_ACK.getValue())
.build();
+static final PropertyDescriptor DURABLE_SUBSCRIBER = new
PropertyDescriptor.Builder()
+
.name("Durable subscription")
+
.description("If destination is Topic if present then make it the consumer
durable. " +
+
"@see
https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createDurableConsumer-javax.jms.Topic-java.lang.String-";)
+
.required(false)
+
.expressionLanguageSupported(true)
+
.defaultValue("true")
+
.allowableValues("true", "false")
+ .build();
+static final PropertyDescriptor SHARED_SUBSCRIBER = new
PropertyDescriptor.Builder()
+.name("Shared
subscription")
+
.description("If destination is Topic if present then make it the consumer
shared. " +
+
"@see
https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createSharedConsumer-javax.jms.Topic-java.lang.String-";)
+
.required(false)
+
.expressionLanguageSupported(true)
+
.defaultValue("false")
+
.allowableValues("true", "false")
+.build();
+static final PropertyDescriptor SUBSCRIPTION_NAME = new
PropertyDescriptor.Builder()
+
.name("Subscription Name")
+
.description("The name of the subscription to use if destination is Topic and
is shared or durable.")
+
.required(false)
+
.expressionLanguageSupported(true)
+.build();
--- End diff --
added, just pushed.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (NIFI-3983) Support ability to make JMS 2.0 durable subscriptions on Topic
[
https://issues.apache.org/jira/browse/NIFI-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065894#comment-16065894
]
ASF GitHub Bot commented on NIFI-3983:
--
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1863#discussion_r124448184
--- Diff:
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
---
@@ -86,6 +86,31 @@
.defaultValue(CLIENT_ACK.getValue())
.build();
+static final PropertyDescriptor DURABLE_SUBSCRIBER = new
PropertyDescriptor.Builder()
+
.name("Durable subscription")
+
.description("If destination is Topic if present then make it the consumer
durable. " +
+
"@see
https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createDurableConsumer-javax.jms.Topic-java.lang.String-";)
+
.required(false)
+
.expressionLanguageSupported(true)
+
.defaultValue("true")
--- End diff --
Fyi. Here is an example how you set it for an activemq artemis client (I'm
an active contributor there)
(tcp://remote-host1:5445?httpEnabled=true,remote-host2:5445?httpEnabled=true)?clientID=1234
> Support ability to make JMS 2.0 durable subscriptions on Topic
> --
>
> Key: NIFI-3983
> URL: https://issues.apache.org/jira/browse/NIFI-3983
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Michael Andre Pearce
>
> Currently the jms consumer, only supports standard queue consumption and
> topic subscription. For topics, in JMS 2.0 you can make shared durable
> subscribers which gives a subscription semantic similar to queue per
> subscription name, meaning message is delivered once per subscription. This
> is very useful in setups using JMS 2.0.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] nifi pull request #1863: NIFI-3983 - Support ability to make JMS 2.0 durable...
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1863#discussion_r124448184
--- Diff:
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
---
@@ -86,6 +86,31 @@
.defaultValue(CLIENT_ACK.getValue())
.build();
+static final PropertyDescriptor DURABLE_SUBSCRIBER = new
PropertyDescriptor.Builder()
+
.name("Durable subscription")
+
.description("If destination is Topic if present then make it the consumer
durable. " +
+
"@see
https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createDurableConsumer-javax.jms.Topic-java.lang.String-";)
+
.required(false)
+
.expressionLanguageSupported(true)
+
.defaultValue("true")
--- End diff --
Fyi. Here is an example how you set it for an activemq artemis client (I'm
an active contributor there)
(tcp://remote-host1:5445?httpEnabled=true,remote-host2:5445?httpEnabled=true)?clientID=1234
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (NIFI-3983) Support ability to make JMS 2.0 durable subscriptions on Topic
[
https://issues.apache.org/jira/browse/NIFI-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065890#comment-16065890
]
ASF GitHub Bot commented on NIFI-3983:
--
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1863#discussion_r124447987
--- Diff:
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
---
@@ -86,6 +86,31 @@
.defaultValue(CLIENT_ACK.getValue())
.build();
+static final PropertyDescriptor DURABLE_SUBSCRIBER = new
PropertyDescriptor.Builder()
+
.name("Durable subscription")
+
.description("If destination is Topic if present then make it the consumer
durable. " +
+
"@see
https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createDurableConsumer-javax.jms.Topic-java.lang.String-";)
+
.required(false)
+
.expressionLanguageSupported(true)
+
.defaultValue("true")
+
.allowableValues("true", "false")
+ .build();
+static final PropertyDescriptor SHARED_SUBSCRIBER = new
PropertyDescriptor.Builder()
+.name("Shared
subscription")
+
.description("If destination is Topic if present then make it the consumer
shared. " +
+
"@see
https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createSharedConsumer-javax.jms.Topic-java.lang.String-";)
+
.required(false)
+
.expressionLanguageSupported(true)
+
.defaultValue("false")
+
.allowableValues("true", "false")
+.build();
+static final PropertyDescriptor SUBSCRIPTION_NAME = new
PropertyDescriptor.Builder()
+
.name("Subscription Name")
+
.description("The name of the subscription to use if destination is Topic and
is shared or durable.")
+
.required(false)
+
.expressionLanguageSupported(true)
+.build();
--- End diff --
Sure will do didn't now about this in nifi
> Support ability to make JMS 2.0 durable subscriptions on Topic
> --
>
> Key: NIFI-3983
> URL: https://issues.apache.org/jira/browse/NIFI-3983
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Michael Andre Pearce
>
> Currently the jms consumer, only supports standard queue consumption and
> topic subscription. For topics, in JMS 2.0 you can make shared durable
> subscribers which gives a subscription semantic similar to queue per
> subscription name, meaning message is delivered once per subscription. This
> is very useful in setups using JMS 2.0.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (NIFI-3983) Support ability to make JMS 2.0 durable subscriptions on Topic
[
https://issues.apache.org/jira/browse/NIFI-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065891#comment-16065891
]
ASF GitHub Bot commented on NIFI-3983:
--
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1863#discussion_r124448019
--- Diff:
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
---
@@ -86,6 +86,31 @@
.defaultValue(CLIENT_ACK.getValue())
.build();
+static final PropertyDescriptor DURABLE_SUBSCRIBER = new
PropertyDescriptor.Builder()
+
.name("Durable subscription")
+
.description("If destination is Topic if present then make it the consumer
durable. " +
+
"@see
https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createDurableConsumer-javax.jms.Topic-java.lang.String-";)
+
.required(false)
+
.expressionLanguageSupported(true)
+
.defaultValue("true")
--- End diff --
Yes this is my bad
> Support ability to make JMS 2.0 durable subscriptions on Topic
> --
>
> Key: NIFI-3983
> URL: https://issues.apache.org/jira/browse/NIFI-3983
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Michael Andre Pearce
>
> Currently the jms consumer, only supports standard queue consumption and
> topic subscription. For topics, in JMS 2.0 you can make shared durable
> subscribers which gives a subscription semantic similar to queue per
> subscription name, meaning message is delivered once per subscription. This
> is very useful in setups using JMS 2.0.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] nifi pull request #1863: NIFI-3983 - Support ability to make JMS 2.0 durable...
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1863#discussion_r124448019
--- Diff:
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
---
@@ -86,6 +86,31 @@
.defaultValue(CLIENT_ACK.getValue())
.build();
+static final PropertyDescriptor DURABLE_SUBSCRIBER = new
PropertyDescriptor.Builder()
+
.name("Durable subscription")
+
.description("If destination is Topic if present then make it the consumer
durable. " +
+
"@see
https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createDurableConsumer-javax.jms.Topic-java.lang.String-";)
+
.required(false)
+
.expressionLanguageSupported(true)
+
.defaultValue("true")
--- End diff --
Yes this is my bad
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] nifi pull request #1863: NIFI-3983 - Support ability to make JMS 2.0 durable...
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1863#discussion_r124447987
--- Diff:
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
---
@@ -86,6 +86,31 @@
.defaultValue(CLIENT_ACK.getValue())
.build();
+static final PropertyDescriptor DURABLE_SUBSCRIBER = new
PropertyDescriptor.Builder()
+
.name("Durable subscription")
+
.description("If destination is Topic if present then make it the consumer
durable. " +
+
"@see
https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createDurableConsumer-javax.jms.Topic-java.lang.String-";)
+
.required(false)
+
.expressionLanguageSupported(true)
+
.defaultValue("true")
+
.allowableValues("true", "false")
+ .build();
+static final PropertyDescriptor SHARED_SUBSCRIBER = new
PropertyDescriptor.Builder()
+.name("Shared
subscription")
+
.description("If destination is Topic if present then make it the consumer
shared. " +
+
"@see
https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createSharedConsumer-javax.jms.Topic-java.lang.String-";)
+
.required(false)
+
.expressionLanguageSupported(true)
+
.defaultValue("false")
+
.allowableValues("true", "false")
+.build();
+static final PropertyDescriptor SUBSCRIPTION_NAME = new
PropertyDescriptor.Builder()
+
.name("Subscription Name")
+
.description("The name of the subscription to use if destination is Topic and
is shared or durable.")
+
.required(false)
+
.expressionLanguageSupported(true)
+.build();
--- End diff --
Sure will do didn't now about this in nifi
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (NIFI-3983) Support ability to make JMS 2.0 durable subscriptions on Topic
[
https://issues.apache.org/jira/browse/NIFI-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065888#comment-16065888
]
ASF GitHub Bot commented on NIFI-3983:
--
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1863#discussion_r124447960
--- Diff:
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
---
@@ -86,6 +86,31 @@
.defaultValue(CLIENT_ACK.getValue())
.build();
+static final PropertyDescriptor DURABLE_SUBSCRIBER = new
PropertyDescriptor.Builder()
+
.name("Durable subscription")
+
.description("If destination is Topic if present then make it the consumer
durable. " +
+
"@see
https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createDurableConsumer-javax.jms.Topic-java.lang.String-";)
+
.required(false)
+
.expressionLanguageSupported(true)
+
.defaultValue("true")
--- End diff --
Note only durable non shared, client Id is mandatory all others it is
optional (and typically undesirable)
> Support ability to make JMS 2.0 durable subscriptions on Topic
> --
>
> Key: NIFI-3983
> URL: https://issues.apache.org/jira/browse/NIFI-3983
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Michael Andre Pearce
>
> Currently the jms consumer, only supports standard queue consumption and
> topic subscription. For topics, in JMS 2.0 you can make shared durable
> subscribers which gives a subscription semantic similar to queue per
> subscription name, meaning message is delivered once per subscription. This
> is very useful in setups using JMS 2.0.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] nifi pull request #1863: NIFI-3983 - Support ability to make JMS 2.0 durable...
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1863#discussion_r124447960
--- Diff:
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
---
@@ -86,6 +86,31 @@
.defaultValue(CLIENT_ACK.getValue())
.build();
+static final PropertyDescriptor DURABLE_SUBSCRIBER = new
PropertyDescriptor.Builder()
+
.name("Durable subscription")
+
.description("If destination is Topic if present then make it the consumer
durable. " +
+
"@see
https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createDurableConsumer-javax.jms.Topic-java.lang.String-";)
+
.required(false)
+
.expressionLanguageSupported(true)
+
.defaultValue("true")
--- End diff --
Note only durable non shared, client Id is mandatory all others it is
optional (and typically undesirable)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (NIFI-3983) Support ability to make JMS 2.0 durable subscriptions on Topic
[
https://issues.apache.org/jira/browse/NIFI-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065887#comment-16065887
]
ASF GitHub Bot commented on NIFI-3983:
--
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1863#discussion_r124447851
--- Diff:
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
---
@@ -86,6 +86,31 @@
.defaultValue(CLIENT_ACK.getValue())
.build();
+static final PropertyDescriptor DURABLE_SUBSCRIBER = new
PropertyDescriptor.Builder()
+
.name("Durable subscription")
+
.description("If destination is Topic if present then make it the consumer
durable. " +
+
"@see
https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createDurableConsumer-javax.jms.Topic-java.lang.String-";)
+
.required(false)
+
.expressionLanguageSupported(true)
+
.defaultValue("true")
--- End diff --
If you use shared subscriber typically you would not set client Id. If a
client Id is present then it would end up making different subscription names
for each clientId. Like wise a clientId must be unique per connection. As such
typically this would not be the behaviour one would want.
For a durable not shared client Id though is manadatory.
The clientId is set on connection and must be the first thing set after
creation of a connection by spec. This is not accessible though in jms
template. As such you're reliant on it being set by the providers connection
factory. Typically setable via jndi properties for the vendors connection
factory or via the connection URL strings.
Please see jms spec.
> Support ability to make JMS 2.0 durable subscriptions on Topic
> --
>
> Key: NIFI-3983
> URL: https://issues.apache.org/jira/browse/NIFI-3983
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Michael Andre Pearce
>
> Currently the jms consumer, only supports standard queue consumption and
> topic subscription. For topics, in JMS 2.0 you can make shared durable
> subscribers which gives a subscription semantic similar to queue per
> subscription name, meaning message is delivered once per subscription. This
> is very useful in setups using JMS 2.0.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] nifi pull request #1863: NIFI-3983 - Support ability to make JMS 2.0 durable...
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1863#discussion_r124447851
--- Diff:
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
---
@@ -86,6 +86,31 @@
.defaultValue(CLIENT_ACK.getValue())
.build();
+static final PropertyDescriptor DURABLE_SUBSCRIBER = new
PropertyDescriptor.Builder()
+
.name("Durable subscription")
+
.description("If destination is Topic if present then make it the consumer
durable. " +
+
"@see
https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createDurableConsumer-javax.jms.Topic-java.lang.String-";)
+
.required(false)
+
.expressionLanguageSupported(true)
+
.defaultValue("true")
--- End diff --
If you use shared subscriber typically you would not set client Id. If a
client Id is present then it would end up making different subscription names
for each clientId. Like wise a clientId must be unique per connection. As such
typically this would not be the behaviour one would want.
For a durable not shared client Id though is manadatory.
The clientId is set on connection and must be the first thing set after
creation of a connection by spec. This is not accessible though in jms
template. As such you're reliant on it being set by the providers connection
factory. Typically setable via jndi properties for the vendors connection
factory or via the connection URL strings.
Please see jms spec.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (NIFI-3983) Support ability to make JMS 2.0 durable subscriptions on Topic
[
https://issues.apache.org/jira/browse/NIFI-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065842#comment-16065842
]
ASF GitHub Bot commented on NIFI-3983:
--
Github user ijokarumawak commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1863#discussion_r124441093
--- Diff:
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
---
@@ -86,6 +86,31 @@
.defaultValue(CLIENT_ACK.getValue())
.build();
+static final PropertyDescriptor DURABLE_SUBSCRIBER = new
PropertyDescriptor.Builder()
+
.name("Durable subscription")
+
.description("If destination is Topic if present then make it the consumer
durable. " +
+
"@see
https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createDurableConsumer-javax.jms.Topic-java.lang.String-";)
+
.required(false)
+
.expressionLanguageSupported(true)
+
.defaultValue("true")
--- End diff --
I'm testing these new properties with Active MQ. With durable subscription
enabled, I got following error:
```
Caused by: javax.jms.JMSException: You cannot create a durable subscriber
without specifying a unique clientID on a Connection
at
org.apache.activemq.ActiveMQConnection.checkClientIDWasManuallySpecified(ActiveMQConnection.java:1288)
at
org.apache.activemq.ActiveMQSession.createDurableSubscriber(ActiveMQSession.java:1467)
at
org.springframework.jms.connection.CachingConnectionFactory$CachedSessionInvocationHandler.getCachedConsumer(CachingConnectionFactory.java:442)
at
org.springframework.jms.connection.CachingConnectionFactory$CachedSessionInvocationHandler.invoke(CachingConnectionFactory.java:356)
at com.sun.proxy.$Proxy84.createDurableConsumer(Unknown Source)
at
org.apache.nifi.jms.processors.JMSConsumer$1.doInJms(JMSConsumer.java:87)
at
org.apache.nifi.jms.processors.JMSConsumer$1.doInJms(JMSConsumer.java:65)
at
org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:494)
... 16 common frames omitted
```
I think we need to set unique client id at each processor. Probably at
AbstractJMSProcessor.java
https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/AbstractJMSProcessor.java#L198
```
// Need to add something like this:
this.cachingConnectionFactory.setClientId("some-unique-id");
```
I'm wondering if client id can be the same value with subscription name...
I will research on this a bit more, but do you have any idea?
> Support ability to make JMS 2.0 durable subscriptions on Topic
> --
>
> Key: NIFI-3983
> URL: https://issues.apache.org/jira/browse/NIFI-3983
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Michael Andre Pearce
>
> Currently the jms consumer, only supports standard queue consumption and
> topic subscription. For topics, in JMS 2.0 you can make shared durable
> subscribers which gives a subscription semantic similar to queue per
> subscription name, meaning message is delivered once per subscription. This
> is very useful in setups using JMS 2.0.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (NIFI-3983) Support ability to make JMS 2.0 durable subscriptions on Topic
[
https://issues.apache.org/jira/browse/NIFI-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065844#comment-16065844
]
ASF GitHub Bot commented on NIFI-3983:
--
Github user ijokarumawak commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1863#discussion_r124437824
--- Diff:
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
---
@@ -86,6 +86,31 @@
.defaultValue(CLIENT_ACK.getValue())
.build();
+static final PropertyDescriptor DURABLE_SUBSCRIBER = new
PropertyDescriptor.Builder()
+
.name("Durable subscription")
+
.description("If destination is Topic if present then make it the consumer
durable. " +
+
"@see
https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createDurableConsumer-javax.jms.Topic-java.lang.String-";)
+
.required(false)
+
.expressionLanguageSupported(true)
+
.defaultValue("true")
--- End diff --
I think we should make default value as `false` to keep current behavior.
> Support ability to make JMS 2.0 durable subscriptions on Topic
> --
>
> Key: NIFI-3983
> URL: https://issues.apache.org/jira/browse/NIFI-3983
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Michael Andre Pearce
>
> Currently the jms consumer, only supports standard queue consumption and
> topic subscription. For topics, in JMS 2.0 you can make shared durable
> subscribers which gives a subscription semantic similar to queue per
> subscription name, meaning message is delivered once per subscription. This
> is very useful in setups using JMS 2.0.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (NIFI-3983) Support ability to make JMS 2.0 durable subscriptions on Topic
[
https://issues.apache.org/jira/browse/NIFI-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065843#comment-16065843
]
ASF GitHub Bot commented on NIFI-3983:
--
Github user ijokarumawak commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1863#discussion_r124438011
--- Diff:
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
---
@@ -86,6 +86,31 @@
.defaultValue(CLIENT_ACK.getValue())
.build();
+static final PropertyDescriptor DURABLE_SUBSCRIBER = new
PropertyDescriptor.Builder()
+
.name("Durable subscription")
+
.description("If destination is Topic if present then make it the consumer
durable. " +
+
"@see
https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createDurableConsumer-javax.jms.Topic-java.lang.String-";)
+
.required(false)
+
.expressionLanguageSupported(true)
+
.defaultValue("true")
+
.allowableValues("true", "false")
+ .build();
+static final PropertyDescriptor SHARED_SUBSCRIBER = new
PropertyDescriptor.Builder()
+.name("Shared
subscription")
+
.description("If destination is Topic if present then make it the consumer
shared. " +
+
"@see
https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createSharedConsumer-javax.jms.Topic-java.lang.String-";)
+
.required(false)
+
.expressionLanguageSupported(true)
+
.defaultValue("false")
+
.allowableValues("true", "false")
+.build();
+static final PropertyDescriptor SUBSCRIPTION_NAME = new
PropertyDescriptor.Builder()
+
.name("Subscription Name")
+
.description("The name of the subscription to use if destination is Topic and
is shared or durable.")
+
.required(false)
+
.expressionLanguageSupported(true)
+.build();
--- End diff --
If a property descriptor doesn't have any validator, it just becomes
invalid. Please add NON_EMPTY_VALIDATOR.
```
.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
```
I added above code temporarily to proceed testing.
> Support ability to make JMS 2.0 durable subscriptions on Topic
> --
>
> Key: NIFI-3983
> URL: https://issues.apache.org/jira/browse/NIFI-3983
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Michael Andre Pearce
>
> Currently the jms consumer, only supports standard queue consumption and
> topic subscription. For topics, in JMS 2.0 you can make shared durable
> subscribers which gives a subscription semantic similar to queue per
> subscription name, meaning message is delivered once per subscription. This
> is very useful in setups using JMS 2.0.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] nifi pull request #1863: NIFI-3983 - Support ability to make JMS 2.0 durable...
Github user ijokarumawak commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1863#discussion_r124437824
--- Diff:
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
---
@@ -86,6 +86,31 @@
.defaultValue(CLIENT_ACK.getValue())
.build();
+static final PropertyDescriptor DURABLE_SUBSCRIBER = new
PropertyDescriptor.Builder()
+
.name("Durable subscription")
+
.description("If destination is Topic if present then make it the consumer
durable. " +
+
"@see
https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createDurableConsumer-javax.jms.Topic-java.lang.String-";)
+
.required(false)
+
.expressionLanguageSupported(true)
+
.defaultValue("true")
--- End diff --
I think we should make default value as `false` to keep current behavior.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] nifi pull request #1863: NIFI-3983 - Support ability to make JMS 2.0 durable...
Github user ijokarumawak commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1863#discussion_r124441093
--- Diff:
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
---
@@ -86,6 +86,31 @@
.defaultValue(CLIENT_ACK.getValue())
.build();
+static final PropertyDescriptor DURABLE_SUBSCRIBER = new
PropertyDescriptor.Builder()
+
.name("Durable subscription")
+
.description("If destination is Topic if present then make it the consumer
durable. " +
+
"@see
https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createDurableConsumer-javax.jms.Topic-java.lang.String-";)
+
.required(false)
+
.expressionLanguageSupported(true)
+
.defaultValue("true")
--- End diff --
I'm testing these new properties with Active MQ. With durable subscription
enabled, I got following error:
```
Caused by: javax.jms.JMSException: You cannot create a durable subscriber
without specifying a unique clientID on a Connection
at
org.apache.activemq.ActiveMQConnection.checkClientIDWasManuallySpecified(ActiveMQConnection.java:1288)
at
org.apache.activemq.ActiveMQSession.createDurableSubscriber(ActiveMQSession.java:1467)
at
org.springframework.jms.connection.CachingConnectionFactory$CachedSessionInvocationHandler.getCachedConsumer(CachingConnectionFactory.java:442)
at
org.springframework.jms.connection.CachingConnectionFactory$CachedSessionInvocationHandler.invoke(CachingConnectionFactory.java:356)
at com.sun.proxy.$Proxy84.createDurableConsumer(Unknown Source)
at
org.apache.nifi.jms.processors.JMSConsumer$1.doInJms(JMSConsumer.java:87)
at
org.apache.nifi.jms.processors.JMSConsumer$1.doInJms(JMSConsumer.java:65)
at
org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:494)
... 16 common frames omitted
```
I think we need to set unique client id at each processor. Probably at
AbstractJMSProcessor.java
https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/AbstractJMSProcessor.java#L198
```
// Need to add something like this:
this.cachingConnectionFactory.setClientId("some-unique-id");
```
I'm wondering if client id can be the same value with subscription name...
I will research on this a bit more, but do you have any idea?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] nifi pull request #1863: NIFI-3983 - Support ability to make JMS 2.0 durable...
Github user ijokarumawak commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1863#discussion_r124438011
--- Diff:
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
---
@@ -86,6 +86,31 @@
.defaultValue(CLIENT_ACK.getValue())
.build();
+static final PropertyDescriptor DURABLE_SUBSCRIBER = new
PropertyDescriptor.Builder()
+
.name("Durable subscription")
+
.description("If destination is Topic if present then make it the consumer
durable. " +
+
"@see
https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createDurableConsumer-javax.jms.Topic-java.lang.String-";)
+
.required(false)
+
.expressionLanguageSupported(true)
+
.defaultValue("true")
+
.allowableValues("true", "false")
+ .build();
+static final PropertyDescriptor SHARED_SUBSCRIBER = new
PropertyDescriptor.Builder()
+.name("Shared
subscription")
+
.description("If destination is Topic if present then make it the consumer
shared. " +
+
"@see
https://docs.oracle.com/javaee/7/api/javax/jms/Session.html#createSharedConsumer-javax.jms.Topic-java.lang.String-";)
+
.required(false)
+
.expressionLanguageSupported(true)
+
.defaultValue("false")
+
.allowableValues("true", "false")
+.build();
+static final PropertyDescriptor SUBSCRIPTION_NAME = new
PropertyDescriptor.Builder()
+
.name("Subscription Name")
+
.description("The name of the subscription to use if destination is Topic and
is shared or durable.")
+
.required(false)
+
.expressionLanguageSupported(true)
+.build();
--- End diff --
If a property descriptor doesn't have any validator, it just becomes
invalid. Please add NON_EMPTY_VALIDATOR.
```
.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
```
I added above code temporarily to proceed testing.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (NIFI-4105) support the specified Maximum value column and CSV Stream for Cassandra
[ https://issues.apache.org/jira/browse/NIFI-4105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065814#comment-16065814 ] ASF GitHub Bot commented on NIFI-4105: -- Github user ggthename commented on the issue: https://github.com/apache/nifi/pull/1937 @pvillard31 I have one question. There were some problems on my side(maven 3.5.0) What is the meaning of failure? How can I solve this situation. Thanks! `[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2. 18:test (default-test) on project nifi-write-ahead-log: There are test failures. [ERROR] [ERROR] Please refer to D:\github\nifi\nifi-commons\nifi-write-ahead-log\target\ surefire-reports for the individual test results. [ERROR] -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal o rg.apache.maven.plugins:maven-surefire-plugin:2.18:test (default-test) on projec t nifi-write-ahead-log: There are test failures. Please refer to D:\github\nifi\nifi-commons\nifi-write-ahead-log\target\surefire -reports for the individual test results. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:213) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:154) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:146) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje ct(LifecycleModuleBuilder.java:117) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje ct(LifecycleModuleBuilder.java:81) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThre adedBuilder.build(SingleThreadedBuilder.java:51) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(Lifecycl eStarter.java:128) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345) at org.apache.maven.cli.MavenCli.main(MavenCli.java:191) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Laun cher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.jav a:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(La uncher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java: 356) Caused by: org.apache.maven.plugin.MojoFailureException: There are test failures . ` and It is the TestMinimalLockingWriteAheadLog.txt ` --- Test set: org.wali.TestMinimalLockingWriteAheadLog --- Tests run: 12, Failures: 0, Errors: 1, Skipped: 2, Time elapsed: 7.641 sec <<< FAILURE! - in org.wali.TestMinimalLockingWriteAheadLog testRecoverFileThatHasTrailingNULBytesAndTruncation(org.wali.TestMinimalLockingWriteAheadLog) Time elapsed: 0.03 sec <<< ERROR! java.nio.channels.OverlappingFileLockException: null at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255) at sun.nio.ch.SharedFileLockTable.add(FileLockTable.java:152) at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:1063) at java.nio.channels.FileChannel.lock(FileChannel.java:1053) at org.wali.MinimalLockingWriteAheadLog.(MinimalLockingWriteAheadLog.java:187) at org.wali.MinimalLockingWriteAheadLog.(MinimalLockingWriteAheadLog.java:108) at org.wali.TestMinimalLockingWriteAheadLog.testRecoverFileThatHasTrailingNULBytesAndTruncation(TestMinimalLockingWriteAheadLog.java:472) ` > support the specified Maximum value column and CSV Stream for Cassandra > --- > > Key: NIFI-4105 > URL: https://issues.apache.org/jira/browse/NIFI-4105 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.3.0 >Reporter: Yoonwon Ko > > I'm trying
[GitHub] nifi issue #1937: NIFI-4105 support the specified Maximum value column and C...
Github user ggthename commented on the issue: https://github.com/apache/nifi/pull/1937 @pvillard31 I have one question. There were some problems on my side(maven 3.5.0) What is the meaning of failure? How can I solve this situation. Thanks! `[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2. 18:test (default-test) on project nifi-write-ahead-log: There are test failures. [ERROR] [ERROR] Please refer to D:\github\nifi\nifi-commons\nifi-write-ahead-log\target\ surefire-reports for the individual test results. [ERROR] -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal o rg.apache.maven.plugins:maven-surefire-plugin:2.18:test (default-test) on projec t nifi-write-ahead-log: There are test failures. Please refer to D:\github\nifi\nifi-commons\nifi-write-ahead-log\target\surefire -reports for the individual test results. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:213) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:154) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:146) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje ct(LifecycleModuleBuilder.java:117) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje ct(LifecycleModuleBuilder.java:81) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThre adedBuilder.build(SingleThreadedBuilder.java:51) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(Lifecycl eStarter.java:128) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345) at org.apache.maven.cli.MavenCli.main(MavenCli.java:191) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Laun cher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.jav a:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(La uncher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java: 356) Caused by: org.apache.maven.plugin.MojoFailureException: There are test failures . ` and It is the TestMinimalLockingWriteAheadLog.txt ` --- Test set: org.wali.TestMinimalLockingWriteAheadLog --- Tests run: 12, Failures: 0, Errors: 1, Skipped: 2, Time elapsed: 7.641 sec <<< FAILURE! - in org.wali.TestMinimalLockingWriteAheadLog testRecoverFileThatHasTrailingNULBytesAndTruncation(org.wali.TestMinimalLockingWriteAheadLog) Time elapsed: 0.03 sec <<< ERROR! java.nio.channels.OverlappingFileLockException: null at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255) at sun.nio.ch.SharedFileLockTable.add(FileLockTable.java:152) at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:1063) at java.nio.channels.FileChannel.lock(FileChannel.java:1053) at org.wali.MinimalLockingWriteAheadLog.(MinimalLockingWriteAheadLog.java:187) at org.wali.MinimalLockingWriteAheadLog.(MinimalLockingWriteAheadLog.java:108) at org.wali.TestMinimalLockingWriteAheadLog.testRecoverFileThatHasTrailingNULBytesAndTruncation(TestMinimalLockingWriteAheadLog.java:472) ` --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi pull request #1946: NIFI-4125 - Add basic security settings to Transfor...
Github user alopresto commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1946#discussion_r124429931
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/TransformXml.java
---
@@ -98,6 +99,16 @@
.addValidator(StandardValidators.BOOLEAN_VALIDATOR)
.build();
+public static final PropertyDescriptor SECURE_PROCESSING = new
PropertyDescriptor.Builder()
+.name("secure-processing")
+.displayName("Secure processing")
+.description("Whether or not to mitigate various XML-related
attacks like XXE (XML External Entity) attacks.")
+.required(true)
+.defaultValue("false")
--- End diff --
No worries, I found those comments in the email thread but for some reason
they did not show for me in the GitHub UI. I understand the desire for backward
compatibility but this is a security fix, so as long as it is well-documented
in the processor and the release notes/migration notes for the release that
contains this, I think `true` is a safe choice.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (NIFI-4125) Add basic security settings to TransformXml
[
https://issues.apache.org/jira/browse/NIFI-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065731#comment-16065731
]
ASF GitHub Bot commented on NIFI-4125:
--
Github user alopresto commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1946#discussion_r124429931
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/TransformXml.java
---
@@ -98,6 +99,16 @@
.addValidator(StandardValidators.BOOLEAN_VALIDATOR)
.build();
+public static final PropertyDescriptor SECURE_PROCESSING = new
PropertyDescriptor.Builder()
+.name("secure-processing")
+.displayName("Secure processing")
+.description("Whether or not to mitigate various XML-related
attacks like XXE (XML External Entity) attacks.")
+.required(true)
+.defaultValue("false")
--- End diff --
No worries, I found those comments in the email thread but for some reason
they did not show for me in the GitHub UI. I understand the desire for backward
compatibility but this is a security fix, so as long as it is well-documented
in the processor and the release notes/migration notes for the release that
contains this, I think `true` is a safe choice.
> Add basic security settings to TransformXml
> ---
>
> Key: NIFI-4125
> URL: https://issues.apache.org/jira/browse/NIFI-4125
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
>Affects Versions: 1.3.0
>Reporter: Yuri
>Priority: Minor
> Labels: newbie, security, xslt
>
> Since data flows can generally deal with non-trusted data, the processors
> should handle it in a secure manner.
> In case of XML there are various known vulnerabilities -
> [OWASP|https://www.owasp.org/index.php/XML_External_Entity_%28XXE%29_Processing].
> Some can be mitigated via XML parser/XSLT Processor features.
> The TransformXml processor should have a setting enabling these secure
> settings.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (NIFI-4125) Add basic security settings to TransformXml
[
https://issues.apache.org/jira/browse/NIFI-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065720#comment-16065720
]
ASF GitHub Bot commented on NIFI-4125:
--
Github user mattyb149 commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1946#discussion_r124428785
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/TransformXml.java
---
@@ -98,6 +99,16 @@
.addValidator(StandardValidators.BOOLEAN_VALIDATOR)
.build();
+public static final PropertyDescriptor SECURE_PROCESSING = new
PropertyDescriptor.Builder()
+.name("secure-processing")
+.displayName("Secure processing")
+.description("Whether or not to mitigate various XML-related
attacks like XXE (XML External Entity) attacks.")
+.required(true)
+.defaultValue("false")
--- End diff --
That's my bad, I suggested he change it to keep the default pre-existing
behavior. If true is better, I'm fine with that
> Add basic security settings to TransformXml
> ---
>
> Key: NIFI-4125
> URL: https://issues.apache.org/jira/browse/NIFI-4125
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
>Affects Versions: 1.3.0
>Reporter: Yuri
>Priority: Minor
> Labels: newbie, security, xslt
>
> Since data flows can generally deal with non-trusted data, the processors
> should handle it in a secure manner.
> In case of XML there are various known vulnerabilities -
> [OWASP|https://www.owasp.org/index.php/XML_External_Entity_%28XXE%29_Processing].
> Some can be mitigated via XML parser/XSLT Processor features.
> The TransformXml processor should have a setting enabling these secure
> settings.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] nifi pull request #1946: NIFI-4125 - Add basic security settings to Transfor...
Github user mattyb149 commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1946#discussion_r124428785
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/TransformXml.java
---
@@ -98,6 +99,16 @@
.addValidator(StandardValidators.BOOLEAN_VALIDATOR)
.build();
+public static final PropertyDescriptor SECURE_PROCESSING = new
PropertyDescriptor.Builder()
+.name("secure-processing")
+.displayName("Secure processing")
+.description("Whether or not to mitigate various XML-related
attacks like XXE (XML External Entity) attacks.")
+.required(true)
+.defaultValue("false")
--- End diff --
That's my bad, I suggested he change it to keep the default pre-existing
behavior. If true is better, I'm fine with that
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (NIFI-4125) Add basic security settings to TransformXml
[
https://issues.apache.org/jira/browse/NIFI-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065672#comment-16065672
]
ASF GitHub Bot commented on NIFI-4125:
--
Github user alopresto commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1946#discussion_r124423881
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/TransformXml.java
---
@@ -98,6 +99,16 @@
.addValidator(StandardValidators.BOOLEAN_VALIDATOR)
.build();
+public static final PropertyDescriptor SECURE_PROCESSING = new
PropertyDescriptor.Builder()
+.name("secure-processing")
+.displayName("Secure processing")
+.description("Whether or not to mitigate various XML-related
attacks like XXE (XML External Entity) attacks.")
+.required(true)
+.defaultValue("false")
--- End diff --
Is there a reason you decided to default this to `false`? Do the secure
processing features add substantial time or drastically reduce the feature set
of the processor?
> Add basic security settings to TransformXml
> ---
>
> Key: NIFI-4125
> URL: https://issues.apache.org/jira/browse/NIFI-4125
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
>Affects Versions: 1.3.0
>Reporter: Yuri
>Priority: Minor
> Labels: newbie, security, xslt
>
> Since data flows can generally deal with non-trusted data, the processors
> should handle it in a secure manner.
> In case of XML there are various known vulnerabilities -
> [OWASP|https://www.owasp.org/index.php/XML_External_Entity_%28XXE%29_Processing].
> Some can be mitigated via XML parser/XSLT Processor features.
> The TransformXml processor should have a setting enabling these secure
> settings.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] nifi pull request #1946: NIFI-4125 - Add basic security settings to Transfor...
Github user alopresto commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1946#discussion_r124423881
--- Diff:
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/TransformXml.java
---
@@ -98,6 +99,16 @@
.addValidator(StandardValidators.BOOLEAN_VALIDATOR)
.build();
+public static final PropertyDescriptor SECURE_PROCESSING = new
PropertyDescriptor.Builder()
+.name("secure-processing")
+.displayName("Secure processing")
+.description("Whether or not to mitigate various XML-related
attacks like XXE (XML External Entity) attacks.")
+.required(true)
+.defaultValue("false")
--- End diff --
Is there a reason you decided to default this to `false`? Do the secure
processing features add substantial time or drastically reduce the feature set
of the processor?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (NIFI-4105) support the specified Maximum value column and CSV Stream for Cassandra
[ https://issues.apache.org/jira/browse/NIFI-4105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065655#comment-16065655 ] ASF GitHub Bot commented on NIFI-4105: -- Github user ggthename commented on the issue: https://github.com/apache/nifi/pull/1937 @pvillard31 Really? I'm sorry. I'll check again. Thank you. > support the specified Maximum value column and CSV Stream for Cassandra > --- > > Key: NIFI-4105 > URL: https://issues.apache.org/jira/browse/NIFI-4105 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.3.0 >Reporter: Yoonwon Ko > > I'm trying to find a CassandraProcessor to fetch rows whose values in the > specified Maximum Value columns are larger than the previously-seen maximum > like QueryDatabaseTable. > But I found only QueryCassandra. It just executes same CQL everytime without > keeping maximum value. > and I think we also need convertToCsvStream option. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #1937: NIFI-4105 support the specified Maximum value column and C...
Github user ggthename commented on the issue: https://github.com/apache/nifi/pull/1937 @pvillard31 Really? I'm sorry. I'll check again. Thank you. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Updated] (NIFI-4134) Introduce checks to prevent Admin from removing their own permissions
[ https://issues.apache.org/jira/browse/NIFI-4134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy LoPresto updated NIFI-4134: Summary: Introduce checks to prevent Admin from removing their own permissions (was: Introduce checks to prevent Admin from removing there own permissions) > Introduce checks to prevent Admin from removing their own permissions > - > > Key: NIFI-4134 > URL: https://issues.apache.org/jira/browse/NIFI-4134 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework, Core UI >Reporter: Matt Gilman >Priority: Minor > > Install checks and update UI to prevent an administrator from removing their > own permissions to the admin policies (access all policies -> Read/Write). If > they are the only admin and this action is performed, it would require the > user to delete the existing authorizations or hand edit the authorizations to > restore access. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi pull request #1955: NIFI-4136 Add a failure option to unmatch behavior ...
GitHub user pvillard31 opened a pull request: https://github.com/apache/nifi/pull/1955 NIFI-4136 Add a failure option to unmatch behavior options in GrokReader Thank you for submitting a contribution to Apache NiFi. 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 master)? - [X] Is your initial contribution a single, squashed commit? ### 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? ### 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. You can merge this pull request into a Git repository by running: $ git pull https://github.com/pvillard31/nifi NIFI-4136 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/1955.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1955 commit 33ec5335a8c6c3ae9d8bcf7421219df00ef16932 Author: Pierre Villard Date: 2017-06-27T20:41:41Z NIFI-4136 Add a failure option to unmatch behavior options in GrokReader --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-4136) GrokReader - Add a failure option to unmatch behavior options
[ https://issues.apache.org/jira/browse/NIFI-4136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065440#comment-16065440 ] ASF GitHub Bot commented on NIFI-4136: -- GitHub user pvillard31 opened a pull request: https://github.com/apache/nifi/pull/1955 NIFI-4136 Add a failure option to unmatch behavior options in GrokReader Thank you for submitting a contribution to Apache NiFi. 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 master)? - [X] Is your initial contribution a single, squashed commit? ### 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? ### 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. You can merge this pull request into a Git repository by running: $ git pull https://github.com/pvillard31/nifi NIFI-4136 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/1955.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1955 commit 33ec5335a8c6c3ae9d8bcf7421219df00ef16932 Author: Pierre Villard Date: 2017-06-27T20:41:41Z NIFI-4136 Add a failure option to unmatch behavior options in GrokReader > GrokReader - Add a failure option to unmatch behavior options > - > > Key: NIFI-4136 > URL: https://issues.apache.org/jira/browse/NIFI-4136 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Pierre Villard >Assignee: Pierre Villard > > At the moment, when using the GrokReader, if a line does not match the grok > expression (and is not part of a stack trace), the line can be either ignored > (the line will be completely skipped) or appended to the last field from the > previous line. > In the case where appending is not desired and that data should not be > ignored/deleted, we should add the option to route the full flow file to the > failure relationship. This way the flow file could be treated in a different > way (for example with SplitText and ExtractGrok to isolate the incorrect > lines and re-route the correct lines back to the Record processors). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (NIFI-4136) GrokReader - Add a failure option to unmatch behavior options
[ https://issues.apache.org/jira/browse/NIFI-4136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-4136: - Status: Patch Available (was: Open) > GrokReader - Add a failure option to unmatch behavior options > - > > Key: NIFI-4136 > URL: https://issues.apache.org/jira/browse/NIFI-4136 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Pierre Villard >Assignee: Pierre Villard > > At the moment, when using the GrokReader, if a line does not match the grok > expression (and is not part of a stack trace), the line can be either ignored > (the line will be completely skipped) or appended to the last field from the > previous line. > In the case where appending is not desired and that data should not be > ignored/deleted, we should add the option to route the full flow file to the > failure relationship. This way the flow file could be treated in a different > way (for example with SplitText and ExtractGrok to isolate the incorrect > lines and re-route the correct lines back to the Record processors). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (NIFI-4136) GrokReader - Add a failure option to unmatch behavior options
Pierre Villard created NIFI-4136: Summary: GrokReader - Add a failure option to unmatch behavior options Key: NIFI-4136 URL: https://issues.apache.org/jira/browse/NIFI-4136 Project: Apache NiFi Issue Type: Improvement Components: Extensions Reporter: Pierre Villard Assignee: Pierre Villard At the moment, when using the GrokReader, if a line does not match the grok expression (and is not part of a stack trace), the line can be either ignored (the line will be completely skipped) or appended to the last field from the previous line. In the case where appending is not desired and that data should not be ignored/deleted, we should add the option to route the full flow file to the failure relationship. This way the flow file could be treated in a different way (for example with SplitText and ExtractGrok to isolate the incorrect lines and re-route the correct lines back to the Record processors). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-3193) Update ConsumeAMQP and PublishAMQP to retrieve username from certificate common name
[ https://issues.apache.org/jira/browse/NIFI-3193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065415#comment-16065415 ] Michael Hogue commented on NIFI-3193: - Work here: https://github.com/m-hogue/nifi/tree/NIFI-3193 > Update ConsumeAMQP and PublishAMQP to retrieve username from certificate > common name > > > Key: NIFI-3193 > URL: https://issues.apache.org/jira/browse/NIFI-3193 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Affects Versions: 1.0.0, 1.1.0, 0.7.1 >Reporter: Brian >Assignee: Michael Hogue > > At the moment the NiFi AMQP processors can establish a SSL connection to > RabbitMQ but still user a user defined username and password to authenticate. > When using certificates RabbitMQ allows you to use to COMMON_NAME from the > certificate to authenticate instead of providing a username and password. > Unfortunately the NiFi processors do not support this so I would like to > request an update to the processors to enable this functionality. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4074) ListHDFS recursive search with regex
[ https://issues.apache.org/jira/browse/NIFI-4074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065407#comment-16065407 ] ASF GitHub Bot commented on NIFI-4074: -- Github user champagst closed the pull request at: https://github.com/apache/nifi/pull/1917 > ListHDFS recursive search with regex > > > Key: NIFI-4074 > URL: https://issues.apache.org/jira/browse/NIFI-4074 > Project: Apache NiFi > Issue Type: Bug >Reporter: Steve Champagne > > ListHDFS isn't picking up nested files correctly when you use a regex. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4074) ListHDFS recursive search with regex
[ https://issues.apache.org/jira/browse/NIFI-4074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065406#comment-16065406 ] ASF GitHub Bot commented on NIFI-4074: -- Github user champagst commented on the issue: https://github.com/apache/nifi/pull/1917 I figured out how this is intended to work. Sorry for the misunderstanding. > ListHDFS recursive search with regex > > > Key: NIFI-4074 > URL: https://issues.apache.org/jira/browse/NIFI-4074 > Project: Apache NiFi > Issue Type: Bug >Reporter: Steve Champagne > > ListHDFS isn't picking up nested files correctly when you use a regex. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #1917: NIFI-4074: Fix recursive regex search
Github user champagst commented on the issue: https://github.com/apache/nifi/pull/1917 I figured out how this is intended to work. Sorry for the misunderstanding. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi pull request #1917: NIFI-4074: Fix recursive regex search
Github user champagst closed the pull request at: https://github.com/apache/nifi/pull/1917 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Comment Edited] (NIFI-3193) Update ConsumeAMQP and PublishAMQP to retrieve username from certificate common name
[ https://issues.apache.org/jira/browse/NIFI-3193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065392#comment-16065392 ] Michael Hogue edited comment on NIFI-3193 at 6/27/17 8:04 PM: -- [~bdeep] : A couple of things. In thinking about your feature request to go ahead and declare a queue if it doesn't exist, that's only possible for NiFi to do if you're not using exchanges (i.e. you're just using the default exchange). The reason is that RabbitMQ maintains a mapping of which the exchanges leverage to route messages to the appropriate queue. In that case, NiFi would have no knowledge of which queue the message would be routed to. Per one of the RabbitMQ docs [1], in the case that the exchange provided is empty, then the routing key is assumed to be the queue name. In that case, we could declare it if it doesn't exist. The issue is that there are a number of arguments in queue declaration that i feel would need to be explicit (See Queues in [1]). Perhaps it'd be better if the queue declaration were left to RabbitMQ admins? Or maybe just have sensible defaults? Thoughts? > For example, when you declare a queue with the name of > "search-indexing-online", the AMQP 0-9-1 broker will bind it to the default > exchange using "search-indexing-online" as the routing key. Therefore, a > message published to the default exchange with the routing key > "search-indexing-online" will be routed to the queue > "search-indexing-online". In other words, the default exchange makes it seem > like it is possible to deliver messages directly to queues, even though that > is not technically what is happening. [1] https://www.rabbitmq.com/tutorials/amqp-concepts.html -- See 'Default Exchange', 'Queues' was (Author: m-hogue): [~bdeep] : A couple of things. In thinking about your feature request to go ahead and declare a queue if it doesn't exist, that's only possible for NiFi to do if you're not using exchanges (i.e. you're just using the default exchange). The reason is that RabbitMQ maintains a mapping of which the exchanges leverage to route messages to the appropriate queue. In that case, NiFi would have no knowledge of which queue the message would be routed to. Per one of the RabbitMQ docs [1], in the case that the exchange provided is empty, then the routing key is assumed to be the queue name. In that case, we could declare it if it doesn't exist. The issue is that there are a number of arguments in queue declaration that i feel would need to be explicit (See Queues in [1]). Perhaps it'd be better if the queue declaration were left to RabbitMQ admins? Thoughts? > For example, when you declare a queue with the name of > "search-indexing-online", the AMQP 0-9-1 broker will bind it to the default > exchange using "search-indexing-online" as the routing key. Therefore, a > message published to the default exchange with the routing key > "search-indexing-online" will be routed to the queue > "search-indexing-online". In other words, the default exchange makes it seem > like it is possible to deliver messages directly to queues, even though that > is not technically what is happening. [1] https://www.rabbitmq.com/tutorials/amqp-concepts.html -- See 'Default Exchange', 'Queues' > Update ConsumeAMQP and PublishAMQP to retrieve username from certificate > common name > > > Key: NIFI-3193 > URL: https://issues.apache.org/jira/browse/NIFI-3193 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Affects Versions: 1.0.0, 1.1.0, 0.7.1 >Reporter: Brian >Assignee: Michael Hogue > > At the moment the NiFi AMQP processors can establish a SSL connection to > RabbitMQ but still user a user defined username and password to authenticate. > When using certificates RabbitMQ allows you to use to COMMON_NAME from the > certificate to authenticate instead of providing a username and password. > Unfortunately the NiFi processors do not support this so I would like to > request an update to the processors to enable this functionality. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-3193) Update ConsumeAMQP and PublishAMQP to retrieve username from certificate common name
[ https://issues.apache.org/jira/browse/NIFI-3193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065392#comment-16065392 ] Michael Hogue commented on NIFI-3193: - [~bdeep] : A couple of things. In thinking about your feature request to go ahead and declare a queue if it doesn't exist, that's only possible for NiFi to do if you're not using exchanges (i.e. you're just using the default exchange). The reason is that RabbitMQ maintains a mapping of which the exchanges leverage to route messages to the appropriate queue. In that case, NiFi would have no knowledge of which queue the message would be routed to. Per one of the RabbitMQ docs [1], in the case that the exchange provided is empty, then the routing key is assumed to be the queue name. In that case, we could declare it if it doesn't exist. The issue is that there are a number of arguments in queue declaration that i feel would need to be explicit (See Queues in [1]). Perhaps it'd be better if the queue declaration were left to RabbitMQ admins? Thoughts? > For example, when you declare a queue with the name of > "search-indexing-online", the AMQP 0-9-1 broker will bind it to the default > exchange using "search-indexing-online" as the routing key. Therefore, a > message published to the default exchange with the routing key > "search-indexing-online" will be routed to the queue > "search-indexing-online". In other words, the default exchange makes it seem > like it is possible to deliver messages directly to queues, even though that > is not technically what is happening. [1] https://www.rabbitmq.com/tutorials/amqp-concepts.html -- See 'Default Exchange', 'Queues' > Update ConsumeAMQP and PublishAMQP to retrieve username from certificate > common name > > > Key: NIFI-3193 > URL: https://issues.apache.org/jira/browse/NIFI-3193 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Affects Versions: 1.0.0, 1.1.0, 0.7.1 >Reporter: Brian >Assignee: Michael Hogue > > At the moment the NiFi AMQP processors can establish a SSL connection to > RabbitMQ but still user a user defined username and password to authenticate. > When using certificates RabbitMQ allows you to use to COMMON_NAME from the > certificate to authenticate instead of providing a username and password. > Unfortunately the NiFi processors do not support this so I would like to > request an update to the processors to enable this functionality. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (NIFI-4045) POST lineage does may not populate eventId
[ https://issues.apache.org/jira/browse/NIFI-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-4045: - Resolution: Fixed Fix Version/s: 1.4.0 Status: Resolved (was: Patch Available) > POST lineage does may not populate eventId > -- > > Key: NIFI-4045 > URL: https://issues.apache.org/jira/browse/NIFI-4045 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: Matt Gilman >Assignee: Matt Gilman >Priority: Trivial > Fix For: 1.4.0 > > > The when submitting a request for flowfile lineage, the request can be made > using either a flowfile uuid or an event id. Currently, the event id is not > populated when the request was made using the event id. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4045) POST lineage does may not populate eventId
[ https://issues.apache.org/jira/browse/NIFI-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065367#comment-16065367 ] ASF subversion and git services commented on NIFI-4045: --- Commit c99c036c207d6e434295bb1200dbcffacdffd128 in nifi's branch refs/heads/master from [~mcgilman] [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=c99c036 ] NIFI-4045: - Addressing issues causing the eventId to not be relayed when submitting a lineage request under certain conditions. Signed-off-by: Pierre Villard This closes #1903. > POST lineage does may not populate eventId > -- > > Key: NIFI-4045 > URL: https://issues.apache.org/jira/browse/NIFI-4045 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: Matt Gilman >Assignee: Matt Gilman >Priority: Trivial > > The when submitting a request for flowfile lineage, the request can be made > using either a flowfile uuid or an event id. Currently, the event id is not > populated when the request was made using the event id. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4045) POST lineage does may not populate eventId
[ https://issues.apache.org/jira/browse/NIFI-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065369#comment-16065369 ] ASF GitHub Bot commented on NIFI-4045: -- Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/1903 > POST lineage does may not populate eventId > -- > > Key: NIFI-4045 > URL: https://issues.apache.org/jira/browse/NIFI-4045 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: Matt Gilman >Assignee: Matt Gilman >Priority: Trivial > > The when submitting a request for flowfile lineage, the request can be made > using either a flowfile uuid or an event id. Currently, the event id is not > populated when the request was made using the event id. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi pull request #1903: NIFI-4045: POST lineage may not respond with eventI...
Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/1903 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-4045) POST lineage does may not populate eventId
[ https://issues.apache.org/jira/browse/NIFI-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065366#comment-16065366 ] ASF GitHub Bot commented on NIFI-4045: -- Github user pvillard31 commented on the issue: https://github.com/apache/nifi/pull/1903 +1, code LGTM, build OK, event ID is correctly populated in the requests. > POST lineage does may not populate eventId > -- > > Key: NIFI-4045 > URL: https://issues.apache.org/jira/browse/NIFI-4045 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: Matt Gilman >Assignee: Matt Gilman >Priority: Trivial > > The when submitting a request for flowfile lineage, the request can be made > using either a flowfile uuid or an event id. Currently, the event id is not > populated when the request was made using the event id. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #1903: NIFI-4045: POST lineage may not respond with eventId
Github user pvillard31 commented on the issue: https://github.com/apache/nifi/pull/1903 +1, code LGTM, build OK, event ID is correctly populated in the requests. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-4086) Docker image produced by Dockerfile is larger than needed
[ https://issues.apache.org/jira/browse/NIFI-4086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065346#comment-16065346 ] ASF GitHub Bot commented on NIFI-4086: -- Github user pvillard31 commented on the issue: https://github.com/apache/nifi/pull/1926 Actually... just realized that your work would be included by #1910. > Docker image produced by Dockerfile is larger than needed > - > > Key: NIFI-4086 > URL: https://issues.apache.org/jira/browse/NIFI-4086 > Project: Apache NiFi > Issue Type: Bug > Components: Docker >Reporter: Niels Zeilemaker > > The Dockerfile has a chown action after the curl, which more or less doubles > the size of the resulting docker image. Merging the chown step into the curl > step fixes this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #1926: NIFI-4086 Add chown to curl step to save space in final im...
Github user pvillard31 commented on the issue: https://github.com/apache/nifi/pull/1926 Actually... just realized that your work would be included by #1910. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi issue #1926: NIFI-4086 Add chown to curl step to save space in final im...
Github user pvillard31 commented on the issue: https://github.com/apache/nifi/pull/1926 Hey @NielsZeilemaker, thanks for your contribution! It's a +1 from me, I do see a real improvement on the size of the image but I'd appreciate if @apiri or @jdye64 could also have a quick look. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-4086) Docker image produced by Dockerfile is larger than needed
[ https://issues.apache.org/jira/browse/NIFI-4086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065335#comment-16065335 ] ASF GitHub Bot commented on NIFI-4086: -- Github user pvillard31 commented on the issue: https://github.com/apache/nifi/pull/1926 Hey @NielsZeilemaker, thanks for your contribution! It's a +1 from me, I do see a real improvement on the size of the image but I'd appreciate if @apiri or @jdye64 could also have a quick look. > Docker image produced by Dockerfile is larger than needed > - > > Key: NIFI-4086 > URL: https://issues.apache.org/jira/browse/NIFI-4086 > Project: Apache NiFi > Issue Type: Bug > Components: Docker >Reporter: Niels Zeilemaker > > The Dockerfile has a chown action after the curl, which more or less doubles > the size of the resulting docker image. Merging the chown step into the curl > step fixes this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4105) support the specified Maximum value column and CSV Stream for Cassandra
[ https://issues.apache.org/jira/browse/NIFI-4105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065333#comment-16065333 ] ASF GitHub Bot commented on NIFI-4105: -- Github user pvillard31 commented on the issue: https://github.com/apache/nifi/pull/1937 Hi @ggthename, thanks for your contribution. Can you check that ``mvn clean install -Pcontrib-check`` is succeeding on your side? Travis builds are complaining about test failures and I've the same on my side. Once you have a succeeding build, can you rebase your PR and squash your commits. Thanks! > support the specified Maximum value column and CSV Stream for Cassandra > --- > > Key: NIFI-4105 > URL: https://issues.apache.org/jira/browse/NIFI-4105 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.3.0 >Reporter: Yoonwon Ko > > I'm trying to find a CassandraProcessor to fetch rows whose values in the > specified Maximum Value columns are larger than the previously-seen maximum > like QueryDatabaseTable. > But I found only QueryCassandra. It just executes same CQL everytime without > keeping maximum value. > and I think we also need convertToCsvStream option. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #1937: NIFI-4105 support the specified Maximum value column and C...
Github user pvillard31 commented on the issue: https://github.com/apache/nifi/pull/1937 Hi @ggthename, thanks for your contribution. Can you check that ``mvn clean install -Pcontrib-check`` is succeeding on your side? Travis builds are complaining about test failures and I've the same on my side. Once you have a succeeding build, can you rebase your PR and squash your commits. Thanks! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (NIFI-4135) RangerNiFiAuthorizer should support storing audit info to HDFS
Yolanda M. Davis created NIFI-4135: -- Summary: RangerNiFiAuthorizer should support storing audit info to HDFS Key: NIFI-4135 URL: https://issues.apache.org/jira/browse/NIFI-4135 Project: Apache NiFi Issue Type: Bug Components: Extensions Reporter: Yolanda M. Davis Assignee: Yolanda M. Davis When using Ranger to support authorization an option to log auditing information to HDFS can be supported. The RangerNiFiAuthorizer should be prepared to communicate with a hadoop cluster in order to support this feature. In it's current implementation the authorizer does not have the hadoop-client jars available as a dependency nor does it support the ability to refer to the required *.site.xml files in order to communicate without using the default configuration. Both of these changes are needed in order to send audit info to HDFS. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi-minifi pull request #86: MINIFI-344: Enabling running as a windows serv...
Github user jzonthemtn commented on a diff in the pull request: https://github.com/apache/nifi-minifi/pull/86#discussion_r124367664 --- Diff: minifi-docs/src/main/markdown/System_Admin_Guide.md --- @@ -650,6 +650,16 @@ NiFi Properties Overrides: nifi.database.directory: ./database_repository_override ``` +# Running as a Windows Service --- End diff -- A Windows service appears to run with a working directory of `C:\Windows\System32` and this causes problems when the directories in the configuration are relative paths. Setting them to absolute paths lets the service find the files it wants. Not my preferred solution but is cleaner than others I tried. If anyone has any other ideas let me know. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Updated] (NIFI-4129) The duplicate portion of the shell.sh file should be delete
[ https://issues.apache.org/jira/browse/NIFI-4129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-4129: - Fix Version/s: (was: 1.2.0) > The duplicate portion of the shell.sh file should be delete > --- > > Key: NIFI-4129 > URL: https://issues.apache.org/jira/browse/NIFI-4129 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.2.0, 1.1.1 >Reporter: shuguo zheng > > Delete the duplicate portion of the shell.sh file -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4129) The duplicate portion of the shell.sh file should be delete
[ https://issues.apache.org/jira/browse/NIFI-4129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065316#comment-16065316 ] ASF GitHub Bot commented on NIFI-4129: -- Github user pvillard31 commented on the issue: https://github.com/apache/nifi/pull/1952 I'm not sure to see why this should need to be removed. This part ensures that the file that is created to define NiFi as a service is containing the proper header with the Apache licensing. Why would you want/need to remove that? > The duplicate portion of the shell.sh file should be delete > --- > > Key: NIFI-4129 > URL: https://issues.apache.org/jira/browse/NIFI-4129 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.2.0, 1.1.1 >Reporter: shuguo zheng > Fix For: 1.2.0 > > > Delete the duplicate portion of the shell.sh file -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #1952: [NIFI-4129]Delete the duplicate portion of the shell.sh fi...
Github user pvillard31 commented on the issue: https://github.com/apache/nifi/pull/1952 I'm not sure to see why this should need to be removed. This part ensures that the file that is created to define NiFi as a service is containing the proper header with the Apache licensing. Why would you want/need to remove that? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi-minifi pull request #86: MINIFI-344: Enabling running as a windows serv...
Github user jzonthemtn commented on a diff in the pull request:
https://github.com/apache/nifi-minifi/pull/86#discussion_r124366986
--- Diff:
minifi-bootstrap/src/main/java/org/apache/nifi/minifi/bootstrap/RunMiNiFi.java
---
@@ -275,7 +275,7 @@ public static void main(String[] args) throws
IOException, InterruptedException
}
}
-private static File getBootstrapConfFile() {
+public static File getBootstrapConfFile() {
--- End diff --
I changed this to `public` so the new `WindowsService` class could call it
instead of duplicating the function.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] nifi-minifi pull request #86: MINIFI-344: Enabling running as a windows serv...
Github user jzonthemtn commented on a diff in the pull request: https://github.com/apache/nifi-minifi/pull/86#discussion_r124366751 --- Diff: minifi-assembly/src/main/assembly/dependencies.xml --- @@ -107,7 +107,7 @@ true -true +false --- End diff -- I didn't see any values that were actually being filtered. I set it to `false` so it would not interfere with the Commons Daemon executables. If I missed some let me know... --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi-minifi pull request #86: MINIFI-344: Enabling running as a windows serv...
GitHub user jzonthemtn opened a pull request: https://github.com/apache/nifi-minifi/pull/86 MINIFI-344: Enabling running as a windows service. Thank you for submitting a contribution to Apache NiFi - MiNiFi. 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 MINIFI- 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: - [X] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi-minifi folder? - [ ] Have you written or updated unit tests to verify your 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, including the main LICENSE file under minifi-assembly? - [X] If applicable, have you updated the NOTICE file, including the main NOTICE file found under minifi-assembly? ### 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 travis-ci for build issues and submit an update to your PR as soon as possible. You can merge this pull request into a Git repository by running: $ git pull https://github.com/jzonthemtn/nifi-minifi MINIFI-344 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi-minifi/pull/86.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #86 commit 7392b218d249abe4d10bda49c4d18a8ec49fd6ea Author: jzonthemtn Date: 2017-06-27T18:58:44Z MINIFI-344: Enabling running as a windows service. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Resolved] (NIFI-4126) ExtractGrok performance
[ https://issues.apache.org/jira/browse/NIFI-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard resolved NIFI-4126. -- Resolution: Fixed Fix Version/s: 1.4.0 > ExtractGrok performance > --- > > Key: NIFI-4126 > URL: https://issues.apache.org/jira/browse/NIFI-4126 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.2.0, 1.3.0 >Reporter: Andre F de Miranda >Assignee: Andre F de Miranda > Fix For: 1.4.0 > > > Currently ExtractGrok performance is low compared to other processors. We > should investigate the feasibility of using performance relevant annotations > such as side effect free and support batching to improve its performance -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (NIFI-4126) ExtractGrok performance
[ https://issues.apache.org/jira/browse/NIFI-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-4126: - Component/s: Extensions Issue Type: Improvement (was: Bug) > ExtractGrok performance > --- > > Key: NIFI-4126 > URL: https://issues.apache.org/jira/browse/NIFI-4126 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.2.0, 1.3.0 >Reporter: Andre F de Miranda >Assignee: Andre F de Miranda > > Currently ExtractGrok performance is low compared to other processors. We > should investigate the feasibility of using performance relevant annotations > such as side effect free and support batching to improve its performance -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4126) ExtractGrok performance
[ https://issues.apache.org/jira/browse/NIFI-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065300#comment-16065300 ] ASF subversion and git services commented on NIFI-4126: --- Commit 1e7eceee8433d59904551d14856d66498785fdf2 in nifi's branch refs/heads/master from [~trixpan] [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=1e7ecee ] NIFI-4126 - Add SupportBatching, SideEffectFree and EventDriven annotations to ExtractGrok Signed-off-by: Pierre Villard This closes #1950. > ExtractGrok performance > --- > > Key: NIFI-4126 > URL: https://issues.apache.org/jira/browse/NIFI-4126 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.2.0, 1.3.0 >Reporter: Andre F de Miranda >Assignee: Andre F de Miranda > > Currently ExtractGrok performance is low compared to other processors. We > should investigate the feasibility of using performance relevant annotations > such as side effect free and support batching to improve its performance -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4126) ExtractGrok performance
[ https://issues.apache.org/jira/browse/NIFI-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065301#comment-16065301 ] ASF GitHub Bot commented on NIFI-4126: -- Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/1950 > ExtractGrok performance > --- > > Key: NIFI-4126 > URL: https://issues.apache.org/jira/browse/NIFI-4126 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.2.0, 1.3.0 >Reporter: Andre F de Miranda >Assignee: Andre F de Miranda > > Currently ExtractGrok performance is low compared to other processors. We > should investigate the feasibility of using performance relevant annotations > such as side effect free and support batching to improve its performance -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi pull request #1950: NIFI-4126 - Add SupportBatching, SideEffectFree and...
Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/1950 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-4126) ExtractGrok performance
[ https://issues.apache.org/jira/browse/NIFI-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065298#comment-16065298 ] ASF GitHub Bot commented on NIFI-4126: -- Github user pvillard31 commented on the issue: https://github.com/apache/nifi/pull/1950 +1, merging, thanks @trixpan > ExtractGrok performance > --- > > Key: NIFI-4126 > URL: https://issues.apache.org/jira/browse/NIFI-4126 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.2.0, 1.3.0 >Reporter: Andre F de Miranda >Assignee: Andre F de Miranda > > Currently ExtractGrok performance is low compared to other processors. We > should investigate the feasibility of using performance relevant annotations > such as side effect free and support batching to improve its performance -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #1950: NIFI-4126 - Add SupportBatching, SideEffectFree and EventD...
Github user pvillard31 commented on the issue: https://github.com/apache/nifi/pull/1950 +1, merging, thanks @trixpan --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-4133) PublishKafkaRecord_0_10 should allow publishing all messages from a flow file to the same partition
[
https://issues.apache.org/jira/browse/NIFI-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065262#comment-16065262
]
Bryan Bende commented on NIFI-4133:
---
We also need to consider that someone might want to all flow files from a given
source to a specific partition. For that case it may be better to have a
property "Partition" that supports EL and then we could do something like:
GetFile (source1) -> UpdateAttribute (set kafka.partition = 1) -> PublishKafka
(partition = ${kafka.partition})
GetFile (source2) -> UpdateAttribute (set kafka.partition = 2) -> PublishKafka
(partition = ${kafka.partition})
> PublishKafkaRecord_0_10 should allow publishing all messages from a flow file
> to the same partition
> ---
>
> Key: NIFI-4133
> URL: https://issues.apache.org/jira/browse/NIFI-4133
> Project: Apache NiFi
> Issue Type: Improvement
>Affects Versions: 1.2.0, 1.3.0
>Reporter: Bryan Bende
>Priority: Minor
>
> In some use cases it is required to publish all of the messages from a given
> flow file to the same partition so that they can later be consumer in the
> same order.
> Currently the processor provides an option to choose between the default
> partitioner and a round-robin partitioner, and also allows specifying the
> name of a field in each record to use as a message key.
> The default partitioner has the following behavior:
> 1) If a partition is specified in the record, use it
> 2) If no partition is specified but a key is present choose a partition
> based on a hash of the key
> 3) If no partition or key is present choose a partition in a round-robin
> fashion
> Currently we never pass in a partition to the Kafka record that is created,
> so we always fall into #2 or #3, and the message key is really meant to be
> unique per-event so we shouldn't be relying on every message using the same
> message key.
> We should add an option to the processor like "Partition per FlowFile" which
> can be used with the default partitioner, and the NiFi side will pass in the
> same partition for each message created from the same flow file.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (NIFI-4133) PublishKafkaRecord_0_10 should allow publishing all messages from a flow file to the same partition
[
https://issues.apache.org/jira/browse/NIFI-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065262#comment-16065262
]
Bryan Bende edited comment on NIFI-4133 at 6/27/17 6:28 PM:
We also need to consider that someone might want to all flow files from a given
source to a specific partition. For that case it may be better to have a
property "Partition" that supports EL and then we could do something like:
{code}
GetFile (source1) -> UpdateAttribute (set kafka.partition = 1) -> PublishKafka
(partition = ${kafka.partition})
GetFile (source2) -> UpdateAttribute (set kafka.partition = 2) -> PublishKafka
(partition = ${kafka.partition})
{code}
was (Author: bende):
We also need to consider that someone might want to all flow files from a given
source to a specific partition. For that case it may be better to have a
property "Partition" that supports EL and then we could do something like:
GetFile (source1) -> UpdateAttribute (set kafka.partition = 1) -> PublishKafka
(partition = ${kafka.partition})
GetFile (source2) -> UpdateAttribute (set kafka.partition = 2) -> PublishKafka
(partition = ${kafka.partition})
> PublishKafkaRecord_0_10 should allow publishing all messages from a flow file
> to the same partition
> ---
>
> Key: NIFI-4133
> URL: https://issues.apache.org/jira/browse/NIFI-4133
> Project: Apache NiFi
> Issue Type: Improvement
>Affects Versions: 1.2.0, 1.3.0
>Reporter: Bryan Bende
>Priority: Minor
>
> In some use cases it is required to publish all of the messages from a given
> flow file to the same partition so that they can later be consumer in the
> same order.
> Currently the processor provides an option to choose between the default
> partitioner and a round-robin partitioner, and also allows specifying the
> name of a field in each record to use as a message key.
> The default partitioner has the following behavior:
> 1) If a partition is specified in the record, use it
> 2) If no partition is specified but a key is present choose a partition
> based on a hash of the key
> 3) If no partition or key is present choose a partition in a round-robin
> fashion
> Currently we never pass in a partition to the Kafka record that is created,
> so we always fall into #2 or #3, and the message key is really meant to be
> unique per-event so we shouldn't be relying on every message using the same
> message key.
> We should add an option to the processor like "Partition per FlowFile" which
> can be used with the default partitioner, and the NiFi side will pass in the
> same partition for each message created from the same flow file.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (NIFI-4119) Improve UX of canvas label configuration
[ https://issues.apache.org/jira/browse/NIFI-4119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065209#comment-16065209 ] ASF GitHub Bot commented on NIFI-4119: -- Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/1940 > Improve UX of canvas label configuration > > > Key: NIFI-4119 > URL: https://issues.apache.org/jira/browse/NIFI-4119 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Affects Versions: 1.3.0 >Reporter: Yuri >Priority: Trivial > Labels: newbie > > The single most used field of a canvas label's configuration dialog is it's > text value. Naturally, it should be in focus as soon as you open the dialog. > Current UX seems to be tedious when dealing with multiple labels. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4119) Improve UX of canvas label configuration
[ https://issues.apache.org/jira/browse/NIFI-4119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065212#comment-16065212 ] ASF GitHub Bot commented on NIFI-4119: -- Github user alopresto commented on the issue: https://github.com/apache/nifi/pull/1940 Ran `contrib-check` and all tests pass. +1, merging. > Improve UX of canvas label configuration > > > Key: NIFI-4119 > URL: https://issues.apache.org/jira/browse/NIFI-4119 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Affects Versions: 1.3.0 >Reporter: Yuri >Priority: Trivial > Labels: newbie > > The single most used field of a canvas label's configuration dialog is it's > text value. Naturally, it should be in focus as soon as you open the dialog. > Current UX seems to be tedious when dealing with multiple labels. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi issue #1940: NIFI-4119 - Improve UX of canvas label configuration
Github user alopresto commented on the issue: https://github.com/apache/nifi/pull/1940 Ran `contrib-check` and all tests pass. +1, merging. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi pull request #1940: NIFI-4119 - Improve UX of canvas label configuratio...
Github user asfgit closed the pull request at: https://github.com/apache/nifi/pull/1940 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-4119) Improve UX of canvas label configuration
[ https://issues.apache.org/jira/browse/NIFI-4119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065208#comment-16065208 ] ASF subversion and git services commented on NIFI-4119: --- Commit 202eb5ccbee5e7033de59fcfc59384254c4ae4ed in nifi's branch refs/heads/master from [~yuri1969] [ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=202eb5c ] NIFI-4119 - Improve UX of canvas label configuration by providing immediate focus to value field This closes #1940. Signed-off-by: Andy LoPresto > Improve UX of canvas label configuration > > > Key: NIFI-4119 > URL: https://issues.apache.org/jira/browse/NIFI-4119 > Project: Apache NiFi > Issue Type: Improvement > Components: Core UI >Affects Versions: 1.3.0 >Reporter: Yuri >Priority: Trivial > Labels: newbie > > The single most used field of a canvas label's configuration dialog is it's > text value. Naturally, it should be in focus as soon as you open the dialog. > Current UX seems to be tedious when dealing with multiple labels. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4038) Create gRPC server processor
[
https://issues.apache.org/jira/browse/NIFI-4038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065196#comment-16065196
]
ASF GitHub Bot commented on NIFI-4038:
--
Github user m-hogue commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1947#discussion_r124347240
--- Diff:
nifi-nar-bundles/nifi-grpc-bundle/nifi-grpc-processors/src/main/resources/proto/grpc.proto
---
@@ -0,0 +1,57 @@
+// 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.
+
+// NOTE: you may need to add the sources generated when running `maven
clean compile` to your IDE
+// configured source directories. Otherwise, the classes generated when
the proto is compiled won't
+// be accessible. For IntelliJ, open this module's settings and mark the
following as source directories:
+//
+// * target/generated-sources/protobuf/grpc-java
+// * target/generated-sources/protobuf/java
+
+syntax = "proto3";
+
+option java_multiple_files = true;
+option java_package = "org.apache.nifi.processors.grpc";
+option java_outer_classname = "GRPCProto";
+option objc_class_prefix = "grpc";
+
+package org.apache.nifi.processors.grpc;
+
+// The FlowFile service definition.
+service FlowFileService {
+// Sends a FlowFile (blocking rpc)
+rpc Send (FlowFileRequest) returns (FlowFileReply) {}
+}
+
+// The request message
+message FlowFileRequest {
+// tags 1-15 require one byte to encode and should be left for
commonly occurring tags.
+// For that reason, tags 3-14 are left available.
+int64 id = 1;
+map attributes = 2;
+bytes content = 15;
--- End diff --
Technically yes, per the protobuf docs. I'll add a comment to the IDL.
> The smallest tag number you can specify is 1, and the largest is 229 - 1,
or 536,870,911. You also cannot use the numbers 19000 through 1 [1]
[1]
https://developers.google.com/protocol-buffers/docs/proto3#assigning-tags
> Create gRPC server processor
>
>
> Key: NIFI-4038
> URL: https://issues.apache.org/jira/browse/NIFI-4038
> Project: Apache NiFi
> Issue Type: New Feature
>Reporter: Michael Hogue
>Assignee: Michael Hogue
>Priority: Minor
> Attachments: listen_and_invoke_grpc.xml
>
>
> Create a simple gRPC [1] server processor similar to `HandleHttpRequest` that
> listens for RPCs from the gRPC processor created in NIFI-4037.
> [1] http://www.grpc.io/about/
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] nifi pull request #1947: NIFI-4038, NIFI-4037 grpc client and server process...
Github user m-hogue commented on a diff in the pull request:
https://github.com/apache/nifi/pull/1947#discussion_r124347240
--- Diff:
nifi-nar-bundles/nifi-grpc-bundle/nifi-grpc-processors/src/main/resources/proto/grpc.proto
---
@@ -0,0 +1,57 @@
+// 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.
+
+// NOTE: you may need to add the sources generated when running `maven
clean compile` to your IDE
+// configured source directories. Otherwise, the classes generated when
the proto is compiled won't
+// be accessible. For IntelliJ, open this module's settings and mark the
following as source directories:
+//
+// * target/generated-sources/protobuf/grpc-java
+// * target/generated-sources/protobuf/java
+
+syntax = "proto3";
+
+option java_multiple_files = true;
+option java_package = "org.apache.nifi.processors.grpc";
+option java_outer_classname = "GRPCProto";
+option objc_class_prefix = "grpc";
+
+package org.apache.nifi.processors.grpc;
+
+// The FlowFile service definition.
+service FlowFileService {
+// Sends a FlowFile (blocking rpc)
+rpc Send (FlowFileRequest) returns (FlowFileReply) {}
+}
+
+// The request message
+message FlowFileRequest {
+// tags 1-15 require one byte to encode and should be left for
commonly occurring tags.
+// For that reason, tags 3-14 are left available.
+int64 id = 1;
+map attributes = 2;
+bytes content = 15;
--- End diff --
Technically yes, per the protobuf docs. I'll add a comment to the IDL.
> The smallest tag number you can specify is 1, and the largest is 229 - 1,
or 536,870,911. You also cannot use the numbers 19000 through 1 [1]
[1]
https://developers.google.com/protocol-buffers/docs/proto3#assigning-tags
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (NIFI-4124) Add a Record API-based PutMongo clone
[ https://issues.apache.org/jira/browse/NIFI-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065181#comment-16065181 ] ASF GitHub Bot commented on NIFI-4124: -- Github user MikeThomsen closed the pull request at: https://github.com/apache/nifi/pull/1945 > Add a Record API-based PutMongo clone > - > > Key: NIFI-4124 > URL: https://issues.apache.org/jira/browse/NIFI-4124 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Mike Thomsen >Priority: Minor > Labels: mongodb, putmongo, records > > A new processor that can use the Record API to put data into Mongo is needed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NIFI-4124) Add a Record API-based PutMongo clone
[ https://issues.apache.org/jira/browse/NIFI-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065183#comment-16065183 ] ASF GitHub Bot commented on NIFI-4124: -- GitHub user MikeThomsen reopened a pull request: https://github.com/apache/nifi/pull/1945 NIFI-4124 Added org.apache.nifi.mongo.PutMongoRecord. https://issues.apache.org/jira/browse/NIFI-4124 You can merge this pull request into a Git repository by running: $ git pull https://github.com/MikeThomsen/nifi NIFI-4124 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/1945.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1945 commit 19653f2784e8dc32312ba1ed204edb99e98dca82 Author: Mike Thomsen Date: 2017-06-26T16:36:51Z NIFI-4124 Added org.apache.nifi.mongo.PutMongoRecord. > Add a Record API-based PutMongo clone > - > > Key: NIFI-4124 > URL: https://issues.apache.org/jira/browse/NIFI-4124 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Mike Thomsen >Priority: Minor > Labels: mongodb, putmongo, records > > A new processor that can use the Record API to put data into Mongo is needed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi pull request #1945: NIFI-4124 Added org.apache.nifi.mongo.PutMongoRecor...
GitHub user MikeThomsen reopened a pull request: https://github.com/apache/nifi/pull/1945 NIFI-4124 Added org.apache.nifi.mongo.PutMongoRecord. https://issues.apache.org/jira/browse/NIFI-4124 You can merge this pull request into a Git repository by running: $ git pull https://github.com/MikeThomsen/nifi NIFI-4124 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/1945.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1945 commit 19653f2784e8dc32312ba1ed204edb99e98dca82 Author: Mike Thomsen Date: 2017-06-26T16:36:51Z NIFI-4124 Added org.apache.nifi.mongo.PutMongoRecord. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] nifi pull request #1945: NIFI-4124 Added org.apache.nifi.mongo.PutMongoRecor...
Github user MikeThomsen closed the pull request at: https://github.com/apache/nifi/pull/1945 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-4038) Create gRPC server processor
[ https://issues.apache.org/jira/browse/NIFI-4038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065169#comment-16065169 ] ASF GitHub Bot commented on NIFI-4038: -- Github user m-hogue commented on a diff in the pull request: https://github.com/apache/nifi/pull/1947#discussion_r124342294 --- Diff: nifi-nar-bundles/nifi-grpc-bundle/nifi-grpc-nar/src/main/resources/LICENSE --- @@ -0,0 +1,259 @@ + Apache License + Version 2.0, January 2004 +http://www.apache.org/licenses/ + + TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION + + 1. Definitions. + + "License" shall mean the terms and conditions for use, reproduction, + and distribution as defined by Sections 1 through 9 of this document. + + "Licensor" shall mean the copyright owner or entity authorized by + the copyright owner that is granting the License. + + "Legal Entity" shall mean the union of the acting entity and all + other entities that control, are controlled by, or are under common + control with that entity. For the purposes of this definition, + "control" means (i) the power, direct or indirect, to cause the + direction or management of such entity, whether by contract or + otherwise, or (ii) ownership of fifty percent (50%) or more of the + outstanding shares, or (iii) beneficial ownership of such entity. + + "You" (or "Your") shall mean an individual or Legal Entity + exercising permissions granted by this License. + + "Source" form shall mean the preferred form for making modifications, + including but not limited to software source code, documentation + source, and configuration files. + + "Object" form shall mean any form resulting from mechanical + transformation or translation of a Source form, including but + not limited to compiled object code, generated documentation, + and conversions to other media types. + + "Work" shall mean the work of authorship, whether in Source or + Object form, made available under the License, as indicated by a + copyright notice that is included in or attached to the work + (an example is provided in the Appendix below). + + "Derivative Works" shall mean any work, whether in Source or Object + form, that is based on (or derived from) the Work and for which the + editorial revisions, annotations, elaborations, or other modifications + represent, as a whole, an original work of authorship. For the purposes + of this License, Derivative Works shall not include works that remain + separable from, or merely link (or bind by name) to the interfaces of, + the Work and Derivative Works thereof. + + "Contribution" shall mean any work of authorship, including + the original version of the Work and any modifications or additions + to that Work or Derivative Works thereof, that is intentionally + submitted to Licensor for inclusion in the Work by the copyright owner + or by an individual or Legal Entity authorized to submit on behalf of + the copyright owner. For the purposes of this definition, "submitted" + means any form of electronic, verbal, or written communication sent + to the Licensor or its representatives, including but not limited to + communication on electronic mailing lists, source code control systems, + and issue tracking systems that are managed by, or on behalf of, the + Licensor for the purpose of discussing and improving the Work, but + excluding communication that is conspicuously marked or otherwise + designated in writing by the copyright owner as "Not a Contribution." + + "Contributor" shall mean Licensor and any individual or Legal Entity + on behalf of whom a Contribution has been received by Licensor and + subsequently incorporated within the Work. + + 2. Grant of Copyright License. Subject to the terms and conditions of + this License, each Contributor hereby grants to You a perpetual, + worldwide, non-exclusive, no-charge, royalty-free, irrevocable + copyright license to reproduce, prepare Derivative Works of, + publicly display, publicly perform, sublicense, and distribute the + Work and such Derivative Works in Source or Object form. + + 3. Grant of Patent License. Subject to the terms and conditions of + this License, each Contributor hereby grants to You a perpetual, + worldwide, non-exclusive, no-charge, royalty-free, i
[GitHub] nifi pull request #1947: NIFI-4038, NIFI-4037 grpc client and server process...
Github user m-hogue commented on a diff in the pull request: https://github.com/apache/nifi/pull/1947#discussion_r124342294 --- Diff: nifi-nar-bundles/nifi-grpc-bundle/nifi-grpc-nar/src/main/resources/LICENSE --- @@ -0,0 +1,259 @@ + Apache License + Version 2.0, January 2004 +http://www.apache.org/licenses/ + + TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION + + 1. Definitions. + + "License" shall mean the terms and conditions for use, reproduction, + and distribution as defined by Sections 1 through 9 of this document. + + "Licensor" shall mean the copyright owner or entity authorized by + the copyright owner that is granting the License. + + "Legal Entity" shall mean the union of the acting entity and all + other entities that control, are controlled by, or are under common + control with that entity. For the purposes of this definition, + "control" means (i) the power, direct or indirect, to cause the + direction or management of such entity, whether by contract or + otherwise, or (ii) ownership of fifty percent (50%) or more of the + outstanding shares, or (iii) beneficial ownership of such entity. + + "You" (or "Your") shall mean an individual or Legal Entity + exercising permissions granted by this License. + + "Source" form shall mean the preferred form for making modifications, + including but not limited to software source code, documentation + source, and configuration files. + + "Object" form shall mean any form resulting from mechanical + transformation or translation of a Source form, including but + not limited to compiled object code, generated documentation, + and conversions to other media types. + + "Work" shall mean the work of authorship, whether in Source or + Object form, made available under the License, as indicated by a + copyright notice that is included in or attached to the work + (an example is provided in the Appendix below). + + "Derivative Works" shall mean any work, whether in Source or Object + form, that is based on (or derived from) the Work and for which the + editorial revisions, annotations, elaborations, or other modifications + represent, as a whole, an original work of authorship. For the purposes + of this License, Derivative Works shall not include works that remain + separable from, or merely link (or bind by name) to the interfaces of, + the Work and Derivative Works thereof. + + "Contribution" shall mean any work of authorship, including + the original version of the Work and any modifications or additions + to that Work or Derivative Works thereof, that is intentionally + submitted to Licensor for inclusion in the Work by the copyright owner + or by an individual or Legal Entity authorized to submit on behalf of + the copyright owner. For the purposes of this definition, "submitted" + means any form of electronic, verbal, or written communication sent + to the Licensor or its representatives, including but not limited to + communication on electronic mailing lists, source code control systems, + and issue tracking systems that are managed by, or on behalf of, the + Licensor for the purpose of discussing and improving the Work, but + excluding communication that is conspicuously marked or otherwise + designated in writing by the copyright owner as "Not a Contribution." + + "Contributor" shall mean Licensor and any individual or Legal Entity + on behalf of whom a Contribution has been received by Licensor and + subsequently incorporated within the Work. + + 2. Grant of Copyright License. Subject to the terms and conditions of + this License, each Contributor hereby grants to You a perpetual, + worldwide, non-exclusive, no-charge, royalty-free, irrevocable + copyright license to reproduce, prepare Derivative Works of, + publicly display, publicly perform, sublicense, and distribute the + Work and such Derivative Works in Source or Object form. + + 3. Grant of Patent License. Subject to the terms and conditions of + this License, each Contributor hereby grants to You a perpetual, + worldwide, non-exclusive, no-charge, royalty-free, irrevocable + (except as stated in this section) patent license to make, have made, + use, offer to sell, sell, import, and otherwise transfer the Work, + where such license applies only to those patent claims licensable +
[jira] [Commented] (NIFI-3193) Update ConsumeAMQP and PublishAMQP to retrieve username from certificate common name
[ https://issues.apache.org/jira/browse/NIFI-3193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065166#comment-16065166 ] Michael Hogue commented on NIFI-3193: - I'm on it. > Update ConsumeAMQP and PublishAMQP to retrieve username from certificate > common name > > > Key: NIFI-3193 > URL: https://issues.apache.org/jira/browse/NIFI-3193 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Affects Versions: 1.0.0, 1.1.0, 0.7.1 >Reporter: Brian >Assignee: Michael Hogue > > At the moment the NiFi AMQP processors can establish a SSL connection to > RabbitMQ but still user a user defined username and password to authenticate. > When using certificates RabbitMQ allows you to use to COMMON_NAME from the > certificate to authenticate instead of providing a username and password. > Unfortunately the NiFi processors do not support this so I would like to > request an update to the processors to enable this functionality. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (NIFI-4134) Introduce checks to prevent Admin from removing there own permissions
Matt Gilman created NIFI-4134: - Summary: Introduce checks to prevent Admin from removing there own permissions Key: NIFI-4134 URL: https://issues.apache.org/jira/browse/NIFI-4134 Project: Apache NiFi Issue Type: Improvement Components: Core Framework, Core UI Reporter: Matt Gilman Priority: Minor Install checks and update UI to prevent an administrator from removing their own permissions to the admin policies (access all policies -> Read/Write). If they are the only admin and this action is performed, it would require the user to delete the existing authorizations or hand edit the authorizations to restore access. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (NIFI-3929) Allow external key management for EncryptContent processor
[
https://issues.apache.org/jira/browse/NIFI-3929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto reassigned NIFI-3929:
---
Assignee: Andy LoPresto
> Allow external key management for EncryptContent processor
> --
>
> Key: NIFI-3929
> URL: https://issues.apache.org/jira/browse/NIFI-3929
> Project: Apache NiFi
> Issue Type: New Feature
> Components: Extensions
>Reporter: Andy LoPresto
>Assignee: Andy LoPresto
> Labels: encryption, key-management, security
>
> Currently the {{EncryptContent}} processor (and a future {{EncryptAttribute}}
> processor) can only use a static key (or password-derived key) to
> encrypt/decrypt data. Similar to the {{KeyProvider}} interface used in the
> {{EncryptedWriteAheadProvenanceRepository}} that exposes multiple back-end
> implementations ({{StaticKeyProvider}}, {{FileBasedKeyProvider}}, etc.), a
> generic key management controller service is proposed in
> [NIFI-3890|https://issues.apache.org/jira/browse/NIFI-3890], and this
> processor should add support for consuming the CS and using it to dynamically
> access provided keys for encryption/decryption operations.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (NIFI-4133) PublishKafkaRecord_0_10 should allow publishing all messages from a flow file to the same partition
Bryan Bende created NIFI-4133: - Summary: PublishKafkaRecord_0_10 should allow publishing all messages from a flow file to the same partition Key: NIFI-4133 URL: https://issues.apache.org/jira/browse/NIFI-4133 Project: Apache NiFi Issue Type: Improvement Affects Versions: 1.3.0, 1.2.0 Reporter: Bryan Bende Priority: Minor In some use cases it is required to publish all of the messages from a given flow file to the same partition so that they can later be consumer in the same order. Currently the processor provides an option to choose between the default partitioner and a round-robin partitioner, and also allows specifying the name of a field in each record to use as a message key. The default partitioner has the following behavior: 1) If a partition is specified in the record, use it 2) If no partition is specified but a key is present choose a partition based on a hash of the key 3) If no partition or key is present choose a partition in a round-robin fashion Currently we never pass in a partition to the Kafka record that is created, so we always fall into #2 or #3, and the message key is really meant to be unique per-event so we shouldn't be relying on every message using the same message key. We should add an option to the processor like "Partition per FlowFile" which can be used with the default partitioner, and the NiFi side will pass in the same partition for each message created from the same flow file. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (NIFI-4132) Create EncryptRecord controller service and processor
Andy LoPresto created NIFI-4132:
---
Summary: Create EncryptRecord controller service and processor
Key: NIFI-4132
URL: https://issues.apache.org/jira/browse/NIFI-4132
Project: Apache NiFi
Issue Type: New Feature
Components: Extensions
Affects Versions: 1.3.0
Reporter: Andy LoPresto
Assignee: Andy LoPresto
>From a user:
{quote}
As a dataflow manager, I would love to use a processor to encrypt fields in my
record objects. Essentially, i can plugin a record reader controller service to
"EncryptRecordField", deserialize incoming bytes to internal record objects,
encrypt select fields, then plugin a record writer controller service to
serialize the record objects into a user specified output format.
It would be nice to support pluggable key management. Could either be something
similar to EncryptContent processor config, or to introduce a
KeyManagementControllerService which can interface with various processors when
necessary.
{quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (NIFI-4124) Add a Record API-based PutMongo clone
[ https://issues.apache.org/jira/browse/NIFI-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065042#comment-16065042 ] ASF GitHub Bot commented on NIFI-4124: -- GitHub user MikeThomsen reopened a pull request: https://github.com/apache/nifi/pull/1945 NIFI-4124 Added org.apache.nifi.mongo.PutMongoRecord. https://issues.apache.org/jira/browse/NIFI-4124 You can merge this pull request into a Git repository by running: $ git pull https://github.com/MikeThomsen/nifi NIFI-4124 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/1945.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1945 commit 19653f2784e8dc32312ba1ed204edb99e98dca82 Author: Mike Thomsen Date: 2017-06-26T16:36:51Z NIFI-4124 Added org.apache.nifi.mongo.PutMongoRecord. > Add a Record API-based PutMongo clone > - > > Key: NIFI-4124 > URL: https://issues.apache.org/jira/browse/NIFI-4124 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Mike Thomsen >Priority: Minor > Labels: mongodb, putmongo, records > > A new processor that can use the Record API to put data into Mongo is needed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi pull request #1945: NIFI-4124 Added org.apache.nifi.mongo.PutMongoRecor...
GitHub user MikeThomsen reopened a pull request: https://github.com/apache/nifi/pull/1945 NIFI-4124 Added org.apache.nifi.mongo.PutMongoRecord. https://issues.apache.org/jira/browse/NIFI-4124 You can merge this pull request into a Git repository by running: $ git pull https://github.com/MikeThomsen/nifi NIFI-4124 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi/pull/1945.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1945 commit 19653f2784e8dc32312ba1ed204edb99e98dca82 Author: Mike Thomsen Date: 2017-06-26T16:36:51Z NIFI-4124 Added org.apache.nifi.mongo.PutMongoRecord. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NIFI-4124) Add a Record API-based PutMongo clone
[ https://issues.apache.org/jira/browse/NIFI-4124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16065041#comment-16065041 ] ASF GitHub Bot commented on NIFI-4124: -- Github user MikeThomsen closed the pull request at: https://github.com/apache/nifi/pull/1945 > Add a Record API-based PutMongo clone > - > > Key: NIFI-4124 > URL: https://issues.apache.org/jira/browse/NIFI-4124 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Mike Thomsen >Priority: Minor > Labels: mongodb, putmongo, records > > A new processor that can use the Record API to put data into Mongo is needed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] nifi pull request #1945: NIFI-4124 Added org.apache.nifi.mongo.PutMongoRecor...
Github user MikeThomsen closed the pull request at: https://github.com/apache/nifi/pull/1945 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
