[jira] [Commented] (NIFI-8206) Allow PropertyDescriptors to drive what type of input they accept

["Mark Payne (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/NIFI-8206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17279867#comment-17279867 ] 

Mark Payne commented on NIFI-8206:
----------------------------------

I think this would be a great improvement. I can envision it working something like this:
{code:java}
static final PropertyDescriptor ENRICHMENT_SOURCE = new PropertyDescriptor.Builder();
  .name("Enrichment Source")
  .identifiesResource( ResourceCardinality.ONE_OR_MORE, ResourceType.FILE, ResourceType.DIRECTORY, ResourceType.URL )
  .required(true)
  .build();{code}
Or something to this effect. The idea here being that the Property Descriptor is declaring that it identifies one or more resources. And each of those resources is allowed to be a File, a Directory, or a URL. There would be no need for a validator, as the framework would handle the validation. This would result in several benefits:
 * More polished, consistent UX
 * Simpler code
 * More informative documentation

We've also talked for a long time about having the ability to upload a file to a nifi cluster and have that available to all nodes. That could play in here nicely as well.

From the API perspective, it would also make things easier by allowing something along the lines of:
{code:java}
try (final InputStream resourceIn = context.getProperty(ENRICHMENT_SOURCE).asResource().getInputStream()) {
    ...
}{code}
Or:
{code:java}
final List<Resource> enrichmentResources = context.getProperty(ENRICHMENT_SOURCE).asResourceList();
for (final Resource resource : resource) {
  try (final InputStream resourceIn = resource.getInputStream()) {
  }
}

{code}
If the Resource were to reference a URL, it would be nice to have the framework become responsible for downloading the resource and then periodically checking if it's been updating and if so automatically update what is provided to the processor, etc. For that, an SSL Context may be needed, which could be implemented (from the extension POV) as simple as:
{code:java}
final Resource resource = context.getProperty(ENRICHMENT_SOURCE).asResource(SSL_CONTEXT); {code}
Where SSL_CONTEXT is a Property Descriptor that references an SSLContextService, perhaps.

Some things to think through here but i like the idea very much!

> 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
>            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)