[jira] [Commented] (NIFIREG-132) Various REST API endpoints missing swagger annotations for body parameters.
[
https://issues.apache.org/jira/browse/NIFIREG-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16344655#comment-16344655
]
Daniel Chaffelson commented on NIFIREG-132:
---
Looking good, Python code output available at :
[https://github.com/Chaffelson/nipyapi/blob/master/nipyapi/registry/apis/bucket_flows_api.py]
> Various REST API endpoints missing swagger annotations for body parameters.
> ---
>
> Key: NIFIREG-132
> URL: https://issues.apache.org/jira/browse/NIFIREG-132
> Project: NiFi Registry
> Issue Type: Bug
>Affects Versions: 0.1.0
>Reporter: Kevin Doran
>Assignee: Kevin Doran
>Priority: Major
> Fix For: 0.2.0
>
>
> The following endpoints are missing the swagger {{@ApiParam}} annotation for
> the body parameter, which creates incorrect documentation/spec in the
> {{swagger.json}} file in the build output:
> * create flow
> * update flow
> * create flow version
> Thanks to [~chaffelson] for help identifying and testing this issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] nifi-registry issue #89: NIFIREG-120 Basic Docker Image Support
Github user Chaffelson commented on the issue: https://github.com/apache/nifi-registry/pull/89 Hi @abinet that is an excellent point. I did not include it originally because I do not have the test harness to ensure that I did it correctly, but I have spoken with @kevdoran and I believe he is set up to test it, so I have now committed what I believe should be a working version with the security options for review. I have also included the 'upstream' improvements to the NiFi Docker image which allow you to pass in a host & port via environment variables on startup. This facilitates running multiple containers on the same machine during testing and development. ---
[jira] [Commented] (NIFIREG-120) Basic Docker Image
[ https://issues.apache.org/jira/browse/NIFIREG-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16344852#comment-16344852 ] ASF GitHub Bot commented on NIFIREG-120: Github user Chaffelson commented on the issue: https://github.com/apache/nifi-registry/pull/89 Hi @abinet that is an excellent point. I did not include it originally because I do not have the test harness to ensure that I did it correctly, but I have spoken with @kevdoran and I believe he is set up to test it, so I have now committed what I believe should be a working version with the security options for review. I have also included the 'upstream' improvements to the NiFi Docker image which allow you to pass in a host & port via environment variables on startup. This facilitates running multiple containers on the same machine during testing and development. > Basic Docker Image > -- > > Key: NIFIREG-120 > URL: https://issues.apache.org/jira/browse/NIFIREG-120 > Project: NiFi Registry > Issue Type: Improvement >Affects Versions: 0.1.0 >Reporter: Daniel Chaffelson >Priority: Minor > Fix For: 0.2.0 > > > It would be convenient if NiFi Registry had an integrated Docker image ready > for uploading to Dockerhub, similar to the main NiFi Project, for ease of > integration testing. > This could probably be ported, with some changes, from the same approach used > in the main NiFi project for continuity. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi pull request #2443: NIFI-4827 Added support for reading queries from th...
Github user MikeThomsen commented on a diff in the pull request: https://github.com/apache/nifi/pull/2443#discussion_r164708858 --- Diff: nifi-nar-bundles/nifi-mongodb-bundle/nifi-mongodb-processors/test-flows/NIFI_4827.xml --- @@ -0,0 +1,635 @@ + --- End diff -- If not there, it should be some place that is owned by the NiFi team so it can easily survive us if the infamous "hit by a bus" scenario happens. ---
[jira] [Commented] (NIFI-4827) Make GetMongo able to use flowfiles for queries
[ https://issues.apache.org/jira/browse/NIFI-4827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16344883#comment-16344883 ] ASF GitHub Bot commented on NIFI-4827: -- Github user MikeThomsen commented on a diff in the pull request: https://github.com/apache/nifi/pull/2443#discussion_r164708858 --- Diff: nifi-nar-bundles/nifi-mongodb-bundle/nifi-mongodb-processors/test-flows/NIFI_4827.xml --- @@ -0,0 +1,635 @@ + --- End diff -- If not there, it should be some place that is owned by the NiFi team so it can easily survive us if the infamous "hit by a bus" scenario happens. > Make GetMongo able to use flowfiles for queries > --- > > Key: NIFI-4827 > URL: https://issues.apache.org/jira/browse/NIFI-4827 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Mike Thomsen >Assignee: Mike Thomsen >Priority: Minor > > GetMongo should be able to retrieve a valid query from the flowfile content > or allow the incoming flowfile to provide attributes to power EL statements > in the Query configuration field. Allowing the body to be used would allow > GetMongo to be used in a much more generic way. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi pull request #2443: NIFI-4827 Added support for reading queries from th...
Github user MikeThomsen commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2443#discussion_r164711784
--- Diff:
nifi-nar-bundles/nifi-mongodb-bundle/nifi-mongodb-processors/src/main/java/org/apache/nifi/processors/mongodb/GetMongo.java
---
@@ -89,6 +99,17 @@ public ValidationResult validate(final String subject,
final String value, final
.expressionLanguageSupported(true)
.addValidator(DOCUMENT_VALIDATOR)
.build();
+
+static final AllowableValue LOC_BODY = new AllowableValue("body",
"Body");
+static final AllowableValue LOC_PARAM = new AllowableValue("param",
"Query Parameter");
+static final PropertyDescriptor QUERY_LOC = new
PropertyDescriptor.Builder()
--- End diff --
Actually, I think allowing a blank field was the wrong decision because it
is not a valid query w/ MongoDB. So I'll make that change.
---
[jira] [Commented] (NIFI-4827) Make GetMongo able to use flowfiles for queries
[
https://issues.apache.org/jira/browse/NIFI-4827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16344903#comment-16344903
]
ASF GitHub Bot commented on NIFI-4827:
--
Github user MikeThomsen commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2443#discussion_r164711784
--- Diff:
nifi-nar-bundles/nifi-mongodb-bundle/nifi-mongodb-processors/src/main/java/org/apache/nifi/processors/mongodb/GetMongo.java
---
@@ -89,6 +99,17 @@ public ValidationResult validate(final String subject,
final String value, final
.expressionLanguageSupported(true)
.addValidator(DOCUMENT_VALIDATOR)
.build();
+
+static final AllowableValue LOC_BODY = new AllowableValue("body",
"Body");
+static final AllowableValue LOC_PARAM = new AllowableValue("param",
"Query Parameter");
+static final PropertyDescriptor QUERY_LOC = new
PropertyDescriptor.Builder()
--- End diff --
Actually, I think allowing a blank field was the wrong decision because it
is not a valid query w/ MongoDB. So I'll make that change.
> Make GetMongo able to use flowfiles for queries
> ---
>
> Key: NIFI-4827
> URL: https://issues.apache.org/jira/browse/NIFI-4827
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Mike Thomsen
>Assignee: Mike Thomsen
>Priority: Minor
>
> GetMongo should be able to retrieve a valid query from the flowfile content
> or allow the incoming flowfile to provide attributes to power EL statements
> in the Query configuration field. Allowing the body to be used would allow
> GetMongo to be used in a much more generic way.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] nifi pull request #2443: NIFI-4827 Added support for reading queries from th...
Github user mattyb149 commented on a diff in the pull request: https://github.com/apache/nifi/pull/2443#discussion_r164713456 --- Diff: nifi-nar-bundles/nifi-mongodb-bundle/nifi-mongodb-processors/test-flows/NIFI_4827.xml --- @@ -0,0 +1,635 @@ + --- End diff -- Agreed, I often make the Gist available for the reviewer, then once merged, the template could be added to the Wiki of sample templates for all to have ---
[jira] [Commented] (NIFI-4827) Make GetMongo able to use flowfiles for queries
[ https://issues.apache.org/jira/browse/NIFI-4827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16344908#comment-16344908 ] ASF GitHub Bot commented on NIFI-4827: -- Github user mattyb149 commented on a diff in the pull request: https://github.com/apache/nifi/pull/2443#discussion_r164713456 --- Diff: nifi-nar-bundles/nifi-mongodb-bundle/nifi-mongodb-processors/test-flows/NIFI_4827.xml --- @@ -0,0 +1,635 @@ + --- End diff -- Agreed, I often make the Gist available for the reviewer, then once merged, the template could be added to the Wiki of sample templates for all to have > Make GetMongo able to use flowfiles for queries > --- > > Key: NIFI-4827 > URL: https://issues.apache.org/jira/browse/NIFI-4827 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Mike Thomsen >Assignee: Mike Thomsen >Priority: Minor > > GetMongo should be able to retrieve a valid query from the flowfile content > or allow the incoming flowfile to provide attributes to power EL statements > in the Query configuration field. Allowing the body to be used would allow > GetMongo to be used in a much more generic way. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi pull request #2443: NIFI-4827 Added support for reading queries from th...
Github user MikeThomsen commented on a diff in the pull request: https://github.com/apache/nifi/pull/2443#discussion_r164718633 --- Diff: nifi-nar-bundles/nifi-mongodb-bundle/nifi-mongodb-processors/test-flows/NIFI_4827.xml --- @@ -0,0 +1,635 @@ + --- End diff -- Ok. Removed this for now since it can go on the Wiki. ---
[jira] [Commented] (NIFI-4827) Make GetMongo able to use flowfiles for queries
[ https://issues.apache.org/jira/browse/NIFI-4827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16344944#comment-16344944 ] ASF GitHub Bot commented on NIFI-4827: -- Github user MikeThomsen commented on a diff in the pull request: https://github.com/apache/nifi/pull/2443#discussion_r164718633 --- Diff: nifi-nar-bundles/nifi-mongodb-bundle/nifi-mongodb-processors/test-flows/NIFI_4827.xml --- @@ -0,0 +1,635 @@ + --- End diff -- Ok. Removed this for now since it can go on the Wiki. > Make GetMongo able to use flowfiles for queries > --- > > Key: NIFI-4827 > URL: https://issues.apache.org/jira/browse/NIFI-4827 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Mike Thomsen >Assignee: Mike Thomsen >Priority: Minor > > GetMongo should be able to retrieve a valid query from the flowfile content > or allow the incoming flowfile to provide attributes to power EL statements > in the Query configuration field. Allowing the body to be used would allow > GetMongo to be used in a much more generic way. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi issue #2028: NIFI-3518 Create a Morphlines processor
Github user joewitt commented on the issue: https://github.com/apache/nifi/pull/2028 Bill, Some feedback after reviewing in more detail. 1. There are no unit tests. I can see why they'd be non-portable given it is executing a process but it does seem like a good candidate for an integration-test at least. We should definitely have something. We do have a naming convention for integration tests to execute. 2. The nar is not connected to the nifi-nar-bundles pom 3. The nar is not connected to the nifi-assembly. This is perfectly fine though if you dont want the nar to be available in the build by default but rather something someone opts into. I'm ok either way just pointing this out. 4. The L&N updates within the nar are a good start but are incomplete with regard to the totality of the jars present within the nar. 5. The L&N updates in the nar will also need to be validated to see if any need to be carried forward into the nifi-assembly nar. 6. There are unused imports which cause checkstyle/rat failures which is why travis failed on all builds. 7. I'm not an expert on morphlines but it seems like it could be used to do dangerous things on the filesystem. We have a RestrictedComponent annotation for this purpose so it is probably best to add that to the processor. 8. The processor name for a 'users point of view' should probably be 'ExecuteMorphline' 9. You'll probably want to provide some documentation/additional documentation as many other processors do helping the user (and reviewer to evaluate). 10. Can you update to latest nifi version which is 1.6.0-SNAPSHOT in your next commit. Not a big deal as I can do that easily enough but it helps. This looks like a lot but for the L&N we have tons of examples. The rest are pretty straightforward to sort out. Let me know if you plan to tackle these. Thanks ---
[jira] [Commented] (NIFI-3518) Create a Morphlines processor
[ https://issues.apache.org/jira/browse/NIFI-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16345052#comment-16345052 ] ASF GitHub Bot commented on NIFI-3518: -- Github user joewitt commented on the issue: https://github.com/apache/nifi/pull/2028 Bill, Some feedback after reviewing in more detail. 1. There are no unit tests. I can see why they'd be non-portable given it is executing a process but it does seem like a good candidate for an integration-test at least. We should definitely have something. We do have a naming convention for integration tests to execute. 2. The nar is not connected to the nifi-nar-bundles pom 3. The nar is not connected to the nifi-assembly. This is perfectly fine though if you dont want the nar to be available in the build by default but rather something someone opts into. I'm ok either way just pointing this out. 4. The L&N updates within the nar are a good start but are incomplete with regard to the totality of the jars present within the nar. 5. The L&N updates in the nar will also need to be validated to see if any need to be carried forward into the nifi-assembly nar. 6. There are unused imports which cause checkstyle/rat failures which is why travis failed on all builds. 7. I'm not an expert on morphlines but it seems like it could be used to do dangerous things on the filesystem. We have a RestrictedComponent annotation for this purpose so it is probably best to add that to the processor. 8. The processor name for a 'users point of view' should probably be 'ExecuteMorphline' 9. You'll probably want to provide some documentation/additional documentation as many other processors do helping the user (and reviewer to evaluate). 10. Can you update to latest nifi version which is 1.6.0-SNAPSHOT in your next commit. Not a big deal as I can do that easily enough but it helps. This looks like a lot but for the L&N we have tons of examples. The rest are pretty straightforward to sort out. Let me know if you plan to tackle these. Thanks > Create a Morphlines processor > - > > Key: NIFI-3518 > URL: https://issues.apache.org/jira/browse/NIFI-3518 > Project: Apache NiFi > Issue Type: New Feature >Reporter: William Nouet >Priority: Minor > > Create a dedicate processor to run Morphlines transformations > (http://kitesdk.org/docs/1.1.0/morphlines/morphlines-reference-guide.html) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFI-3518) Create a Morphlines processor
[ https://issues.apache.org/jira/browse/NIFI-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Witt updated NIFI-3518: -- Attachment: NIFI-3518-versionupdates.patch > Create a Morphlines processor > - > > Key: NIFI-3518 > URL: https://issues.apache.org/jira/browse/NIFI-3518 > Project: Apache NiFi > Issue Type: New Feature >Reporter: William Nouet >Priority: Minor > Attachments: NIFI-3518-versionupdates.patch > > > Create a dedicate processor to run Morphlines transformations > (http://kitesdk.org/docs/1.1.0/morphlines/morphlines-reference-guide.html) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFIREG-132) Various REST API endpoints missing swagger annotations for body parameters.
[
https://issues.apache.org/jira/browse/NIFIREG-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16345058#comment-16345058
]
Kevin Doran commented on NIFIREG-132:
-
Thanks for testing [~chaffelson]. I've added a commit to GitHub PR #95:
https://github.com/apache/nifi-registry/pull/95
> Various REST API endpoints missing swagger annotations for body parameters.
> ---
>
> Key: NIFIREG-132
> URL: https://issues.apache.org/jira/browse/NIFIREG-132
> Project: NiFi Registry
> Issue Type: Bug
>Affects Versions: 0.1.0
>Reporter: Kevin Doran
>Assignee: Kevin Doran
>Priority: Major
> Fix For: 0.2.0
>
>
> The following endpoints are missing the swagger {{@ApiParam}} annotation for
> the body parameter, which creates incorrect documentation/spec in the
> {{swagger.json}} file in the build output:
> * create flow
> * update flow
> * create flow version
> Thanks to [~chaffelson] for help identifying and testing this issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] nifi issue #2028: NIFI-3518 Create a Morphlines processor
Github user joewitt commented on the issue: https://github.com/apache/nifi/pull/2028 i added a file to the JIRA which is a patch you can apply for the simple pom updates for version ---
[jira] [Commented] (NIFI-3518) Create a Morphlines processor
[ https://issues.apache.org/jira/browse/NIFI-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16345060#comment-16345060 ] ASF GitHub Bot commented on NIFI-3518: -- Github user joewitt commented on the issue: https://github.com/apache/nifi/pull/2028 i added a file to the JIRA which is a patch you can apply for the simple pom updates for version > Create a Morphlines processor > - > > Key: NIFI-3518 > URL: https://issues.apache.org/jira/browse/NIFI-3518 > Project: Apache NiFi > Issue Type: New Feature >Reporter: William Nouet >Priority: Minor > Attachments: NIFI-3518-versionupdates.patch > > > Create a dedicate processor to run Morphlines transformations > (http://kitesdk.org/docs/1.1.0/morphlines/morphlines-reference-guide.html) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFIREG-120) Basic Docker Image
[ https://issues.apache.org/jira/browse/NIFIREG-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16345088#comment-16345088 ] ASF GitHub Bot commented on NIFIREG-120: Github user kevdoran commented on the issue: https://github.com/apache/nifi-registry/pull/89 Thanks @abinet and @Chaffelson. Will review. @apiri and @bbende, I looked into the comment above about the jdk and the error log @Chaffelson provided. It looks like a requirement for jdk/javac got introduced due to a Java language in a DB migration script: [V1.3__DropBucketItemNameUniqueness.sql#L16](https://github.com/apache/nifi-registry/blob/master/nifi-registry-framework/src/main/resources/db/migration/V1.3__DropBucketItemNameUniqueness.sql#L16). This script gets compiled and executed at runtime during app startup in order to initialize (if necessary) the embedded H2 database. Not sure what we want to do about that, if anything, just mentioning it. > Basic Docker Image > -- > > Key: NIFIREG-120 > URL: https://issues.apache.org/jira/browse/NIFIREG-120 > Project: NiFi Registry > Issue Type: Improvement >Affects Versions: 0.1.0 >Reporter: Daniel Chaffelson >Priority: Minor > Fix For: 0.2.0 > > > It would be convenient if NiFi Registry had an integrated Docker image ready > for uploading to Dockerhub, similar to the main NiFi Project, for ease of > integration testing. > This could probably be ported, with some changes, from the same approach used > in the main NiFi project for continuity. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi-registry issue #89: NIFIREG-120 Basic Docker Image Support
Github user kevdoran commented on the issue: https://github.com/apache/nifi-registry/pull/89 Thanks @abinet and @Chaffelson. Will review. @apiri and @bbende, I looked into the comment above about the jdk and the error log @Chaffelson provided. It looks like a requirement for jdk/javac got introduced due to a Java language in a DB migration script: [V1.3__DropBucketItemNameUniqueness.sql#L16](https://github.com/apache/nifi-registry/blob/master/nifi-registry-framework/src/main/resources/db/migration/V1.3__DropBucketItemNameUniqueness.sql#L16). This script gets compiled and executed at runtime during app startup in order to initialize (if necessary) the embedded H2 database. Not sure what we want to do about that, if anything, just mentioning it. ---
[jira] [Created] (MINIFICPP-386) Boostrap script should allow for alternative installation directories when building packages
marco polo created MINIFICPP-386: Summary: Boostrap script should allow for alternative installation directories when building packages Key: MINIFICPP-386 URL: https://issues.apache.org/jira/browse/MINIFICPP-386 Project: NiFi MiNiFi C++ Issue Type: Improvement Reporter: marco polo -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFIREG-120) Basic Docker Image
[ https://issues.apache.org/jira/browse/NIFIREG-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16345098#comment-16345098 ] Pierre Villard commented on NIFIREG-120: Sorry to jump in because I don't know what would be the effort but, if we can remove the need for a JDK, we should do it IMO. > Basic Docker Image > -- > > Key: NIFIREG-120 > URL: https://issues.apache.org/jira/browse/NIFIREG-120 > Project: NiFi Registry > Issue Type: Improvement >Affects Versions: 0.1.0 >Reporter: Daniel Chaffelson >Priority: Minor > Fix For: 0.2.0 > > > It would be convenient if NiFi Registry had an integrated Docker image ready > for uploading to Dockerhub, similar to the main NiFi Project, for ease of > integration testing. > This could probably be ported, with some changes, from the same approach used > in the main NiFi project for continuity. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (NIFI-4829) MockControllerServiceInitializationContext: Update getControllerServiceName to function properly vs always returning null
Jon Kessler created NIFI-4829:
-
Summary: MockControllerServiceInitializationContext: Update
getControllerServiceName to function properly vs always returning null
Key: NIFI-4829
URL: https://issues.apache.org/jira/browse/NIFI-4829
Project: Apache NiFi
Issue Type: Improvement
Components: Core Framework
Affects Versions: 1.5.0
Reporter: Jon Kessler
Currently this method is hardcoded to return null. When using the TestRunner to
configure and enable controller services, those controller services will have
access to a ControllerServiceLookup object that is aware of all controller
services that have been added to that TestRunner. Rather than returning null,
that method should use the lookup when it is available.
[https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=blob;f=nifi-mock/src/main/java/org/apache/nifi/util/MockControllerServiceInitializationContext.java;hb=HEAD#l54]
Something like:
{code:java}
@Override
public String getControllerServiceName(final String serviceIdentifier) {
return getControllerServiceLookup() != null ?
getControllerServiceLookup().getControllerServiceName(serviceIdentifier) : null;
}{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] nifi-minifi-cpp issue #251: MINIFICPP-384 Ignore flex/bison generated files ...
Github user apiri commented on the issue: https://github.com/apache/nifi-minifi-cpp/pull/251 Looks good here. Verified the make package_source target works as anticipated in a few different scenarios. Will merge. ---
[jira] [Commented] (MINIFICPP-384) CPack needs to ignore flex/bison generated files
[ https://issues.apache.org/jira/browse/MINIFICPP-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16345335#comment-16345335 ] ASF GitHub Bot commented on MINIFICPP-384: -- Github user apiri commented on the issue: https://github.com/apache/nifi-minifi-cpp/pull/251 Looks good here. Verified the make package_source target works as anticipated in a few different scenarios. Will merge. > CPack needs to ignore flex/bison generated files > > > Key: MINIFICPP-384 > URL: https://issues.apache.org/jira/browse/MINIFICPP-384 > Project: NiFi MiNiFi C++ > Issue Type: Bug >Reporter: Andrew Christianson >Assignee: Andrew Christianson >Priority: Major > Fix For: 0.5.0 > > > Lexer/parser generated code is included in src packages. These files need to > be excluded. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi-minifi-cpp pull request #251: MINIFICPP-384 Ignore flex/bison generated...
Github user asfgit closed the pull request at: https://github.com/apache/nifi-minifi-cpp/pull/251 ---
[jira] [Commented] (MINIFICPP-384) CPack needs to ignore flex/bison generated files
[ https://issues.apache.org/jira/browse/MINIFICPP-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16345337#comment-16345337 ] ASF GitHub Bot commented on MINIFICPP-384: -- Github user asfgit closed the pull request at: https://github.com/apache/nifi-minifi-cpp/pull/251 > CPack needs to ignore flex/bison generated files > > > Key: MINIFICPP-384 > URL: https://issues.apache.org/jira/browse/MINIFICPP-384 > Project: NiFi MiNiFi C++ > Issue Type: Bug >Reporter: Andrew Christianson >Assignee: Andrew Christianson >Priority: Major > Fix For: 0.5.0 > > > Lexer/parser generated code is included in src packages. These files need to > be excluded. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (MINIFICPP-384) CPack needs to ignore flex/bison generated files
[ https://issues.apache.org/jira/browse/MINIFICPP-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aldrin Piri resolved MINIFICPP-384. --- Resolution: Fixed > CPack needs to ignore flex/bison generated files > > > Key: MINIFICPP-384 > URL: https://issues.apache.org/jira/browse/MINIFICPP-384 > Project: NiFi MiNiFi C++ > Issue Type: Bug >Reporter: Andrew Christianson >Assignee: Andrew Christianson >Priority: Major > Fix For: 0.5.0 > > > Lexer/parser generated code is included in src packages. These files need to > be excluded. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi-registry pull request #96: NIFIREG-131 Surface auth failure details
GitHub user kevdoran opened a pull request: https://github.com/apache/nifi-registry/pull/96 NIFIREG-131 Surface auth failure details Adds logging of root cause for exceptions passed to AuthenticationEntryPoint. AuthenticationEntryPoint writes exception message to response body. You can merge this pull request into a Git repository by running: $ git pull https://github.com/kevdoran/nifi-registry NIFIREG-131 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi-registry/pull/96.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 #96 commit cd478f5a0cd4a38e4ea67cf115c2a9528bd2bdda Author: Kevin Doran Date: 2018-01-30T16:47:49Z NIFIREG-131 Surface auth failure details Adds logging of root cause for exceptions passed to AuthenticationEntryPoint. AuthenticationEntryPoint writes exception message to response body. ---
[jira] [Commented] (NIFIREG-131) Add logging authentication failure cases
[ https://issues.apache.org/jira/browse/NIFIREG-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16345360#comment-16345360 ] ASF GitHub Bot commented on NIFIREG-131: GitHub user kevdoran opened a pull request: https://github.com/apache/nifi-registry/pull/96 NIFIREG-131 Surface auth failure details Adds logging of root cause for exceptions passed to AuthenticationEntryPoint. AuthenticationEntryPoint writes exception message to response body. You can merge this pull request into a Git repository by running: $ git pull https://github.com/kevdoran/nifi-registry NIFIREG-131 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/nifi-registry/pull/96.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 #96 commit cd478f5a0cd4a38e4ea67cf115c2a9528bd2bdda Author: Kevin Doran Date: 2018-01-30T16:47:49Z NIFIREG-131 Surface auth failure details Adds logging of root cause for exceptions passed to AuthenticationEntryPoint. AuthenticationEntryPoint writes exception message to response body. > Add logging authentication failure cases > > > Key: NIFIREG-131 > URL: https://issues.apache.org/jira/browse/NIFIREG-131 > Project: NiFi Registry > Issue Type: Improvement >Affects Versions: 0.1.0 >Reporter: Kevin Doran >Assignee: Kevin Doran >Priority: Minor > Fix For: 0.2.0 > > > The handling for unauthenticated requests made to a secured Registry instance > swallows authentication exceptions with a vague error message: > "AuthenticationEntryPoint invoked as no user identity credentials were found > in the request." and an HTTP 401 response is returned with no body to aide in > client troubleshooting. > We should add more useful troubleshooting information (including the root > cause) to the logs and some guidance information for the client to the > response body. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi-registry issue #96: NIFIREG-131 Surface auth failure details
Github user kevdoran commented on the issue: https://github.com/apache/nifi-registry/pull/96 This change results in the following responses when testing a composite file+ldap authorizer and accessing and endpoint that requires authentication: --- _No credentials:_ ``` HTTP/1.1 401 Unauthorized ... An Authentication object was not found in the SecurityContext. Contact the system administrator. ``` _Bad credentials:_ ``` HTTP/1.1 401 Unauthorized ... Unable to validate the access token. Contact the system administrator. ``` _Untrusted Proxy:_ ``` HTTP/1.1 403 Forbidden ... Untrusted proxy [CN=user1, OU=nifi]. Contact the system administrator. ``` --- Logging for the root cause exception has also been added to the AuthenticationEntryPoint bean. ---
[jira] [Commented] (NIFIREG-131) Add logging authentication failure cases
[ https://issues.apache.org/jira/browse/NIFIREG-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16345382#comment-16345382 ] ASF GitHub Bot commented on NIFIREG-131: Github user kevdoran commented on the issue: https://github.com/apache/nifi-registry/pull/96 This change results in the following responses when testing a composite file+ldap authorizer and accessing and endpoint that requires authentication: --- _No credentials:_ ``` HTTP/1.1 401 Unauthorized ... An Authentication object was not found in the SecurityContext. Contact the system administrator. ``` _Bad credentials:_ ``` HTTP/1.1 401 Unauthorized ... Unable to validate the access token. Contact the system administrator. ``` _Untrusted Proxy:_ ``` HTTP/1.1 403 Forbidden ... Untrusted proxy [CN=user1, OU=nifi]. Contact the system administrator. ``` --- Logging for the root cause exception has also been added to the AuthenticationEntryPoint bean. > Add logging authentication failure cases > > > Key: NIFIREG-131 > URL: https://issues.apache.org/jira/browse/NIFIREG-131 > Project: NiFi Registry > Issue Type: Improvement >Affects Versions: 0.1.0 >Reporter: Kevin Doran >Assignee: Kevin Doran >Priority: Minor > Fix For: 0.2.0 > > > The handling for unauthenticated requests made to a secured Registry instance > swallows authentication exceptions with a vague error message: > "AuthenticationEntryPoint invoked as no user identity credentials were found > in the request." and an HTTP 401 response is returned with no body to aide in > client troubleshooting. > We should add more useful troubleshooting information (including the root > cause) to the logs and some guidance information for the client to the > response body. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (NIFI-4830) Blob not being read properly from Database to Avro
Israel Varea created NIFI-4830:
--
Summary: Blob not being read properly from Database to Avro
Key: NIFI-4830
URL: https://issues.apache.org/jira/browse/NIFI-4830
Project: Apache NiFi
Issue Type: Bug
Reporter: Israel Varea
When using QueryDatabaseTable or any other component using JdbcCommon.java, the
Blob column of the database is not fetched correctly to the Avro ByteBuffer.
Instead of fetching whole file, only first bytes which are different to zero
are added. Then, the rest of the bytes remain with zero value.
Specifically, this code in JdbcCommon.java should be fixed:
{code:java}
if (javaSqlType == BLOB) {
Blob blob = rs.getBlob(i);
if (blob != null) {
long numChars = blob.length();
byte[] buffer = new byte[(int) numChars];
InputStream is = blob.getBinaryStream();
int index = 0;
int c = is.read();
while (c > 0) {
buffer[index++] = (byte) c;
c = is.read();
}
ByteBuffer bb = ByteBuffer.wrap(buffer);
rec.put(i - 1, bb);
blob.free();
} else {
rec.put(i - 1, null);
}
continue;
}
{code}
Notice the while statement.
The whole block should be replaced for something like
{code:java}
if (javaSqlType == BLOB) {
Blob blob = rs.getBlob(i);
if (blob != null) {
long blobLength = blob.length();
byte[] blobAsBytes = blob.getBytes(1, blobLength);
ByteBuffer bb = ByteBuffer.wrap(blobAsBytes);
rec.put(i - 1, bb);
blob.free();
} else {
rec.put(i - 1, null);
}
continue;
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (NIFI-4830) Blob not being read properly from Database to Avro
[
https://issues.apache.org/jira/browse/NIFI-4830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Israel Varea updated NIFI-4830:
---
Description:
When using QueryDatabaseTable or any other component using JdbcCommon.java, the
Blob column of the database is not fetched correctly to the Avro ByteBuffer.
Instead of fetching whole file, only first bytes which are different to zero
are added. Then, the rest of the bytes remain with zero value.
Specifically, this code in JdbcCommon.java should be fixed:
{code:java}
if (javaSqlType == BLOB) {
Blob blob = rs.getBlob(i);
if (blob != null) {
long numChars = blob.length();
byte[] buffer = new byte[(int) numChars];
InputStream is = blob.getBinaryStream();
int index = 0;
int c = is.read();
while (c > 0) {
buffer[index++] = (byte) c;
c = is.read();
}
ByteBuffer bb = ByteBuffer.wrap(buffer);
rec.put(i - 1, bb);
blob.free();
} else {
rec.put(i - 1, null);
}
continue;
}
{code}
Notice the while statement.
The whole block should be replaced for something like
{code:java}
if (javaSqlType == BLOB) {
Blob blob = rs.getBlob(i);
if (blob != null) {
long blobLength = blob.length();
byte[] blobAsBytes = blob.getBytes(1, blobLength);
ByteBuffer bb = ByteBuffer.wrap(blobAsBytes);
rec.put(i - 1, bb);
blob.free();
} else {
rec.put(i - 1, null);
}
continue;
}
{code}
Not checked yet though.
was:
When using QueryDatabaseTable or any other component using JdbcCommon.java, the
Blob column of the database is not fetched correctly to the Avro ByteBuffer.
Instead of fetching whole file, only first bytes which are different to zero
are added. Then, the rest of the bytes remain with zero value.
Specifically, this code in JdbcCommon.java should be fixed:
{code:java}
if (javaSqlType == BLOB) {
Blob blob = rs.getBlob(i);
if (blob != null) {
long numChars = blob.length();
byte[] buffer = new byte[(int) numChars];
InputStream is = blob.getBinaryStream();
int index = 0;
int c = is.read();
while (c > 0) {
buffer[index++] = (byte) c;
c = is.read();
}
ByteBuffer bb = ByteBuffer.wrap(buffer);
rec.put(i - 1, bb);
blob.free();
} else {
rec.put(i - 1, null);
}
continue;
}
{code}
Notice the while statement.
The whole block should be replaced for something like
{code:java}
if (javaSqlType == BLOB) {
Blob blob = rs.getBlob(i);
if (blob != null) {
long blobLength = blob.length();
byte[] blobAsBytes = blob.getBytes(1, blobLength);
ByteBuffer bb = ByteBuffer.wrap(blobAsBytes);
rec.put(i - 1, bb);
blob.free();
} else {
rec.put(i - 1, null);
}
continue;
}
{code}
> Blob not being read properly from Database to Avro
> --
>
> Key: NIFI-4830
> URL: https://issues.apache.org/jira/browse/NIFI-4830
> Project: Apache NiFi
> Issue Type: Bug
>Reporter: Israel Varea
>Priority: Major
>
> When using QueryDatabaseTable or any other component using JdbcCommon.java,
> the Blob column of the database is not fetched correctly to the Avro
> ByteBuffer. Instead of fetching whole file, only first bytes which are
> different to zero are added. Then, the rest of the bytes re
[GitHub] nifi-registry issue #96: NIFIREG-131 Surface auth failure details
Github user bbende commented on the issue: https://github.com/apache/nifi-registry/pull/96 Reviewing... ---
[GitHub] nifi-registry issue #96: NIFIREG-131 Surface auth failure details
Github user bbende commented on the issue: https://github.com/apache/nifi-registry/pull/96 +1 Verified I got back the untrusted proxy error on the client side, and also saw it in the logs on registry server side, going to merge, thanks! ---
[jira] [Commented] (NIFIREG-131) Add logging authentication failure cases
[ https://issues.apache.org/jira/browse/NIFIREG-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16345560#comment-16345560 ] ASF GitHub Bot commented on NIFIREG-131: Github user bbende commented on the issue: https://github.com/apache/nifi-registry/pull/96 +1 Verified I got back the untrusted proxy error on the client side, and also saw it in the logs on registry server side, going to merge, thanks! > Add logging authentication failure cases > > > Key: NIFIREG-131 > URL: https://issues.apache.org/jira/browse/NIFIREG-131 > Project: NiFi Registry > Issue Type: Improvement >Affects Versions: 0.1.0 >Reporter: Kevin Doran >Assignee: Kevin Doran >Priority: Minor > Fix For: 0.2.0 > > > The handling for unauthenticated requests made to a secured Registry instance > swallows authentication exceptions with a vague error message: > "AuthenticationEntryPoint invoked as no user identity credentials were found > in the request." and an HTTP 401 response is returned with no body to aide in > client troubleshooting. > We should add more useful troubleshooting information (including the root > cause) to the logs and some guidance information for the client to the > response body. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFIREG-131) Add logging authentication failure cases
[ https://issues.apache.org/jira/browse/NIFIREG-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16345563#comment-16345563 ] ASF GitHub Bot commented on NIFIREG-131: Github user asfgit closed the pull request at: https://github.com/apache/nifi-registry/pull/96 > Add logging authentication failure cases > > > Key: NIFIREG-131 > URL: https://issues.apache.org/jira/browse/NIFIREG-131 > Project: NiFi Registry > Issue Type: Improvement >Affects Versions: 0.1.0 >Reporter: Kevin Doran >Assignee: Kevin Doran >Priority: Minor > Fix For: 0.2.0 > > > The handling for unauthenticated requests made to a secured Registry instance > swallows authentication exceptions with a vague error message: > "AuthenticationEntryPoint invoked as no user identity credentials were found > in the request." and an HTTP 401 response is returned with no body to aide in > client troubleshooting. > We should add more useful troubleshooting information (including the root > cause) to the logs and some guidance information for the client to the > response body. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi-registry pull request #96: NIFIREG-131 Surface auth failure details
Github user asfgit closed the pull request at: https://github.com/apache/nifi-registry/pull/96 ---
[jira] [Commented] (NIFIREG-131) Add logging authentication failure cases
[ https://issues.apache.org/jira/browse/NIFIREG-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16345544#comment-16345544 ] ASF GitHub Bot commented on NIFIREG-131: Github user bbende commented on the issue: https://github.com/apache/nifi-registry/pull/96 Reviewing... > Add logging authentication failure cases > > > Key: NIFIREG-131 > URL: https://issues.apache.org/jira/browse/NIFIREG-131 > Project: NiFi Registry > Issue Type: Improvement >Affects Versions: 0.1.0 >Reporter: Kevin Doran >Assignee: Kevin Doran >Priority: Minor > Fix For: 0.2.0 > > > The handling for unauthenticated requests made to a secured Registry instance > swallows authentication exceptions with a vague error message: > "AuthenticationEntryPoint invoked as no user identity credentials were found > in the request." and an HTTP 401 response is returned with no body to aide in > client troubleshooting. > We should add more useful troubleshooting information (including the root > cause) to the logs and some guidance information for the client to the > response body. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (NIFIREG-131) Add logging authentication failure cases
[ https://issues.apache.org/jira/browse/NIFIREG-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Bende resolved NIFIREG-131. - Resolution: Fixed > Add logging authentication failure cases > > > Key: NIFIREG-131 > URL: https://issues.apache.org/jira/browse/NIFIREG-131 > Project: NiFi Registry > Issue Type: Improvement >Affects Versions: 0.1.0 >Reporter: Kevin Doran >Assignee: Kevin Doran >Priority: Minor > Fix For: 0.2.0 > > > The handling for unauthenticated requests made to a secured Registry instance > swallows authentication exceptions with a vague error message: > "AuthenticationEntryPoint invoked as no user identity credentials were found > in the request." and an HTTP 401 response is returned with no body to aide in > client troubleshooting. > We should add more useful troubleshooting information (including the root > cause) to the logs and some guidance information for the client to the > response body. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi-registry issue #95: NIFIREG-128 NIFIREG-129 NIFIREG-132 Swagger Fixes
Github user bbende commented on the issue: https://github.com/apache/nifi-registry/pull/95 +1 Looks good, will merge ---
[jira] [Commented] (NIFIREG-128) Swagger spec missing body param for create/update bucket
[
https://issues.apache.org/jira/browse/NIFIREG-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16345570#comment-16345570
]
ASF GitHub Bot commented on NIFIREG-128:
Github user bbende commented on the issue:
https://github.com/apache/nifi-registry/pull/95
+1 Looks good, will merge
> Swagger spec missing body param for create/update bucket
>
>
> Key: NIFIREG-128
> URL: https://issues.apache.org/jira/browse/NIFIREG-128
> Project: NiFi Registry
> Issue Type: Bug
>Affects Versions: 0.1.0
>Reporter: Daniel Chaffelson
>Assignee: Kevin Doran
>Priority: Major
> Fix For: 0.2.0
>
>
> The swagger definition doesn't allow the create_bucket call to specify a
> name, which is required to create a bucket
>
> {code:java}
> "/buckets" : {
> "post" : {
> "tags" : [ "buckets" ],
> "summary" : "Creates a bucket",
> "description" : "",
> "operationId" : "createBucket",
> "consumes" : [ "application/json" ],
> "produces" : [ "application/json" ],
> "responses" : {
> "200" : {
> "description" : "successful operation",
> "schema" : {
> "$ref" : "#/definitions/bucket"
> }
> },
> "400" : {
> "description" : "NiFi Registry was unable to complete the request because it
> was invalid. The request should not be retried without modification."
> },
> "401" : {
> "description" : "Client could not be authenticated."
> },
> "403" : {
> "description" : "Client is not authorized to make this request."
> }
> }
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] nifi-registry pull request #95: NIFIREG-128 NIFIREG-129 NIFIREG-132 Swagger ...
Github user asfgit closed the pull request at: https://github.com/apache/nifi-registry/pull/95 ---
[jira] [Commented] (NIFIREG-128) Swagger spec missing body param for create/update bucket
[
https://issues.apache.org/jira/browse/NIFIREG-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16345575#comment-16345575
]
ASF GitHub Bot commented on NIFIREG-128:
Github user asfgit closed the pull request at:
https://github.com/apache/nifi-registry/pull/95
> Swagger spec missing body param for create/update bucket
>
>
> Key: NIFIREG-128
> URL: https://issues.apache.org/jira/browse/NIFIREG-128
> Project: NiFi Registry
> Issue Type: Bug
>Affects Versions: 0.1.0
>Reporter: Daniel Chaffelson
>Assignee: Kevin Doran
>Priority: Major
> Fix For: 0.2.0
>
>
> The swagger definition doesn't allow the create_bucket call to specify a
> name, which is required to create a bucket
>
> {code:java}
> "/buckets" : {
> "post" : {
> "tags" : [ "buckets" ],
> "summary" : "Creates a bucket",
> "description" : "",
> "operationId" : "createBucket",
> "consumes" : [ "application/json" ],
> "produces" : [ "application/json" ],
> "responses" : {
> "200" : {
> "description" : "successful operation",
> "schema" : {
> "$ref" : "#/definitions/bucket"
> }
> },
> "400" : {
> "description" : "NiFi Registry was unable to complete the request because it
> was invalid. The request should not be retried without modification."
> },
> "401" : {
> "description" : "Client could not be authenticated."
> },
> "403" : {
> "description" : "Client is not authorized to make this request."
> }
> }
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (NIFIREG-129) swagger spec missing snapshot_metadata param for bucket_flows_api
[ https://issues.apache.org/jira/browse/NIFIREG-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Bende resolved NIFIREG-129. - Resolution: Fixed > swagger spec missing snapshot_metadata param for bucket_flows_api > - > > Key: NIFIREG-129 > URL: https://issues.apache.org/jira/browse/NIFIREG-129 > Project: NiFi Registry > Issue Type: Bug >Affects Versions: 0.1.0 >Reporter: Daniel Chaffelson >Assignee: Kevin Doran >Priority: Major > Fix For: 0.2.0 > > > When calling methods to retrieve versioned flows from the bucket_flows_api ( > get_flow, get_flow_version, get_latest_flow_version, etc) the spec calls for > a bucket_id and a flow_id, however the endpoint returns the error "Invalid > value for `snapshot_metadata`, must not be `None`" > Presumably there is a parameter missing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (NIFIREG-128) Swagger spec missing body param for create/update bucket
[
https://issues.apache.org/jira/browse/NIFIREG-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Bende resolved NIFIREG-128.
-
Resolution: Fixed
> Swagger spec missing body param for create/update bucket
>
>
> Key: NIFIREG-128
> URL: https://issues.apache.org/jira/browse/NIFIREG-128
> Project: NiFi Registry
> Issue Type: Bug
>Affects Versions: 0.1.0
>Reporter: Daniel Chaffelson
>Assignee: Kevin Doran
>Priority: Major
> Fix For: 0.2.0
>
>
> The swagger definition doesn't allow the create_bucket call to specify a
> name, which is required to create a bucket
>
> {code:java}
> "/buckets" : {
> "post" : {
> "tags" : [ "buckets" ],
> "summary" : "Creates a bucket",
> "description" : "",
> "operationId" : "createBucket",
> "consumes" : [ "application/json" ],
> "produces" : [ "application/json" ],
> "responses" : {
> "200" : {
> "description" : "successful operation",
> "schema" : {
> "$ref" : "#/definitions/bucket"
> }
> },
> "400" : {
> "description" : "NiFi Registry was unable to complete the request because it
> was invalid. The request should not be retried without modification."
> },
> "401" : {
> "description" : "Client could not be authenticated."
> },
> "403" : {
> "description" : "Client is not authorized to make this request."
> }
> }
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (NIFIREG-132) Various REST API endpoints missing swagger annotations for body parameters.
[
https://issues.apache.org/jira/browse/NIFIREG-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Bende resolved NIFIREG-132.
-
Resolution: Fixed
> Various REST API endpoints missing swagger annotations for body parameters.
> ---
>
> Key: NIFIREG-132
> URL: https://issues.apache.org/jira/browse/NIFIREG-132
> Project: NiFi Registry
> Issue Type: Bug
>Affects Versions: 0.1.0
>Reporter: Kevin Doran
>Assignee: Kevin Doran
>Priority: Major
> Fix For: 0.2.0
>
>
> The following endpoints are missing the swagger {{@ApiParam}} annotation for
> the body parameter, which creates incorrect documentation/spec in the
> {{swagger.json}} file in the build output:
> * create flow
> * update flow
> * create flow version
> Thanks to [~chaffelson] for help identifying and testing this issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] nifi-registry pull request #89: NIFIREG-120 Basic Docker Image Support
Github user kevdoran commented on a diff in the pull request: https://github.com/apache/nifi-registry/pull/89#discussion_r164846239 --- Diff: nifi-registry-docker/dockerhub/DockerImage.txt --- @@ -0,0 +1,16 @@ +# 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. + +apache/nifi-registry:0.1.0 --- End diff -- nifi-registry-0.1.0 is already released and master is now at nifi-registry-0.2.0-SNAPSHOT. I think this version should not be 0.1.0. Looking at what NiFi does, this should probably track towards the next version, i.e., `nifi-registry:0.2.0` (or perhaps `nifi-registry:0.2.0-SNAPSHOT`). @apiri do we have a convention for this file? If one needs to publish a dockerhub image for NiFi Registry 0.1.0, that should probably be done by branching from the rel/nifi-registry-0.1.0 tag. Thoughts? ---
[jira] [Commented] (NIFIREG-120) Basic Docker Image
[ https://issues.apache.org/jira/browse/NIFIREG-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16345617#comment-16345617 ] ASF GitHub Bot commented on NIFIREG-120: Github user kevdoran commented on a diff in the pull request: https://github.com/apache/nifi-registry/pull/89#discussion_r164846239 --- Diff: nifi-registry-docker/dockerhub/DockerImage.txt --- @@ -0,0 +1,16 @@ +# 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. + +apache/nifi-registry:0.1.0 --- End diff -- nifi-registry-0.1.0 is already released and master is now at nifi-registry-0.2.0-SNAPSHOT. I think this version should not be 0.1.0. Looking at what NiFi does, this should probably track towards the next version, i.e., `nifi-registry:0.2.0` (or perhaps `nifi-registry:0.2.0-SNAPSHOT`). @apiri do we have a convention for this file? If one needs to publish a dockerhub image for NiFi Registry 0.1.0, that should probably be done by branching from the rel/nifi-registry-0.1.0 tag. Thoughts? > Basic Docker Image > -- > > Key: NIFIREG-120 > URL: https://issues.apache.org/jira/browse/NIFIREG-120 > Project: NiFi Registry > Issue Type: Improvement >Affects Versions: 0.1.0 >Reporter: Daniel Chaffelson >Priority: Minor > Fix For: 0.2.0 > > > It would be convenient if NiFi Registry had an integrated Docker image ready > for uploading to Dockerhub, similar to the main NiFi Project, for ease of > integration testing. > This could probably be ported, with some changes, from the same approach used > in the main NiFi project for continuity. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi-registry pull request #89: NIFIREG-120 Basic Docker Image Support
Github user kevdoran commented on a diff in the pull request: https://github.com/apache/nifi-registry/pull/89#discussion_r164847991 --- Diff: nifi-registry-docker/pom.xml --- @@ -0,0 +1,29 @@ + + +http://maven.apache.org/POM/4.0.0"; + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; + xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd";> + +nifi-registry +org.apache.nifi.registry +0.1.1-SNAPSHOT --- End diff -- This should be version 0.2.0-SNAPSHOT since master was updated. ---
[jira] [Commented] (NIFIREG-120) Basic Docker Image
[ https://issues.apache.org/jira/browse/NIFIREG-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16345624#comment-16345624 ] ASF GitHub Bot commented on NIFIREG-120: Github user kevdoran commented on a diff in the pull request: https://github.com/apache/nifi-registry/pull/89#discussion_r164847991 --- Diff: nifi-registry-docker/pom.xml --- @@ -0,0 +1,29 @@ + + +http://maven.apache.org/POM/4.0.0"; + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; + xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd";> + +nifi-registry +org.apache.nifi.registry +0.1.1-SNAPSHOT --- End diff -- This should be version 0.2.0-SNAPSHOT since master was updated. > Basic Docker Image > -- > > Key: NIFIREG-120 > URL: https://issues.apache.org/jira/browse/NIFIREG-120 > Project: NiFi Registry > Issue Type: Improvement >Affects Versions: 0.1.0 >Reporter: Daniel Chaffelson >Priority: Minor > Fix For: 0.2.0 > > > It would be convenient if NiFi Registry had an integrated Docker image ready > for uploading to Dockerhub, similar to the main NiFi Project, for ease of > integration testing. > This could probably be ported, with some changes, from the same approach used > in the main NiFi project for continuity. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] nifi issue #2443: NIFI-4827 Added support for reading queries from the flowf...
Github user MikeThomsen commented on the issue: https://github.com/apache/nifi/pull/2443 Ok. I just pushed some changes that should fix things with the query location issue. I took your advice on following the SQL approach. Unit tests are there and batter the heck out of it. ---
[jira] [Commented] (NIFI-4827) Make GetMongo able to use flowfiles for queries
[ https://issues.apache.org/jira/browse/NIFI-4827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16345711#comment-16345711 ] ASF GitHub Bot commented on NIFI-4827: -- Github user MikeThomsen commented on the issue: https://github.com/apache/nifi/pull/2443 Ok. I just pushed some changes that should fix things with the query location issue. I took your advice on following the SQL approach. Unit tests are there and batter the heck out of it. > Make GetMongo able to use flowfiles for queries > --- > > Key: NIFI-4827 > URL: https://issues.apache.org/jira/browse/NIFI-4827 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Mike Thomsen >Assignee: Mike Thomsen >Priority: Minor > > GetMongo should be able to retrieve a valid query from the flowfile content > or allow the incoming flowfile to provide attributes to power EL statements > in the Query configuration field. Allowing the body to be used would allow > GetMongo to be used in a much more generic way. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (NIFI-4831) InvokeHTTP Processor overwrites filename attribute when doing a POST
Tyler Bryant created NIFI-4831: -- Summary: InvokeHTTP Processor overwrites filename attribute when doing a POST Key: NIFI-4831 URL: https://issues.apache.org/jira/browse/NIFI-4831 Project: Apache NiFi Issue Type: Bug Reporter: Tyler Bryant The 'filename' attribute gets overwritten when doing a POST in an InvokeHTTP Processor. I can seem to get around it by putting a 'fileName' attribute in before the InvokeHTTP Processor, and then it correctly keeps the 'filename'. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (NIFIREG-133) [Documentation] Explain how variables are captures when versioning a PG
Pierre Villard created NIFIREG-133: -- Summary: [Documentation] Explain how variables are captures when versioning a PG Key: NIFIREG-133 URL: https://issues.apache.org/jira/browse/NIFIREG-133 Project: NiFi Registry Issue Type: Improvement Reporter: Pierre Villard Context: I have a process group PG that contains an embedded process group PG1. I have a variable defined at PG level that is referenced in a PG1's processor. When versioning both PG and PG1 in NiFi Registry, a copy of the variable defined at PG level will be created at PG1 level. Consequently, when importing PG in another environment, the variable needs to be modified at PG1 level because the one created at PG1 level overwrites the one initially defined at PG level. > Would be nice to add this behavior in the documentation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (NIFIREG-133) [Documentation] Explain how variables are captured when versioning a PG
[ https://issues.apache.org/jira/browse/NIFIREG-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFIREG-133: --- Summary: [Documentation] Explain how variables are captured when versioning a PG (was: [Documentation] Explain how variables are captures when versioning a PG) > [Documentation] Explain how variables are captured when versioning a PG > --- > > Key: NIFIREG-133 > URL: https://issues.apache.org/jira/browse/NIFIREG-133 > Project: NiFi Registry > Issue Type: Improvement >Reporter: Pierre Villard >Priority: Minor > > Context: > I have a process group PG that contains an embedded process group PG1. I have > a variable defined at PG level that is referenced in a PG1's processor. When > versioning both PG and PG1 in NiFi Registry, a copy of the variable defined > at PG level will be created at PG1 level. > Consequently, when importing PG in another environment, the variable needs to > be modified at PG1 level because the one created at PG1 level overwrites the > one initially defined at PG level. > > Would be nice to add this behavior in the documentation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-4388) Module path not honored using InvokeScriptedProcessor
[ https://issues.apache.org/jira/browse/NIFI-4388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16346354#comment-16346354 ] Patrice Freydiere commented on NIFI-4388: - >From my understanding of the code, the classpath was only used for "file >based" scripts, and not "inline body script" ? perhaps the solution is to >mention it in documentation or help. Now with Ivy in classpath it helps using >external libraries depending on script language (ie: Grape for groovy) > Module path not honored using InvokeScriptedProcessor > - > > Key: NIFI-4388 > URL: https://issues.apache.org/jira/browse/NIFI-4388 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 1.3.0 >Reporter: Patrice Freydiere >Priority: Major > > When specify modulepath parameter, using groovy scriptedengine, the jars are > not added to classpath. > This is currently not possible to use third party library in scripting -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-4367) InvokedScriptedProcessor does not support scripted processor that extends AbstractProcessor
[ https://issues.apache.org/jira/browse/NIFI-4367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16346350#comment-16346350 ] Patrice Freydiere commented on NIFI-4367: - hi [~mgaido] , ok send me the PR, i'll have a look at it, ASAP . thank's > InvokedScriptedProcessor does not support scripted processor that extends > AbstractProcessor > --- > > Key: NIFI-4367 > URL: https://issues.apache.org/jira/browse/NIFI-4367 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Reporter: Patrice Freydiere >Priority: Major > Labels: InvokeScriptedProcessor, validation > > InvokeScriptedProcessor pass his ValidationContext to the inner script, > validate call > InvokeScriptedProcessor Line 465 :final > Collection instanceResults = instance.validate(context); > > The problem is that the invokedscript pass the ScriptFile PropertyDescriptor > that is validated, if the script derived from the > AbstractConfigurableComponent, (because the AbstractConfigurableComponent > validate all the context properties). > The context should be refined to remove the InvokeScriptedProcessor > Properties. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
