[
https://issues.apache.org/jira/browse/NIFI-5022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16508014#comment-16508014
]
ASF GitHub Bot commented on NIFI-5022:
--------------------------------------
Github user ottobackwards commented on the issue:
https://github.com/apache/nifi/pull/2588
@joewitt
I added the headers because the code was already apache lic. in the
project, I thought that would be the proper thing to do. I ( possibly or
probably wrongly ) thought that if you put the lic. in the project you *should*
lic. the files with headers.
As for taking the library vs. including the code.
I took that code because I was not sure if the library would be updated
quickly enough if there where changes in the AWS library versions in nifi or
other changes required ( such as my need to add support for query parameters ).
Also, there is not a lot of code to work with. @mattyb149 and I talked it out
and I *have* done a pr to the project for a version bump that would allow us to
use the library, but there has been no response to that pr since May 3rd when I
posted it ( as I had feared at the start ).
Currently I *think* the options are ( in no order )
- The PR goes with the code as it is, with a notice to move to the library
if and when it is updated to a comparable version of aws
- I do a proper fork into my github organization with the required version
and publish ( currently I just do bintray and center )
- This PR is shelved until the project takes the PR
Obviously I would prefer not to shelve this.
Thoughts?
Should I remove the headers?
> Create an AWS Gateway Web API version of InvokeHTTP
> ---------------------------------------------------
>
> Key: NIFI-5022
> URL: https://issues.apache.org/jira/browse/NIFI-5022
> Project: Apache NiFi
> Issue Type: New Feature
> Reporter: Otto Fowler
> Assignee: Otto Fowler
> Priority: Major
>
> Currently the AWS processors are lacking support to call AWS Gateway Web Apis.
> Nifi should provide support for calling this apis, including support for all
> the same authentication methods available to the other AWS client processors.
> Since these APIs are web services, their expected use would require an
> interface more like InvokeHTTP however, than the specialized interfaces for
> the other AWS Services.
> What would be required then would be a new AWS Processor that exposed the
> same interface as InvokeHTTP, but backed by the AWS client support ( and of
> course modified to fit the differences between the OK http client and the
> Amazon client ).
> This new processor should be able to pass all the applicable tests available
> in the InvokeHttp test suite.
> The processor should also be factored in such a way as to make it possible
> for the creation of custom processors for specific apis
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
