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 

Next year when Microsoft renames it "CelestialDB" we can rename the processor 
and add another alias.

Something like that?

-----Original Message-----
From: Sivaprasanna [mailto:sivaprasanna...@gmail.com] 
Sent: Wednesday, April 11, 2018 23:37
To: dev@nifi.apache.org
Subject: [EXT] Suggestion: Apache NiFi component enhancement


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.



Reply via email to