[
https://issues.apache.org/jira/browse/NIFI-14400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
endzeit updated NIFI-14400:
---------------------------
Description:
There are many processes that utilize the {{dependsOn}} mechanism provided by
the {{PropertyDescriptor.Builder}}. When this mechanism is used, it ...
{noformat}
Establishes a relationship between this Property and the given property by
declaring that this Property is only relevant if the given Property has a
non-null value.
Furthermore, if one or more explicit Allowable Values are provided, this
Property will not be relevant unless the given Property's value is equal to one
of the given Allowable Values.
If this method is called multiple times, each with a different dependency, then
a relationship is established such that this Property is relevant only if all
dependencies are satisfied.
{noformat}
As documented, _In the case that this property is NOT considered to be relevant
..., the property will not be shown in the component's configuration in the
User Interface._
However, currently the property will still be deemed as
{{PropertyValue.isSet()}} and provide a {{PropertyValue>getValue()}}. This can
lead to implementation mistakes and hard to trace errors. An example will be
provided below.
This issue proposes to deem properties whose dependency constraints are not met
as not set and to not provide a value. This way users won't fall into these
hard to detect configuration problems and processor implementors do not have to
handle explicitly check the dependency before accessing dependant properties.
Alternatively, the implementation problem could be fixed only for MergeContent
where this issue was detected.
-----
TODO Example MergeContent
was:
There are many processes that utilize the {{dependsOn}} mechanism provided by
the {{PropertyDescriptor.Builder}}. When this mechanism is used, it ...
{noformat}
Establishes a relationship between this Property and the given property by
declaring that this Property is only relevant if the given Property has a
non-null value.
Furthermore, if one or more explicit Allowable Values are provided, this
Property will not be relevant unless the given Property's value is equal to one
of the given Allowable Values.
If this method is called multiple times, each with a different dependency, then
a relationship is established such that this Property is relevant only if all
dependencies are satisfied.
{noformat}
X
> Properties with unmet dependency constraint should not be regarded as set /
> provide a value
> -------------------------------------------------------------------------------------------
>
> Key: NIFI-14400
> URL: https://issues.apache.org/jira/browse/NIFI-14400
> Project: Apache NiFi
> Issue Type: Bug
> Reporter: endzeit
> Priority: Major
>
> There are many processes that utilize the {{dependsOn}} mechanism provided by
> the {{PropertyDescriptor.Builder}}. When this mechanism is used, it ...
> {noformat}
> Establishes a relationship between this Property and the given property by
> declaring that this Property is only relevant if the given Property has a
> non-null value.
> Furthermore, if one or more explicit Allowable Values are provided, this
> Property will not be relevant unless the given Property's value is equal to
> one of the given Allowable Values.
> If this method is called multiple times, each with a different dependency,
> then a relationship is established such that this Property is relevant only
> if all dependencies are satisfied.
> {noformat}
> As documented, _In the case that this property is NOT considered to be
> relevant ..., the property will not be shown in the component's configuration
> in the User Interface._
> However, currently the property will still be deemed as
> {{PropertyValue.isSet()}} and provide a {{PropertyValue>getValue()}}. This
> can lead to implementation mistakes and hard to trace errors. An example will
> be provided below.
>
> This issue proposes to deem properties whose dependency constraints are not
> met as not set and to not provide a value. This way users won't fall into
> these hard to detect configuration problems and processor implementors do not
> have to handle explicitly check the dependency before accessing dependant
> properties.
> Alternatively, the implementation problem could be fixed only for
> MergeContent where this issue was detected.
> -----
> TODO Example MergeContent
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
