[jira] [Commented] (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:comment-tabpanel&focusedCommentId=13725718#comment-13725718 ] 

Burn Lewis commented on UIMA-3123:
----------------------------------

The problem is an old bug that omits the validation of configuration group parameter settings when some non-group parameter settings are also specified.  This means that the new code that logs the values will fail if any settings are invalid as it falsely assumed all had been validated earlier.
We'll fix the bug and provide a mechanism to allow old buggy descriptors to continue to work.
                
> 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