nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sivaprasanna <>
Subject Re: [EXT] Suggestion: Apache NiFi component enhancement
Date Thu, 12 Apr 2018 16:44:55 GMT
No my suggestion was a simpler approach. It just affects only the UI aspect
as my intention is to just override how the 'type' gets rendered in the UI.
For example, a processor's type is set to its canonical class name (
but rather than getting the canonical class name, let's just get from some
other method that checks if the new annotation is present, if it is
present, set the value provided in the annotation as the type, if it's not
present set the canonical class name just like how it is now. Again, my
intention is to just affect the UI so as to avoid making unnecessary
complication that could pose some backwards compatibility issue.


On Thu, Apr 12, 2018 at 1:35 PM, Peter Wicks (pwicks) <>

> I think this is a good idea. But based on your example I think you would
> want to provide a primary Type along with a list of Alias types.
> If NiFi starts and it can no longer find a processor by the Type name it
> had in the flow.xml it can check he annotations/aliases to see if it's been
> renamed. This would allow for easy renames.
> Example 1: NiFi can no longer find AzureDocumentDBProcessor. Developer
> renamed it to CosmosDBProcessor. In this case we don't really want the type
> to still same "DocumentDB", that's just confusing. Also, we might not want
> the type named CosmosDBProcessor. So we make the Type be something nice,
> like "Azure Comos DB", then add Aliases for "AzureDocumentDBProcessor" and
> "CosmosDBProcessor".
> Next year when Microsoft renames it "CelestialDB" we can rename the
> processor and add another alias.
> Something like that?
> -----Original Message-----
> From: Sivaprasanna []
> Sent: Wednesday, April 11, 2018 23:37
> To:
> Subject: [EXT] Suggestion: Apache NiFi component enhancement
> All,
> Currently the "type" of a component is actually the component's canonical
> class name which gets rendered in the UI as the class name with the
> component version. This is good. However I'm thinking it is better to have
> an annotation which a developer can use to override the component type.
> How is it used?
> I think an annotation can be sufficient. The framework checks if the
> annotation is present or not, if it is present, it uses the name provided
> there or else it uses the class name like how it is happening.
> Why and where is it needed?
>    - In scenarios where we devise a new naming convention and want to apply
>    it to older components without breaking backward compatibility
>    - A developer had created a component class with a name but later down
>    the line, the developer or someone else wants to change it to something
>    else, the reason could again be naming convention or just that the new
> name
>    makes more sense
>    - A component that has been built to work with third party tech, like
>    Azure, MongoDB, S3, Druid processors but the later versions of that tech
>    has been changed to something else by the original creators. (Something
>    similar has happened to Azure's DocumentDB which got later rebranded as
>    Azure CosmosDB). In such cases, without deprecating or rebuilding a new
>    processor, this can be used.
> Before creating a JIRA, I wanted to get the community's thoughts. Feel
> free to share your thoughts, concerns. If everything seems fine, I'll start
> working on the implementation.
> -
> Sivaprasanna

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message