NIFI-15155 Add ListenPort API

[kevdoran]

Summary

NIFI-15155

I had two goals in mind:

1. Support identifying properties as Listen Port definitions in serialized representations of property descriptors (extension manifests, versioned flows, flow definition json, etc.)
   • Added ListenPortDefinition to PropertyDescriptor that will be serialized as part of flow components
   • Updated XML Manifest Writer to support PropertyDescriptors with ListenPortDefinitions
2. Support dynamic discovery of components (processors and controller services) that provide Listen Ports by the framework, which will enable discovery via the REST API by external components.
   • Added ListenComponent interface that components can implement to provide bridge to framework

Keeping this in draft status until downstream changes for NIFI-15156 are farther along. See apache/nifi#10476 for draft changes for NIFI-15156.

Tracking

Please complete the following tracking steps prior to pull request creation.

Issue Tracking

• Apache NiFi Jira issue created

Pull Request Tracking

• Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
• Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

• Pull Request based on current revision of the main branch
• Pull Request refers to a feature branch with one commit containing changes

[exceptionfactory]

Thanks for putting this together @kevdoran. The new interfaces and corresponding implementations look clear and straightforward. I noted a few very minor recommendations, but otherwise this should be ready to go forward.

[kevdoran]

Thanks for the review @exceptionfactory. I think I've addressed all your comments, but let me know if you spot anything else you'd like me to change.

[kevdoran]

@exceptionfactory I added one more commit based on testing in apache/nifi#10476. For a processor such as ListenHTTP that can define multiple ports, it will be helpful to provide the property name as contextual information for ports discovered by the framework.

[exceptionfactory]

@exceptionfactory I added one more commit based on testing in apache/nifi#10476. For a processor such as ListenHTTP that can define multiple ports, it will be helpful to provide the property name as contextual information for ports discovered by the framework.

Thanks for the updates @kevdoran. I agree having a distinguishing name is helpful.

Rather than linking directly to the property name, calling the method getPortName() would provide a small amount of indirection. This can support using the property name where it fits, or using a more general name if needed.

[kevdoran]

Rather than linking directly to the property name, calling the method getPortName() would provide a small amount of indirection. This can support using the property name where it fits, or using a more general name if needed.

Thanks for the feedback @exceptionfactory. I really like this suggestion, and I've pushed an update to rename that field to portName.

[exceptionfactory]

Thanks for making the adjustments and keeping things moving with the implementation draft pull request @kevdoran. The latest version looks good! +1 merging