Re: NiFi PutElasticsearch Processor

[shankhamajumdar]

Hi,

I have added ExtractText processor and there added a new property called
myAttribute with value (.+). Then added AttributesToJSON processor with
Attributes List as myAttribute. As result I am getting the below json
structure.

{"myAttribute":"test elasticsearch"}

But it's not working for multiline content as the json attribute is taking
single line only. To resolve this I to keep the entire content in a single
line. So I have added ReplaceText processor before AttributesToJSON
processor. In the replace text processor I am trying to replace \n to empty
space so that entire content can come in a single line. 

Can you please tell me how to make the entire content in a single line using
ReplaceText? I have used search value as \n and replacement value as ' '.
But this is not working properly.

Please provide some input on this.

Regards,
Shankha



--
View this message in context: 
http://apache-nifi-developer-list.39713.n7.nabble.com/NiFi-PutElasticsearch-Processor-tp14733p14774.html
Sent from the Apache NiFi Developer List mailing list archive at Nabble.com.

Re: Creating a custom DatabaseAdapter

[Oleg Zhurakousky]

Stanislav

Sorry to hear you’re having problems. 
Is ether any way we can look at the code (i.e., via GitHub)? Also, when you say 
you don’t see your DatabaseAdapter is not picked up, do you see any messages in 
the logs?

It is hard to determine the issue without more info, but usually symptoms like 
this point to miss-configuration of some type and are usually very easy to fix, 
once diagnosed. 
Let us know what you can do.

Also, a lot of times i helps to just copy another working bundle, then rename 
the artifact(s), build and make sure you can see it being deployed. Now you can 
modify the code any way you like knowing that at the very least you don’t have 
any configuration issues.

Let us know
Cheers
Oleg
> On Feb 17, 2017, at 5:05 AM, Stanislav  wrote:
> 
> Hi,
> 
> I would like to create a custom 
> org.apache.nifi.processors.standard.db.DatabaseAdapter, is this possible?
> I have tried creating new class that implements the interface and specified 
> the full class name in 
> META-INF\services\org.apache.nifi.processors.standard.db.DatabaseAdapter 
> file, and created a nar.
> But this does not appear to be working, the custom processor i have in that 
> nar are picked-up but the DatabaseAdapter isn`t.
> Any tips on how to make it work?
> 
> Best regards,
> Stanislav.
> 

travis-ci auto cancellation

[Andre]

dev,

Would you mind if I configured the NiFi, MiNiFi and MiNiFI-CPP travis-ci
integration to perform auto-cancellation when new commits are pushed to the
same branch or PR?

This should significantly reduce the number of builds we do per busy days
and offer benefits to the whole community.

Cheers

Query on nifi project deployment

[Deepak Kumar Patel]

Hi Dev Team,

Can you guide me, I want to deploy the nifi project inJBoss/WildFly 10.

Is It possible ?
If possible, can you please share the steps.


Thanks in Advance.

Deepak Patel

Re: Query on nifi project deployment

[Pierre Villard]

Hi,

NiFi is running in its own embedded Jetty server. There is no way, at the
moment, to allow NiFi deployment in other web application server.

Hope this helps,
Pierre


2017-02-17 13:55 GMT+01:00 Deepak Kumar Patel :

> Hi Dev Team,
>
> Can you guide me, I want to deploy the nifi project inJBoss/WildFly 10.
>
> Is It possible ?
> If possible, can you please share the steps.
>
>
> Thanks in Advance.
>
> Deepak Patel
>

Re: Query on nifi project deployment

[Pierre Villard]

Just to add some content here (was trying to find another thread discussing
the same subject... but my search skills are low today...): if you want to
deploy NiFi in a custom web application server, the first place I'd look at
would be the nifi-runtime project and in particular at this place:

https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-runtime/src/main/java/org/apache/nifi/NiFi.java#L147

Not sure if it would require a lot of changes.

Pierre




2017-02-17 14:35 GMT+01:00 Pierre Villard :

> Hi,
>
> NiFi is running in its own embedded Jetty server. There is no way, at the
> moment, to allow NiFi deployment in other web application server.
>
> Hope this helps,
> Pierre
>
>
> 2017-02-17 13:55 GMT+01:00 Deepak Kumar Patel  >:
>
>> Hi Dev Team,
>>
>> Can you guide me, I want to deploy the nifi project inJBoss/WildFly 10.
>>
>> Is It possible ?
>> If possible, can you please share the steps.
>>
>>
>> Thanks in Advance.
>>
>> Deepak Patel
>>
>
>

Creating a custom DatabaseAdapter

[Stanislav]

Hi,

I would like to create a custom 
org.apache.nifi.processors.standard.db.DatabaseAdapter, is this possible?
I have tried creating new class that implements the interface and specified the 
full class name in 
META-INF\services\org.apache.nifi.processors.standard.db.DatabaseAdapter file, 
and created a nar.
But this does not appear to be working, the custom processor i have in that nar 
are picked-up but the DatabaseAdapter isn`t.
Any tips on how to make it work?

Best regards,
Stanislav.

Re: NiFi PutElasticsearch Processor

[Mark Payne]

Shankha,

With Java Regex'es, by default, the dot-character does not match newlines. So 
(.+) will only match
a single line. On Extract Text, you can change the property named "Enable 
DOTALL Mode" to true,
which should allow the .+ to capture all of the text in the FlowFile.

Thanks
-Mark



> On Feb 17, 2017, at 5:18 AM, shankhamajumdar  
> wrote:
> 
> Hi,
> 
> I have added ExtractText processor and there added a new property called
> myAttribute with value (.+). Then added AttributesToJSON processor with
> Attributes List as myAttribute. As result I am getting the below json
> structure.
> 
> {"myAttribute":"test elasticsearch"}
> 
> But it's not working for multiline content as the json attribute is taking
> single line only. To resolve this I to keep the entire content in a single
> line. So I have added ReplaceText processor before AttributesToJSON
> processor. In the replace text processor I am trying to replace \n to empty
> space so that entire content can come in a single line. 
> 
> Can you please tell me how to make the entire content in a single line using
> ReplaceText? I have used search value as \n and replacement value as ' '.
> But this is not working properly.
> 
> Please provide some input on this.
> 
> Regards,
> Shankha
> 
> 
> 
> --
> View this message in context: 
> http://apache-nifi-developer-list.39713.n7.nabble.com/NiFi-PutElasticsearch-Processor-tp14733p14774.html
> Sent from the Apache NiFi Developer List mailing list archive at Nabble.com.

