Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Confusion with using instance methods to access static fields. User would no longer have to implement those methods and they can be deprecated.
  2. Repetitive code in getRelationships() and getSupportedPropertyDescriptors().
    1. Analyzing many processors it becomes clear that the code in these methods is very repetitive as seen in example below. A very typical pattern is to assemble Collection in init() method or default constructor, leaving getRelationships() and getSupportedPropertyDescriptors() to simply return the instance variable representing such collections: 

      Code Block
      @Override
      protected void init(final ProcessorInitializationContext context) {
          final List<PropertyDescriptor> descriptors = new ArrayList<>();
          descriptors.add(FILE_SIZE);
          descriptors.add(BATCH_SIZE);
          descriptors.add(DATA_FORMAT);
          descriptors.add(UNIQUE_FLOWFILES);
          this.descriptors = Collections.unmodifiableList(descriptors);
          final Set<Relationship> relationships = new HashSet<>();
          relationships.add(SUCCESS);
          this.relationships = Collections.unmodifiableSet(relationships);
      }
      @Override
      protected List<PropertyDescriptor> getSupportedPropertyDescriptors() {
          return descriptors;
      }
      
      @Override
      public Set<Relationship> getRelationships() {
          return relationships;
      }
    2. Repetitive code could be easily handled by Reflection-based mechanisms already used by NiFi and many other projects and products. An example of one such way could be seen here (https://github.com/apache/nifi/pull/171NIFI-1384 PR). Further more, for enhanced control over which element are meant to be documented, a new @Documentable annotation could be introduced. This would remove a burden from the user to implement these methods making component development much simpler.
  3. While we can recommend best practices, developers could feel free to implement default constructor as they wish with realization that if they do something "questionable" in it, it will have no impact on the overall system until such component is introduced in the process space, at which point its an expression of intent to use.

  4. . . . MORE TO COME. . .

...