[ https://issues.apache.org/jira/browse/UIMA-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Burn Lewis resolved UIMA-3123. ------------------------------ Resolution: Fixed If the environmental variable UIMA_Jira3123 is set any of these invalid group parameter settings will continue to be accepted, with a warning reported on the console. > 2.4.1 release reports errors and fails where 2.4.0 was silent > ------------------------------------------------------------- > > Key: UIMA-3123 > URL: https://issues.apache.org/jira/browse/UIMA-3123 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework > Affects Versions: 2.4.1SDK > Reporter: Marshall Schor > Assignee: Burn Lewis > Priority: Minor > Fix For: 2.4.2SDK > > > 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. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira