[
https://issues.apache.org/jira/browse/UIMA-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Burn Lewis reassigned UIMA-3123:
--------------------------------
Assignee: Burn Lewis
> 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