[ 
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

Reply via email to