Details
-
Improvement
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
2.4.1SDK
-
None
Description
A user tested some "Pear"s (packaged UIMA pipelines) with 2.4.1 and found they failed to validate, whereas they were fine in 2.4.0.
Traced this to some new code in ConfigurationManager_impl, which added some logging for configuration parameter settings, if you specified the log level to be CONFIG.
The process of generating the information that went into the log message was being done, even if the CONFIG level was not enabled. This information included a printed representation of the parameter value. Because of this, the code access the parameter settings. The old code never did this, I think.
The access, if the value was an array (multiple-values-allowed == true), attempted to convert the setting value to an array. This failed in the PEAR example, because the PEAR configuration had an error - the setting was unused - so it had a value of <string/> whereas it should have had a value of <array/>.
While this could be fixed in the PEAR, from the users point of view, this may be more or less difficult - they may just be consumers / users of PEAR files developed by others, and not know how to fix this, or to get the original supplier of the PEAR to do so.
We should not throw an exception in this case, but do something more reasonable - since this occurs in the logging message, we should report this in the log message, instead.
Furthermore, for efficiency, we should avoid doing all log message work unless the log level would allow logging at the CONFIG level, here.