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