Page History

...

1. Usage of instance methods to essentially access static fields. Not a big issue and for some may not be an issue at all, but worth pointing out as it may be confusing to others.
2. Repetitive code in getRelationships() and getSupportedPropertyDescriptors(). 
3. Because instance methods are used to access documentable elements, an instance of the component must be created. This fact presents a number of issues:
   1. Security. As NiFi evolves it is conceivable to assume that at some point one of the security requirements could be that an instance of a component may only be created by an authorized principal (e.g., run as)
   2. Questionable code in default constructor. Unrelated (un-used) and poorly implemented component may render the entire system unavailable by having "questionable code" inside the constructor. And while "questionable code" can also be present in static initializer and cause the same issues during class loading, it's a less common pattern and falls in realm of general coding practices (outside of NiFi).
   3. Throwaway instances. In fact NiFi instance without a flow will create and throw away 2 instances of each discovered component, regardless of how many will actually be used. And if component is already in the canvas and part of the flow 5 instance of it will be created (see 

      Jira
      server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key NIFI-1318

      )
   4. Leaky abstractions (of sort):
      1. developer now must be aware that they should not implement default constructor or any constructor for that matter.
      2. if they do they must be aware of any potential side-effects of creating multiple instances of a component, since component is naturally singleton in the process space.
4. Reliance on the ServiceLoader to discover components.

   1. Current extension model of NiFI assumes local availability of extensions (e.g., some local dir such as 'work') where they can be discovered. ServiceLoader helps with such discovery. But one of the side-effects of the ServiceLoader is a subsequent creation of a component's instance, regardless if the actual instance needs to be created. 

   2. As NiFi moves toward the concept of an ExtensionRegistry the assumptions of having components available locally is no longer valid, since implementation of ExtensionRegistry may not be based on locally available components. 

5. Generation of all documents during NiFi startup
   1. While current model works for a current state/size of NiFi, it is unsustainable for both NiFi distribution and NiFi documentation when one deals with thousands of components, versions etc.

...

Possible improvements

To follow convention over configuration approach which if addressed properly would greatly simplify user(dev) experience and would help to address the following:

...