exceptionfactory commented on a change in pull request #5206:
URL: https://github.com/apache/nifi/pull/5206#discussion_r674854448
##########
File path:
nifi-commons/nifi-sensitive-property-provider/src/main/java/org/apache/nifi/properties/AbstractSensitivePropertyProvider.java
##########
@@ -47,4 +47,34 @@ public String getName() {
public String getIdentifierKey() {
return getProtectionScheme().getIdentifier();
}
+
+ @Override
+ public String protect(final String unprotectedValue, final
ProtectedPropertyContext context) throws SensitivePropertyProtectionException {
+ return protect(unprotectedValue);
+ }
+
+ @Override
+ public String unprotect(final String protectedValue, final
ProtectedPropertyContext context) throws SensitivePropertyProtectionException {
+ return unprotect(protectedValue);
+ }
+
+ /**
+ * Allows implementing classes to provide an implementation that does not
require a context.
+ * @param unprotectedValue The unprotected value
+ * @return The protected value
+ * @throws SensitivePropertyProtectionException If there was a problem
protecting the value
+ */
+ protected String protect(final String unprotectedValue) throws
SensitivePropertyProtectionException {
+ return null;
+ }
+
+ /**
+ * Allows implementing classes to provide an implementation that does not
require a context.
+ * @param protectedValue The protected value
+ * @return The unprotected value
+ * @throws SensitivePropertyProtectionException If there was a problem
unprotecting the value
+ */
+ protected String unprotect(final String protectedValue) throws
SensitivePropertyProtectionException {
+ return null;
+ }
Review comment:
Thanks for the clarification, that is helpful. The concept makes sense
given that some providers will use the context and some will not, however, it
seems like a different approach may be necessary.
Providers that use the context parameter could implement the interface
directly, whereas providers that do not need the context could extend the
abstract class. In light of the existing functionality in this class, perhaps
some refactoring along that line may be necessary, or perhaps two different
abstract classes would be helpful. Either way, adjusting the implementation
would make it clearer which approach a particular provider implements.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
