Busy week, eh? Anybody is having any concerns, suggestions? Any input is appreciated :)
Cheers, Sivaprasanna On Thu, Apr 12, 2018 at 10:14 PM, Sivaprasanna <sivaprasanna...@gmail.com> wrote: > 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 ( > DtoFactory.java#createProcessorDto > <https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/api/dto/DtoFactory.java#L2783>) > 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. > > - > Sivaprasanna > > On Thu, Apr 12, 2018 at 1:35 PM, Peter Wicks (pwicks) <pwi...@micron.com> > wrote: > >> 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 [mailto:sivaprasanna...@gmail.com] >> Sent: Wednesday, April 11, 2018 23:37 >> To: dev@nifi.apache.org >> 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 >> > >