Re: [VOTE] Release Apache NiFi 1.1.2

[Bryan Bende]

+1 (binding) Release this package as nifi-1.1.2


On Thu, Feb 16, 2017 at 10:37 PM, Andy LoPresto  wrote:
> Hello,
>
> I am pleased to be calling this vote for the source release of Apache NiFi
> nifi-1.1.2.
>
> The source zip, including signatures, digests, etc. can be found at:
> https://repository.apache.org/content/repositories/orgapachenifi-1098
>
> The Git tag is nifi-1.1.2-RC1
> The Git commit ID is 51fad01f5daf33716b8b5379c32ee932d91c8c63
> https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=51fad01f5daf33716b8b5379c32ee932d91c8c63
>
> Checksums of nifi-1.1.2-source-release.zip:
> MD5: 31d20a09955fac32d5b4147c497deede
> SHA1: 9f8f2ce00397d990dfb0890f9b1ede70dca4f25e
> SHA256: 0f57b5ae7f5e1d7f1289d779df39f20d70af0ffd92cb01b265beb90b309b747e
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/alopresto.asc
>
> KEYS file available here:
> https://dist.apache.org/repos/dist/release/nifi/KEYS
>
> 2 issues were closed/resolved for this release:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12339600&projectId=12316020
>
> Release note highlights can be found here:
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.1.2
>
> The vote will be open for 96 hours (over holiday weekend).
> Please download the release candidate and evaluate the necessary items
> including checking hashes, signatures, build
> from source, and test.  The please vote:
>
> [ ] +1 Release this package as nifi-1.1.2
> [ ] +0 no opinion
> [ ] -1 Do not release this package because because…
>
> Andy LoPresto
> alopre...@apache.org
> alopresto.apa...@gmail.com
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>

Re: [VOTE] Release Apache NiFi 0.7.2

[Michael Moser]

I'm sad that 0.7.2 does not contain some of the other bug fixes currently
on the 0.x branch.  It doesn't seem like it would have cost very much to
just include them.

+0 (non binding)

-- Mike


On Thu, Feb 16, 2017 at 11:42 PM, Andy LoPresto 
wrote:

> Hello,
>
> I am pleased to be calling this vote for the source release of Apache NiFi
> nifi-0.7.2.
>
> The source zip, including signatures, digests, etc. can be found at:
> https://repository.apache.org/content/repositories/orgapachenifi-1099
>
> The Git tag is nifi-0.7.2-RC1
> The Git commit ID is 831ac6939df7d418cadb336eedb4e09fb97541a1
> https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=
> 831ac6939df7d418cadb336eedb4e09fb97541a1
>
> Checksums of nifi-0.7.2-source-release.zip:
> MD5: efe9ea1cf0698a57a6829fe3829fc136
> SHA1: aee51164af34394c7017dae491b239a88b614865
> SHA256: 8cd02675003fca837ea0092b6225600a4700b905e5214a751ae7ff833263193b
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/alopresto.asc
>
> KEYS file available here:
> https://dist.apache.org/repos/dist/release/nifi/KEYS
>
> 2 issues were closed/resolved for this release:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> version=12339601&projectId=12316020
>
> Release note highlights can be found here:
> https://cwiki.apache.org/confluence/display/NIFI/
> Release+Notes#ReleaseNotes-Version0.7.2
>
> The vote will be open for 96 hours (over holiday weekend).
> Please download the release candidate and evaluate the necessary items
> including checking hashes, signatures, build
> from source, and test.  The please vote:
>
> [ ] +1 Release this package as nifi-0.7.2
> [ ] +0 no opinion
> [ ] -1 Do not release this package because because…
>
> Andy LoPresto
> alopre...@apache.org
> *alopresto.apa...@gmail.com *
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
>

Re: [VOTE] Release Apache NiFi 0.7.2

[Joe Witt]

Mike,

You're absolutely right that there are some good fixes to be included
in an upcoming release.  There is no reason someone couldn't put
together an 0.7.3.

This is just something that we're wanting resolved and have the energy
to push forward and doesn't require additional testing as inclusion of
other items would.

Please by no means see this as a deterrent to progression on an 0.7.3.

Thanks
Joe

On Fri, Feb 17, 2017 at 12:38 PM, Michael Moser  wrote:
> I'm sad that 0.7.2 does not contain some of the other bug fixes currently
> on the 0.x branch.  It doesn't seem like it would have cost very much to
> just include them.
>
> +0 (non binding)
>
> -- Mike
>
>
> On Thu, Feb 16, 2017 at 11:42 PM, Andy LoPresto 
> wrote:
>
>> Hello,
>>
>> I am pleased to be calling this vote for the source release of Apache NiFi
>> nifi-0.7.2.
>>
>> The source zip, including signatures, digests, etc. can be found at:
>> https://repository.apache.org/content/repositories/orgapachenifi-1099
>>
>> The Git tag is nifi-0.7.2-RC1
>> The Git commit ID is 831ac6939df7d418cadb336eedb4e09fb97541a1
>> https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=
>> 831ac6939df7d418cadb336eedb4e09fb97541a1
>>
>> Checksums of nifi-0.7.2-source-release.zip:
>> MD5: efe9ea1cf0698a57a6829fe3829fc136
>> SHA1: aee51164af34394c7017dae491b239a88b614865
>> SHA256: 8cd02675003fca837ea0092b6225600a4700b905e5214a751ae7ff833263193b
>>
>> Release artifacts are signed with the following key:
>> https://people.apache.org/keys/committer/alopresto.asc
>>
>> KEYS file available here:
>> https://dist.apache.org/repos/dist/release/nifi/KEYS
>>
>> 2 issues were closed/resolved for this release:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>> version=12339601&projectId=12316020
>>
>> Release note highlights can be found here:
>> https://cwiki.apache.org/confluence/display/NIFI/
>> Release+Notes#ReleaseNotes-Version0.7.2
>>
>> The vote will be open for 96 hours (over holiday weekend).
>> Please download the release candidate and evaluate the necessary items
>> including checking hashes, signatures, build
>> from source, and test.  The please vote:
>>
>> [ ] +1 Release this package as nifi-0.7.2
>> [ ] +0 no opinion
>> [ ] -1 Do not release this package because because…
>>
>> Andy LoPresto
>> alopre...@apache.org
>> *alopresto.apa...@gmail.com *
>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>>
>>

