Pierre Villard created NIP-25:
---------------------------------
Summary: Add Metadata-Only Parameter Listing to ParameterProvider
Key: NIP-25
URL: https://issues.apache.org/jira/browse/NIP-25
Project: NiFi Improvement Proposal
Issue Type: Improvement
Reporter: Pierre Villard
Assignee: Pierre Villard
h2. Motivation
The {{ParameterProvider}} interface currently requires implementations to
return fully resolved parameter values whenever the framework enumerates
available parameters. For providers backed by external secret stores such as
AWS Secrets Manager, or Azure Key Vault, fetching every secret value may be
expensive.
The NiFi framework uses {{ParameterProvider.fetchParameters()}} to populate the
secrets-picker UI presented to connector users. This UI only needs parameter
metadata (name, group, description) and never displays secret values. There is
currently no way for a provider to return metadata without also fetching
values, forcing the expensive full-fetch path even when only a listing is
needed.
h2. Scope
Add a single default method to the {{ParameterProvider}} interface in nifi-api:
{code:java}
default List<ParameterGroup> listParameters(ConfigurationContext context)
throws IOException {
return fetchParameters(context);
} {code}
The default implementation delegates to the existing
{{fetchParameters(context)}} method, ensuring full backward compatibility.
Providers that can separate metadata retrieval from value retrieval can
override this method to return {{Parameter}} objects with null values and
populated descriptors.
No new types, interfaces, or classes are introduced in nifi-api.
h2. Description
The change consists of a single default method addition to
{{{}org.apache.nifi.parameter.ParameterProvider{}}}:
* Method: {{listParameters(ConfigurationContext context)}}
* Returns: {{List<ParameterGroup>}} — the same return type as
{{{}fetchParameters(){}}}, using existing {{ParameterGroup}} and {{Parameter}}
types.
* Contract: Returns parameter metadata (names, groups, descriptors). Values
may be null when the provider can enumerate parameters without resolving their
values.
* Default behavior: Calls {{{}fetchParameters(context){}}}, so existing
providers require no changes.
Subsequent framework changes (outside the scope of this NIP) would update
{{{}SecretsManager{}}}, {{{}SecretProvider{}}}, and the web layer to call
{{listParameters()}} instead of {{fetchParameters()}} / {{getAllSecrets()}}
when populating the secrets-picker UI. Provider implementations in the NiFi
codebase or external repositories can then override {{listParameters()}} to
provide an optimized metadata-only code path.
h2. Compatibility
This is a purely additive change with no impact on backward compatibility:
* The method has a default implementation, so existing {{ParameterProvider}}
implementations continue to compile and function without modification.
* No existing method signatures, return types, or behaviors are altered.
* No new types are introduced.
* The change does not require a new major version of the Apache NiFi API.
h2. Verification
* Existing unit tests for {{ParameterProvider}} implementations continue to
pass without modification, confirming backward compatibility.
* A new unit test should verify that the default {{listParameters()}}
implementation delegates to {{fetchParameters()}} and returns the same result.
* Framework-level integration can be verified when the corresponding NiFi
framework changes consume the new method.
h2. Alternatives
# New {{SecretDescriptor}} interface in nifi-api — Introduce a metadata-only
type separate from {{{}Secret{}}}. This was considered but using existing
{{{}ParameterGroup{}}}/{{{}Parameter{}}} types with null values achieves the
same goal without expanding the API surface.
# Add a {{metadataOnly}} flag to {{fetchParameters()}} — Modify the existing
method signature or add a boolean parameter. This is not great because it
changes the contract of an established method and is less clear than a distinct
method name.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
