Github user joewitt commented on the issue:
https://github.com/apache/nifi/pull/834
The new dependency in NiFiProperties definitely starts to increase it's
weight from a dependency/transitive perspective. We could just tell them to
only pay attention to its Properties interface but then they lose the static
key name references and the convenience method calls.
The transitive dependency weight becomes even more problematic when we have
additional providers beyond bouncycastle.
Perhaps we should consider ditching the static getInstance mechanism is
NiFiProperties and instead have that class constructed at specific and
appropriate entry points in the project. The constructed instance would have
populated plain text values for all properties sensitive or otherwise. It
could offer either an object model for properties which accounts for their key,
value, and whether they're sensitive or not - OR - it could simply provide a
method allowing the caller to ask if a given property was sensitive or not.
That said, I'm not sure why or if we'd want to expose whether a property was
sensitive or not. I could see it being useful we want to have callers know
they better not store the value in a log file or exception message.
The ProcessContext (processors), Reporting Context (reporting tasks), and
ConfigurtaionContext (controller services) each make sense for adding a
'getApplicationProperties()' method which returns the NiFiProperties. This
properties object would externalize any crypto libraries so that this
dependency (nifi-properties) remains pure.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
