[
https://issues.apache.org/jira/browse/NIFI-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15094482#comment-15094482
]
Oleg Zhurakousky edited comment on NIFI-1384 at 1/12/16 8:11 PM:
-----------------------------------------------------------------
Further investigation shows that most elements from which documentation is
being build are class level elements (static fields, annotations etc) and
therefore can be accessed as such without creating an instance of
ConfigurableComponent. The only caveat is dynamic elements (property
descriptors, relationship etc.). However, the whole concept of dynamic
properties means we wont know until runtime. On top of that we currently have
no way of providing any type of description for those (no description, no
documentation). Also, dynamic elements (in today's implementation) won't appear
in the docs even if in the cases where the floe was restored from the template
containing components with dynamic elements.
So, essentially I am questioning the validity of some of the private methods
that we currently have on implementations of _DocumentetionWriter_
{code}
writeDynamicProperties(..)
writeDynamicRelationships(..)
. . .
{code}.
Based on the above two things become obvious:
1. It is unsustainable to create an instance of every component in the process
space just to print its documentation. Instead component class should be used
to extract all the required information, which will also pave the way of lazy
extraction of such elements when ExtensionRegistry becomes available.
2. Dynamic elements should be excluded from documentation.
was (Author: ozhurakousky):
An instance of every component in the process space is created regardless if
such component is going to be used. That is done to get component's
documentation. However, all documentation data of the component is available
from the component class
> Documentation should not require instance of a component since all
> information available at the class level (static constants, annotation etc)
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: NIFI-1384
> URL: https://issues.apache.org/jira/browse/NIFI-1384
> Project: Apache NiFi
> Issue Type: Sub-task
> Components: Core Framework
> Reporter: Oleg Zhurakousky
> Assignee: Oleg Zhurakousky
> Fix For: 0.5.0
>
>
> An instance of every component in the process space is created regardless if
> such component is going to be used or its documentation is going to be
> accessed. This causes heap pollution which could lead to performance issues
> as NiFi process space increases with new Processors, ControllerServices etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)