Github user YolandaMDavis commented on a diff in the pull request:
https://github.com/apache/nifi/pull/511#discussion_r67215337
--- Diff:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/StandardNiFiWebConfigurationContext.java
---
@@ -452,8 +456,40 @@ private ComponentDetails
getComponentConfiguration(final ProcessorDTO processor)
.state(processor.getState())
.annotationData(processorConfig.getAnnotationData())
.properties(processorConfig.getProperties())
+ .descriptors(getComponentDescriptors(processorConfig))
.validateErrors(processor.getValidationErrors()).build();
}
+
+ private Map<String,ComponentDescriptor>
getComponentDescriptors(final ProcessorConfigDTO processorConfig){
+
+ final Map<String, ComponentDescriptor> descriptors = new
HashMap<>();
+
+ for(String key : processorConfig.getDescriptors().keySet()){
+
+ PropertyDescriptorDTO descriptor =
processorConfig.getDescriptors().get(key);
+ List<PropertyDescriptorDTO.AllowableValueDTO>
allowableValuesDTO = descriptor.getAllowableValues();
+ Map<String,String> allowableValues = new HashMap<>();
+
+ if(allowableValuesDTO != null) {
+ for (PropertyDescriptorDTO.AllowableValueDTO value :
allowableValuesDTO) {
+ allowableValues.put(value.getValue(),
value.getDisplayName());
+ }
+ }
+
+ ComponentDescriptor componentDescriptor = new
ComponentDescriptor.Builder()
+ .name(descriptor.getName())
+ .displayName(descriptor.getDisplayName())
+ .defaultValue(descriptor.getDefaultValue())
+ .allowableValues(allowableValues)
+ .build();
+
+
+ descriptors.put(key,componentDescriptor);
+ }
+
+ return descriptors;
--- End diff --
@olegz this Map is populated based on whether a component (or specifically
a processor in this case) has Property Descriptors; my thought is it's unlikely
we'd encounter one that didn't but I'd defer to @mcgilman for certainty. Even
if it did return an empty map, this method is used by the
ComponentDetails.Builder class which can handle populating component details
with the empty value.
Also this method is used when building and returning detailed information
of a processor's configuration to the caller (after a specific update or get
detail info call). If for some reason a processor was created that had no
properties the Map would simply the reflect that Processor class's
configuration. I believe its possible for property descriptors to be removed
by the caller (via updateComponents and later StandardProcessorDAO) with
subsequent calls to generate that Map reflecting the change; however I would
hesitate to say an validation error should be thrown at this level, especially
if a caller proactively removes a property. If there is a case where a caller
was expecting a property to exist and then, upon retrieving details, discover
that property is gone perhaps it would be better to throw some error at that
level as opposed to within the class above.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
