You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Burn Lewis (JIRA)" <de...@uima.apache.org> on 2013/07/31 22:59:48 UTC
[jira] [Assigned] (UIMA-3123) 2.4.1 release reports errors and
fails where 2.4.0 was silent
[ 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