[jira] [Resolved] (UIMA-3123) 2.4.1 release reports errors and fails where 2.4.0 was silent

["Burn Lewis (JIRA)" <de...@uima.apache.org>]

     [ 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