Re: [VOTE] Release Apache NiFi 1.1.2

[Matt Gilman]

+1 (binding) Release this package as nifi-1.1.2

On Thu, Feb 16, 2017 at 10:37 PM, Andy LoPresto 
wrote:

> Hello,
>
> I am pleased to be calling this vote for the source release of Apache NiFi
> nifi-1.1.2.
>
> The source zip, including signatures, digests, etc. can be found at:
> https://repository.apache.org/content/repositories/orgapachenifi-1098
>
> The Git tag is nifi-1.1.2-RC1
> The Git commit ID is 51fad01f5daf33716b8b5379c32ee932d91c8c63
> https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=
> 51fad01f5daf33716b8b5379c32ee932d91c8c63
>
> Checksums of nifi-1.1.2-source-release.zip:
> MD5: 31d20a09955fac32d5b4147c497deede
> SHA1: 9f8f2ce00397d990dfb0890f9b1ede70dca4f25e
> SHA256: 0f57b5ae7f5e1d7f1289d779df39f20d70af0ffd92cb01b265beb90b309b747e
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/alopresto.asc
>
> KEYS file available here:
> https://dist.apache.org/repos/dist/release/nifi/KEYS
>
> 2 issues were closed/resolved for this release:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> version=12339600&projectId=12316020
>
> Release note highlights can be found here:
> https://cwiki.apache.org/confluence/display/NIFI/
> Release+Notes#ReleaseNotes-Version1.1.2
>
> The vote will be open for 96 hours (over holiday weekend).
> Please download the release candidate and evaluate the necessary items
> including checking hashes, signatures, build
> from source, and test.  The please vote:
>
> [ ] +1 Release this package as nifi-1.1.2
> [ ] +0 no opinion
> [ ] -1 Do not release this package because because…
>
> Andy LoPresto
> alopre...@apache.org
> *alopresto.apa...@gmail.com *
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
>

Re: [VOTE] Release Apache NiFi 0.7.2

[Bryan Bende]

+1 (binding) Release this package as nifi-0.7.2

On Fri, Feb 17, 2017 at 12:55 PM, Joe Witt  wrote:
> Mike,
>
> You're absolutely right that there are some good fixes to be included
> in an upcoming release.  There is no reason someone couldn't put
> together an 0.7.3.
>
> This is just something that we're wanting resolved and have the energy
> to push forward and doesn't require additional testing as inclusion of
> other items would.
>
> Please by no means see this as a deterrent to progression on an 0.7.3.
>
> Thanks
> Joe
>
> On Fri, Feb 17, 2017 at 12:38 PM, Michael Moser  wrote:
>> I'm sad that 0.7.2 does not contain some of the other bug fixes currently
>> on the 0.x branch.  It doesn't seem like it would have cost very much to
>> just include them.
>>
>> +0 (non binding)
>>
>> -- Mike
>>
>>
>> On Thu, Feb 16, 2017 at 11:42 PM, Andy LoPresto 
>> wrote:
>>
>>> Hello,
>>>
>>> I am pleased to be calling this vote for the source release of Apache NiFi
>>> nifi-0.7.2.
>>>
>>> The source zip, including signatures, digests, etc. can be found at:
>>> https://repository.apache.org/content/repositories/orgapachenifi-1099
>>>
>>> The Git tag is nifi-0.7.2-RC1
>>> The Git commit ID is 831ac6939df7d418cadb336eedb4e09fb97541a1
>>> https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=
>>> 831ac6939df7d418cadb336eedb4e09fb97541a1
>>>
>>> Checksums of nifi-0.7.2-source-release.zip:
>>> MD5: efe9ea1cf0698a57a6829fe3829fc136
>>> SHA1: aee51164af34394c7017dae491b239a88b614865
>>> SHA256: 8cd02675003fca837ea0092b6225600a4700b905e5214a751ae7ff833263193b
>>>
>>> Release artifacts are signed with the following key:
>>> https://people.apache.org/keys/committer/alopresto.asc
>>>
>>> KEYS file available here:
>>> https://dist.apache.org/repos/dist/release/nifi/KEYS
>>>
>>> 2 issues were closed/resolved for this release:
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>>> version=12339601&projectId=12316020
>>>
>>> Release note highlights can be found here:
>>> https://cwiki.apache.org/confluence/display/NIFI/
>>> Release+Notes#ReleaseNotes-Version0.7.2
>>>
>>> The vote will be open for 96 hours (over holiday weekend).
>>> Please download the release candidate and evaluate the necessary items
>>> including checking hashes, signatures, build
>>> from source, and test.  The please vote:
>>>
>>> [ ] +1 Release this package as nifi-0.7.2
>>> [ ] +0 no opinion
>>> [ ] -1 Do not release this package because because…
>>>
>>> Andy LoPresto
>>> alopre...@apache.org
>>> *alopresto.apa...@gmail.com *
>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>>>
>>>

Sensitive-value properties

[Russell Bateman]

