[jira] [Resolved] (NIP-25) Add Metadata-Only Parameter Listing to ParameterProvider

["Pierre Villard (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/NIP-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pierre Villard resolved NIP-25.
-------------------------------
    Resolution: Fixed

> 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
>            Priority: Major
>
> 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)