[
https://issues.apache.org/jira/browse/NIFI-8206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17319523#comment-17319523
]
ASF subversion and git services commented on NIFI-8206:
-------------------------------------------------------
Commit 7d1d536da68b00d1c0a7ec8548acf459f2e1845a in nifi's branch
refs/heads/main from Mark Payne
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=7d1d536 ]
NIFI-8206: Added identifiesExternalResource() method to
PropertyDescriptor.Builder and implemented functionality.
- Updated components to make use of new feature
NIFI-8206: Added a ResourceType of TEXT. This requires that the
ResourceReferenceFactory know which types are allowed in order to create the
ResourceReference. PropertyValue needs to then have the PropertyDescriptor
available to it. This resulted in highlighting many bugs in unit tests where
components were not exposing property descriptors via
getSupportedPropertyDescriptors() or were evaluating Expression Language using
the wrong scope, so fixed many unit tests/components to properly declare
Expression Language scope when using it
NIFI-8206: Removed problematic unit test that required directory names with
special characters that are not allowed on some operating systems
This closes #4890.
Signed-off-by: Bryan Bende <[email protected]>
> Allow PropertyDescriptors to drive what type of input they accept
> -----------------------------------------------------------------
>
> Key: NIFI-8206
> URL: https://issues.apache.org/jira/browse/NIFI-8206
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework, Extensions, Tools and Build
> Reporter: Matt Gilman
> Assignee: Mark Payne
> Priority: Major
>
> Currently, PropertyDescriptors can be configured with a Validator that
> validates any proposed value. Rather than solely driving what's allowable
> through the Validator which only exists at runtime, it may be beneficial if
> the PropertyDescriptor can describe the type of input they support. For
> instance a file, a list of files, a URL, etc.
> Using these details to populate the extension metadata generated at build
> time would be helpful in use cases where the flow might be authored separate
> from the runtime environment like Stateless NiFi.
> Having these details may even provide an opportunity to update the Processor
> API to support default file exists validators, URL validators, etc. Also, it
> may allow for the Processor API to offer capabilities around loading the
> content from these configured value.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