1. Where are the values of sensitive-value properties stored?
2. How do they work? (if not obvious from #1)
3. Can /flow.xml.g//z/ be copied wholesale or in part to another
   instance of NiFi?

Thanks,

Russ

Re: Sensitive-value properties

[Bryan Bende]

Russell,

Sensitive property values are stored in the flow.xml.gz in encrypted
form. The encryption is based on the value of
nifi.sensitive.props.key= and if you haven't set one there is a
default in the code. If you have the same sensitive properties key in
both instances than you can copy the flow, or if you didn't set one in
both instances which means you have the same. If you had different
keys then one instance wouldn't be able to decrypt the values from the
other instance.

Thanks,

Bryan

On Fri, Feb 17, 2017 at 2:35 PM, Russell Bateman  wrote:
>
> 1. Where are the values of sensitive-value properties stored?
> 2. How do they work? (if not obvious from #1)
> 3. Can /flow.xml.g//z/ be copied wholesale or in part to another
>instance of NiFi?
>
> Thanks,
>
> Russ
>
>
>

Re: Sensitive-value properties

[Joe Witt]

Russ,

The values are stored within the flow.xml.gz and are encrypted.

They are encrypted/decrypted by the core framework outside the control
of any extension code.  Their values are not returned again to the
client side in encrypted form or otherwise.

The flow.xml.gz can be copied to another nifi instance or cluster
provided the same encryption key/algorithm/configuration is used on
that system.  This, however, is less powerful of a porting approach
than the planned registry work that has been recently discussed a good
bit.

Thanks
Joe

On Fri, Feb 17, 2017 at 2:35 PM, Russell Bateman  wrote:
>
> 1. Where are the values of sensitive-value properties stored?
> 2. How do they work? (if not obvious from #1)
> 3. Can /flow.xml.g//z/ be copied wholesale or in part to another
>instance of NiFi?
>
> Thanks,
>
> Russ
>
>
>

Re: [VOTE] Release Apache NiFi 0.7.2

[Matt Gilman]

+1 (binding) Release this package as nifi-0.7.2

On Thu, Feb 16, 2017 at 11:42 PM, Andy LoPresto 
wrote:

> Hello,
>
> I am pleased to be calling this vote for the source release of Apache NiFi
> nifi-0.7.2.
>
> The source zip, including signatures, digests, etc. can be found at:
> https://repository.apache.org/content/repositories/orgapachenifi-1099
>
> The Git tag is nifi-0.7.2-RC1
> The Git commit ID is 831ac6939df7d418cadb336eedb4e09fb97541a1
> https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=
> 831ac6939df7d418cadb336eedb4e09fb97541a1
>
> Checksums of nifi-0.7.2-source-release.zip:
> MD5: efe9ea1cf0698a57a6829fe3829fc136
> SHA1: aee51164af34394c7017dae491b239a88b614865
> SHA256: 8cd02675003fca837ea0092b6225600a4700b905e5214a751ae7ff833263193b
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/alopresto.asc
>
> KEYS file available here:
> https://dist.apache.org/repos/dist/release/nifi/KEYS
>
> 2 issues were closed/resolved for this release:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> version=12339601&projectId=12316020
>
> Release note highlights can be found here:
> https://cwiki.apache.org/confluence/display/NIFI/
> Release+Notes#ReleaseNotes-Version0.7.2
>
> The vote will be open for 96 hours (over holiday weekend).
> Please download the release candidate and evaluate the necessary items
> including checking hashes, signatures, build
> from source, and test.  The please vote:
>
> [ ] +1 Release this package as nifi-0.7.2
> [ ] +0 no opinion
> [ ] -1 Do not release this package because because…
>
> Andy LoPresto
> alopre...@apache.org
> *alopresto.apa...@gmail.com *
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
>

Re: [VOTE] Release Apache NiFi 0.7.2

[Aldrin Piri]

+1, binding

Comments:
* Hashes and signature looks good
* Build and basic flows worked
* 0.7.2-RC1 tag is currently absent on the Apache repository


On Fri, Feb 17, 2017 at 2:51 PM, Matt Gilman 
wrote:

> +1 (binding) Release this package as nifi-0.7.2
>
> On Thu, Feb 16, 2017 at 11:42 PM, Andy LoPresto 
> wrote:
>
> > Hello,
> >
> > I am pleased to be calling this vote for the source release of Apache
> NiFi
> > nifi-0.7.2.
> >
> > The source zip, including signatures, digests, etc. can be found at:
> > https://repository.apache.org/content/repositories/orgapachenifi-1099
> >
> > The Git tag is nifi-0.7.2-RC1
> > The Git commit ID is 831ac6939df7d418cadb336eedb4e09fb97541a1
> > https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=
> > 831ac6939df7d418cadb336eedb4e09fb97541a1
> >
> > Checksums of nifi-0.7.2-source-release.zip:
> > MD5: efe9ea1cf0698a57a6829fe3829fc136
> > SHA1: aee51164af34394c7017dae491b239a88b614865
> > SHA256: 8cd02675003fca837ea0092b6225600a4700b905e5214a751ae7ff833263193b
> >
> > Release artifacts are signed with the following key:
> > https://people.apache.org/keys/committer/alopresto.asc
> >
> > KEYS file available here:
> > https://dist.apache.org/repos/dist/release/nifi/KEYS
> >
> > 2 issues were closed/resolved for this release:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > version=12339601&projectId=12316020
> >
> > Release note highlights can be found here:
> > https://cwiki.apache.org/confluence/display/NIFI/
> > Release+Notes#ReleaseNotes-Version0.7.2
> >
> > The vote will be open for 96 hours (over holiday weekend).
> > Please download the release candidate and evaluate the necessary items
> > including checking hashes, signatures, build
> > from source, and test.  The please vote:
> >
> > [ ] +1 Release this package as nifi-0.7.2
> > [ ] +0 no opinion
> > [ ] -1 Do not release this package because because…
> >
> > Andy LoPresto
> > alopre...@apache.org
> > *alopresto.apa...@gmail.com *
> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >
> >
>

Re: [VOTE] Release Apache NiFi 0.7.2

[Andy LoPresto]

Thanks to Aldrin for pointing out that the tags did not get pushed for some 
reason. They are both present now:

nifi-0.7.2-RC1: 
https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=6435063885ceb447de89683c0a9149f782112785
 


Andy LoPresto
alopre...@apache.org
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Feb 17, 2017, at 12:25 PM, Aldrin Piri  wrote:
> 
> +1, binding
> 
> Comments:
> * Hashes and signature looks good
> * Build and basic flows worked
> * 0.7.2-RC1 tag is currently absent on the Apache repository
> 
> 
> On Fri, Feb 17, 2017 at 2:51 PM, Matt Gilman 
> wrote:
> 
>> +1 (binding) Release this package as nifi-0.7.2
>> 
>> On Thu, Feb 16, 2017 at 11:42 PM, Andy LoPresto 
>> wrote:
>> 
>>> Hello,
>>> 
>>> I am pleased to be calling this vote for the source release of Apache
>> NiFi
>>> nifi-0.7.2.
>>> 
>>> The source zip, including signatures, digests, etc. can be found at:
>>> https://repository.apache.org/content/repositories/orgapachenifi-1099
>>> 
>>> The Git tag is nifi-0.7.2-RC1
>>> The Git commit ID is 831ac6939df7d418cadb336eedb4e09fb97541a1
>>> https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=
>>> 831ac6939df7d418cadb336eedb4e09fb97541a1
>>> 
>>> Checksums of nifi-0.7.2-source-release.zip:
>>> MD5: efe9ea1cf0698a57a6829fe3829fc136
>>> SHA1: aee51164af34394c7017dae491b239a88b614865
>>> SHA256: 8cd02675003fca837ea0092b6225600a4700b905e5214a751ae7ff833263193b
>>> 
>>> Release artifacts are signed with the following key:
>>> https://people.apache.org/keys/committer/alopresto.asc
>>> 
>>> KEYS file available here:
>>> https://dist.apache.org/repos/dist/release/nifi/KEYS
>>> 
>>> 2 issues were closed/resolved for this release:
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>>> version=12339601&projectId=12316020
>>> 
>>> Release note highlights can be found here:
>>> https://cwiki.apache.org/confluence/display/NIFI/
>>> Release+Notes#ReleaseNotes-Version0.7.2
>>> 
>>> The vote will be open for 96 hours (over holiday weekend).
>>> Please download the release candidate and evaluate the necessary items
>>> including checking hashes, signatures, build
>>> from source, and test.  The please vote:
>>> 
>>> [ ] +1 Release this package as nifi-0.7.2
>>> [ ] +0 no opinion
>>> [ ] -1 Do not release this package because because…
>>> 
>>> Andy LoPresto
>>> alopre...@apache.org
>>> *alopresto.apa...@gmail.com *
>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>>> 
>>> 
>> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [VOTE] Release Apache NiFi 1.1.2

[Andy LoPresto]

Aldrin noted the tag was not pushed. It is present now:

nifi-1.1.2-RC1: 
https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=e31088642b6fdc7cafb52208a6ba29216dde7898
 


Andy LoPresto
alopre...@apache.org
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Feb 17, 2017, at 10:25 AM, Matt Gilman  wrote:
> 
> +1 (binding) Release this package as nifi-1.1.2
> 
> On Thu, Feb 16, 2017 at 10:37 PM, Andy LoPresto  >
> wrote:
> 
>> Hello,
>> 
>> I am pleased to be calling this vote for the source release of Apache NiFi
>> nifi-1.1.2.
>> 
>> The source zip, including signatures, digests, etc. can be found at:
>> https://repository.apache.org/content/repositories/orgapachenifi-1098
>> 
>> The Git tag is nifi-1.1.2-RC1
>> The Git commit ID is 51fad01f5daf33716b8b5379c32ee932d91c8c63
>> https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=
>> 51fad01f5daf33716b8b5379c32ee932d91c8c63
>> 
>> Checksums of nifi-1.1.2-source-release.zip:
>> MD5: 31d20a09955fac32d5b4147c497deede
>> SHA1: 9f8f2ce00397d990dfb0890f9b1ede70dca4f25e
>> SHA256: 0f57b5ae7f5e1d7f1289d779df39f20d70af0ffd92cb01b265beb90b309b747e
>> 
>> Release artifacts are signed with the following key:
>> https://people.apache.org/keys/committer/alopresto.asc
>> 
>> KEYS file available here:
>> https://dist.apache.org/repos/dist/release/nifi/KEYS
>> 
>> 2 issues were closed/resolved for this release:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>> version=12339600&projectId=12316020
>> 
>> Release note highlights can be found here:
>> https://cwiki.apache.org/confluence/display/NIFI/
>> Release+Notes#ReleaseNotes-Version1.1.2
>> 
>> The vote will be open for 96 hours (over holiday weekend).
>> Please download the release candidate and evaluate the necessary items
>> including checking hashes, signatures, build
>> from source, and test.  The please vote:
>> 
>> [ ] +1 Release this package as nifi-1.1.2
>> [ ] +0 no opinion
>> [ ] -1 Do not release this package because because…
>> 
>> Andy LoPresto
>> alopre...@apache.org
>> *alopresto.apa...@gmail.com  
>> mailto:alopresto.apa...@gmail.com>>*
>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [VOTE] Release Apache NiFi 1.1.2

[Aldrin Piri]

+1, binding

Comments:
* The hash provided in the email is for the next development version,
1.1.3-SNAPSHOT.  The hash for 1.1.2, and correctly tagged as such,
is e31088642b6fdc7cafb52208a6ba29216dde7898 [
https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=e31088642b6fdc7cafb52208a6ba29216dde7898
]
* Hashes and signature looks good
* Build and basic flows worked

On Fri, Feb 17, 2017 at 3:47 PM, Andy LoPresto  wrote:

> Aldrin noted the tag was not pushed. It is present now:
>
> nifi-1.1.2-RC1: https://git-wip-us.apache.org/repos/asf?p=
> nifi.git;a=commit;h=e31088642b6fdc7cafb52208a6ba29216dde7898
>
> Andy LoPresto
> alopre...@apache.org
> *alopresto.apa...@gmail.com *
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Feb 17, 2017, at 10:25 AM, Matt Gilman  wrote:
>
> +1 (binding) Release this package as nifi-1.1.2
>
> On Thu, Feb 16, 2017 at 10:37 PM, Andy LoPresto 
> wrote:
>
> Hello,
>
> I am pleased to be calling this vote for the source release of Apache NiFi
> nifi-1.1.2.
>
> The source zip, including signatures, digests, etc. can be found at:
> https://repository.apache.org/content/repositories/orgapachenifi-1098
>
> The Git tag is nifi-1.1.2-RC1
> The Git commit ID is 51fad01f5daf33716b8b5379c32ee932d91c8c63
> https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=
> 51fad01f5daf33716b8b5379c32ee932d91c8c63
>
> Checksums of nifi-1.1.2-source-release.zip:
> MD5: 31d20a09955fac32d5b4147c497deede
> SHA1: 9f8f2ce00397d990dfb0890f9b1ede70dca4f25e
> SHA256: 0f57b5ae7f5e1d7f1289d779df39f20d70af0ffd92cb01b265beb90b309b747e
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/alopresto.asc
>
> KEYS file available here:
> https://dist.apache.org/repos/dist/release/nifi/KEYS
>
> 2 issues were closed/resolved for this release:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> version=12339600&projectId=12316020
>
> Release note highlights can be found here:
> https://cwiki.apache.org/confluence/display/NIFI/
> Release+Notes#ReleaseNotes-Version1.1.2
>
> The vote will be open for 96 hours (over holiday weekend).
> Please download the release candidate and evaluate the necessary items
> including checking hashes, signatures, build
> from source, and test.  The please vote:
>
> [ ] +1 Release this package as nifi-1.1.2
> [ ] +0 no opinion
> [ ] -1 Do not release this package because because…
>
> Andy LoPresto
> alopre...@apache.org
> *alopresto.apa...@gmail.com *
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
>
>

Re: Sensitive-value properties

[Andy LoPresto]

Russ,

Both Bryan and Joe are exactly correct in their responses. To add some context, 
each sensitive property value is encrypted using the specified algorithm in 
nifi.properties. By default, and therefore on any unmodified system, this is 
PBEWITHMD5AND256BITAES-CBC-OPENSSL, which means that the actual cipher applied 
is AES with CBC mode of operation [1] using a 256-bit key which is derived from 
the provided “nifi.sensitive.props.key” value (which is really a password, not 
a true key) using the OpenSSL EVP_BytesToKey [2] key derivation function (KDF) 
— a modified version of PKCS #5 v1.5’s MD5-based PBKDF1 [3] which is identical 
if the combined length of the key and IV is less than or equal to an MD5 digest 
and non-standard if greater.

A random 16 byte salt is generated during the encrypt process (the salt length 
is actually set to be the block length of the cipher in question — AES is 
always 16 bytes, but if you choose to use DES for example, this value would be 
8 bytes), and this salt is provided, along with an iteration count (1000 by 
default) to the KDF. Internally to the application, this process occurs within 
the Jasypt library (slated for removal in NIFI-3116 [4]) but you can see a 
compatible Java native implementation of this process in the 
ConfigEncryptionTool I wrote [5].

If the “nifi.sensitive.props.key” value is empty, a hard-coded password is used 
as Bryan mentioned. This is why ALL DOCUMENTATION should recommend setting that 
value to a unique and strong passphrase prior to deployment [6].

Once the key is derived, the sensitive value is encrypted and the salt and 
cipher text are concatenated and then encoded in hexadecimal. This output is 
wrapped in “enc{“ and “}” tokens to denote the value is encrypted, and then 
stored in the flow.xml.gz. As Joe and Bryan pointed out, the sensitive value 
(in plaintext or encrypted form) is never sent over the REST API to any client, 
including the UI. When editing a processor property that is sensitive, the UI 
displays a static placeholder.

If two values are the same (i.e. the same password in an EncryptContent 
processor encrypting and an EncryptContent processor decrypting later in the 
same flow), the two encrypted values will be completely different in the 
flow.xml.gz even though they were encrypted with the same key. This is because 
of the random salt value mentioned above.

The encrypt-config.sh script [7] in nifi-toolkit exposes the functionality to 
“migrate” the flow.xml.gz encrypted values to be encrypted with a new key. For 
example, if you read the above and feel uncomfortable with your values 
encrypted with the default hard-coded password rather than a unique passphrase, 
you can run this tool and provide a new passphrase, and it will update 
nifi.properties with the new passphrase (and encrypt it if you have encrypted 
configuration [8] enabled) and decrypt all values in the flow.xml.gz and 
re-encrypt them with the new key and re-populate them.

A small note on the migration tool — you may notice that after running it, 
identical values will have identical encrypted values. This design decision was 
made because the performance tradeoff of not re-performing the KDF with a 
unique salt and cipher initialization on each value is immense, and the threat 
model is weak because the key is already present on the same system. This 
decision was further impacted by the process by which Jasypt derives the keys. 
After NIFI-3116 is completed, I feel confident we can improve the security of 
the cipher texts by using unique IVs without incurring the substantial penalty 
currently levied by the library structure.

Throughout this explanation, you may have had concerns about some of the 
decisions made (algorithms selected, default values, etc.). There are ongoing 
efforts to improve these points, as security is an evolving process and attacks 
and computational processing availability to attackers is always increasing. 
More of this is available in relevant Jiras [9][10][11] and the Security 
Features Roadmap on the wiki [12], but in general I am looking to harden the 
system by restricting the algorithms used by default and available in general 
and increasing the cost of all key derivations (both in time and memory 
hardness via PBKDF2, bcrypt, and scrypt [13]). Obviously the obstacles in this 
effort are backwards compatibility and legacy support. It is a balance, but 
with the support of the community, I see us continuing to move forward with 
regards to security while making the user experience even easier.

I hope that provided some helpful information in response to your question.


[1] 
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher_Block_Chaining_.28CBC.29
 

[2] https://www.openssl.org/docs/man1.1.0/crypto/EVP_BytesToKey.html 

[3] https://

Re: Sensitive-value properties

[Russell Bateman]

I thank all of you for this exhaustive treatment. Sometimes I regret 
that what flies around in forum threads never makes it into the docs.


On 02/17/2017 02:32 PM, Andy LoPresto wrote:

Russ,

Both Bryan and Joe are exactly correct in their responses. To add some 
context, each sensitive property value is encrypted using the 
specified algorithm in nifi.properties. By default, and therefore on 
any unmodified system, this is PBEWITHMD5AND256BITAES-CBC-OPENSSL, 
which means that the actual cipher applied is AES with CBC mode of 
operation [1] using a 256-bit key which is derived from the provided 
“nifi.sensitive.props.key” value (which is really a password, not a 
true key) using the OpenSSL EVP_BytesToKey [2] key derivation function 
(KDF) — a modified version of PKCS #5 v1.5’s MD5-based PBKDF1 [3] 
which is identical if the combined length of the key and IV is less 
than or equal to an MD5 digest and non-standard if greater.


A random 16 byte salt is generated during the encrypt process (the 
salt length is actually set to be the block length of the cipher in 
question — AES is always 16 bytes, but if you choose to use DES for 
example, this value would be 8 bytes), and this salt is provided, 
along with an iteration count (1000 by default) to the KDF. Internally 
to the application, this process occurs within the Jasypt library 
(slated for removal in NIFI-3116 [4]) but you can see a compatible 
Java native implementation of this process in the ConfigEncryptionTool 
I wrote [5].


If the “nifi.sensitive.props.key” value is empty, a hard-coded 
password is used as Bryan mentioned. This is why ALL DOCUMENTATION 
should recommend setting that value to a unique and strong passphrase 
prior to deployment [6].


Once the key is derived, the sensitive value is encrypted and the salt 
and cipher text are concatenated and then encoded in hexadecimal. This 
output is wrapped in “enc{“ and “}” tokens to denote the value is 
encrypted, and then stored in the flow.xml.gz. As Joe and Bryan 
pointed out, the sensitive value (in plaintext or encrypted form) is 
never sent over the REST API to any client, including the UI. When 
editing a processor property that is sensitive, the UI displays a 
static placeholder.


If two values are the same (i.e. the same password in an 
EncryptContent processor encrypting and an EncryptContent processor 
decrypting later in the same flow), the two encrypted values will be 
completely different in the flow.xml.gz even though they were 
encrypted with the same key. This is because of the random salt value 
mentioned above.


The encrypt-config.sh script [7] in nifi-toolkit exposes the 
functionality to “migrate” the flow.xml.gz encrypted values to be 
encrypted with a new key. For example, if you read the above and feel 
uncomfortable with your values encrypted with the default hard-coded 
password rather than a unique passphrase, you can run this tool and 
provide a new passphrase, and it will update nifi.properties with the 
new passphrase (and encrypt it if you have encrypted configuration [8] 
enabled) and decrypt all values in the flow.xml.gz and re-encrypt them 
with the new key and re-populate them.


A small note on the migration tool — you may notice that after running 
it, identical values will have identical encrypted values. This design 
decision was made because the performance tradeoff of not 
re-performing the KDF with a unique salt and cipher initialization on 
each value is immense, and the threat model is weak because the key is 
already present on the same system. This decision was further impacted 
by the process by which Jasypt derives the keys. After NIFI-3116 is 
completed, I feel confident we can improve the security of the cipher 
texts by using unique IVs without incurring the substantial penalty 
currently levied by the library structure.


Throughout this explanation, you may have had concerns about some of 
the decisions made (algorithms selected, default values, etc.). There 
are ongoing efforts to improve these points, as security is an 
evolving process and attacks and computational processing availability 
to attackers is always increasing. More of this is available in 
relevant Jiras [9][10][11] and the Security Features Roadmap on the 
wiki [12], but in general I am looking to harden the system by 
restricting the algorithms used by default and available in general 
and increasing the cost of all key derivations (both in time and 
memory hardness via PBKDF2, bcrypt, and scrypt [13]). Obviously the 
obstacles in this effort are backwards compatibility and legacy 
support. It is a balance, but with the support of the community, I see 
us continuing to move forward with regards to security while making 
the user experience even easier.


I hope that provided some helpful information in response to your 
question.



[1] 
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher_Block_Chaining_.28CBC.29

[2] https://www.openssl.org/docs/man1.

Re: Sensitive-value properties

[Andy LoPresto]

A lot of this specific information is buried in the Admin Guide, but I agree 
with your thoughts in general.

Andy LoPresto
alopre...@apache.org
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Feb 17, 2017, at 2:36 PM, Russell Bateman  wrote:
> 
> I thank all of you for this exhaustive treatment. Sometimes I regret that 
> what flies around in forum threads never makes it into the docs.
> 
> On 02/17/2017 02:32 PM, Andy LoPresto wrote:
>> Russ,
>> 
>> Both Bryan and Joe are exactly correct in their responses. To add some 
>> context, each sensitive property value is encrypted using the specified 
>> algorithm in nifi.properties. By default, and therefore on any unmodified 
>> system, this is PBEWITHMD5AND256BITAES-CBC-OPENSSL, which means that the 
>> actual cipher applied is AES with CBC mode of operation [1] using a 256-bit 
>> key which is derived from the provided “nifi.sensitive.props.key” value 
>> (which is really a password, not a true key) using the OpenSSL 
>> EVP_BytesToKey [2] key derivation function (KDF) — a modified version of 
>> PKCS #5 v1.5’s MD5-based PBKDF1 [3] which is identical if the combined 
>> length of the key and IV is less than or equal to an MD5 digest and 
>> non-standard if greater.
>> 
>> A random 16 byte salt is generated during the encrypt process (the salt 
>> length is actually set to be the block length of the cipher in question — 
>> AES is always 16 bytes, but if you choose to use DES for example, this value 
>> would be 8 bytes), and this salt is provided, along with an iteration count 
>> (1000 by default) to the KDF. Internally to the application, this process 
>> occurs within the Jasypt library (slated for removal in NIFI-3116 [4]) but 
>> you can see a compatible Java native implementation of this process in the 
>> ConfigEncryptionTool I wrote [5].
>> 
>> If the “nifi.sensitive.props.key” value is empty, a hard-coded password is 
>> used as Bryan mentioned. This is why ALL DOCUMENTATION should recommend 
>> setting that value to a unique and strong passphrase prior to deployment [6].
>> 
>> Once the key is derived, the sensitive value is encrypted and the salt and 
>> cipher text are concatenated and then encoded in hexadecimal. This output is 
>> wrapped in “enc{“ and “}” tokens to denote the value is encrypted, and then 
>> stored in the flow.xml.gz. As Joe and Bryan pointed out, the sensitive value 
>> (in plaintext or encrypted form) is never sent over the REST API to any 
>> client, including the UI. When editing a processor property that is 
>> sensitive, the UI displays a static placeholder.
>> 
>> If two values are the same (i.e. the same password in an EncryptContent 
>> processor encrypting and an EncryptContent processor decrypting later in the 
>> same flow), the two encrypted values will be completely different in the 
>> flow.xml.gz even though they were encrypted with the same key. This is 
>> because of the random salt value mentioned above.
>> 
>> The encrypt-config.sh script [7] in nifi-toolkit exposes the functionality 
>> to “migrate” the flow.xml.gz encrypted values to be encrypted with a new 
>> key. For example, if you read the above and feel uncomfortable with your 
>> values encrypted with the default hard-coded password rather than a unique 
>> passphrase, you can run this tool and provide a new passphrase, and it will 
>> update nifi.properties with the new passphrase (and encrypt it if you have 
>> encrypted configuration [8] enabled) and decrypt all values in the 
>> flow.xml.gz and re-encrypt them with the new key and re-populate them.
>> 
>> A small note on the migration tool — you may notice that after running it, 
>> identical values will have identical encrypted values. This design decision 
>> was made because the performance tradeoff of not re-performing the KDF with 
>> a unique salt and cipher initialization on each value is immense, and the 
>> threat model is weak because the key is already present on the same system. 
>> This decision was further impacted by the process by which Jasypt derives 
>> the keys. After NIFI-3116 is completed, I feel confident we can improve the 
>> security of the cipher texts by using unique IVs without incurring the 
>> substantial penalty currently levied by the library structure.
>> 
>> Throughout this explanation, you may have had concerns about some of the 
>> decisions made (algorithms selected, default values, etc.). There are 
>> ongoing efforts to improve these points, as security is an evolving process 
>> and attacks and computational processing availability to attackers is always 
>> increasing. More of this is available in relevant Jiras [9][10][11] and the 
>> Security Features Roadmap on the wiki [12], but in general I am looking to 
>> harden the system by restricting the algorithms used by default and 
>> available in general and increasing the cost of all key derivations (both in 
>> time and memory hardness via PBKDF2, b

Re: [VOTE] Release Apache NiFi 1.1.2

[Andre]

+1 - release

On Fri, Feb 17, 2017 at 2:37 PM, Andy LoPresto  wrote:

> Hello,
>
> I am pleased to be calling this vote for the source release of Apache NiFi
> nifi-1.1.2.
>
> The source zip, including signatures, digests, etc. can be found at:
> https://repository.apache.org/content/repositories/orgapachenifi-1098
>
> The Git tag is nifi-1.1.2-RC1
> The Git commit ID is 51fad01f5daf33716b8b5379c32ee932d91c8c63
> https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=
> 51fad01f5daf33716b8b5379c32ee932d91c8c63
>
> Checksums of nifi-1.1.2-source-release.zip:
> MD5: 31d20a09955fac32d5b4147c497deede
> SHA1: 9f8f2ce00397d990dfb0890f9b1ede70dca4f25e
> SHA256: 0f57b5ae7f5e1d7f1289d779df39f20d70af0ffd92cb01b265beb90b309b747e
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/alopresto.asc
>
> KEYS file available here:
> https://dist.apache.org/repos/dist/release/nifi/KEYS
>
> 2 issues were closed/resolved for this release:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> version=12339600&projectId=12316020
>
> Release note highlights can be found here:
> https://cwiki.apache.org/confluence/display/NIFI/
> Release+Notes#ReleaseNotes-Version1.1.2
>
> The vote will be open for 96 hours (over holiday weekend).
> Please download the release candidate and evaluate the necessary items
> including checking hashes, signatures, build
> from source, and test.  The please vote:
>
> [ ] +1 Release this package as nifi-1.1.2
> [ ] +0 no opinion
> [ ] -1 Do not release this package because because…
>
> Andy LoPresto
> alopre...@apache.org
> *alopresto.apa...@gmail.com *
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
>

Re: Creating a custom DatabaseAdapter

[Matt Burgess]

Stanislav,

This is not your fault, it is a current limitation due to the
organization of the NiFi submodules with respect to the location of
DatabaseAdapter.  In general, when a NiFi interface is to be
extensible, there is a submodule for the API JAR to be available to
other NARs/submodules/etc.  In this case, we'd likely want
DatabaseAdapter (and any related classes) to be included in
nifi-standard-services-api-nar as its own API NAR, yet at the moment
it is a class inside nifi-standard-nar.

I agree that we should make this interface available, and refactor the
submodules accordingly to make DatabaseAdapter extensible outside the
nifi-standard NAR. Some care should be given to which "parent NAR" it
belongs, in order to ensure that we don't upset the current mechanism
of one parent NAR per child NAR, but hopefully "nifi-services-api-nar"
is the right spot.  Do you mind writing up a Jira case for this?  I
think it will help the community in general as various DB integrations
are desired.

Thanks in advance,
Matt

On Fri, Feb 17, 2017 at 5:05 AM, Stanislav  wrote:
> Hi,
>
> I would like to create a custom 
> org.apache.nifi.processors.standard.db.DatabaseAdapter, is this possible?
> I have tried creating new class that implements the interface and specified 
> the full class name in 
> META-INF\services\org.apache.nifi.processors.standard.db.DatabaseAdapter 
> file, and created a nar.
> But this does not appear to be working, the custom processor i have in that 
> nar are picked-up but the DatabaseAdapter isn`t.
> Any tips on how to make it work?
>
> Best regards,
> Stanislav.