external resources and parameters should be mandatory by default

[GoogleCodeExporter]

In my experience, in almost all cases, the parameters for components are 
mandatory, although the default in uimaFIT is that they are not mandatory. That 
means that most @ConfigurationParameter and @ExternalResource annotations are 
littered with "mandatory=true". It would be nice if we could change this in a 
future version of uimaFIT, e.g. in 2.0, since this is a non-compatible change.

Original issue reported on code.google.com by richard.eckart on 25 Mar 2011 at 10:25

[GoogleCodeExporter]

I'd say I'm much more like 50/50 mandatory/defaulting in my own code when using 
@ConfigurationParameter. But I'd be okay with changing it.

Original comment by steven.b...@gmail.com on 25 Mar 2011 at 11:33

[GoogleCodeExporter]

In the cases where you say a parameter is optional, do you say that because the 
parameter has a default value or because it is truly optional (that is, "null" 
is a valid value)?

Original comment by richard.eckart on 26 Mar 2011 at 11:43

[GoogleCodeExporter]

I have both, though the default value one is probably a little more common.

Original comment by steven.b...@gmail.com on 26 Mar 2011 at 12:40

[GoogleCodeExporter]

The semantics of "optional" have always confused me.  Here is how I think about 
it.  If a configuration parameter is mandatory, then the description must 
provide a value.  This value may be either explicitly set or a default must be 
provided in the description.  If a configuration parameter is not mandatory, 
then the description does not need to provide a value.  This is because the 
AE/CR using the parameter can either handle a null value or because it will 
provide a default value in the code.  

Where a default value is specified is an important distinction.  If it is 
provided by the analysis engine, then the configuration parameter is optional.  
If it is provided by the description, then it is not.  Providing default values 
in descriptors is preferred in many situations.  For example, for a given 
domain or usage scenario, you can imagine that a set of descriptor files with a 
set of default values would be given and another set of default values would be 
given for a different domain.* However, if the default value will never change 
from use-case to use-case, then it is perfectly reasonable to have the AE 
define a default value and to call the config parameter optional.

We have many optional parameters that are optional either because null is a 
fine value for the parameter or because the AE/CR provides a default value.  
However, I think that if the 'defaultValue' element of the 
ConfigurationParameter annotation is given a value and the annotated member 
variable cannot be null, then the parameter should be mandatory.  I doubt that 
ClearTK is consistent across all of its configuration parameters in this 
respect.  

* I think I have just pointed out a flaw in out treatment of the 'defaultValue' 
element of the @ConfigurationParameter.  It does not facilitate providing 
different default values for different situations.  As it is now, setting the 
defaultValue element is essentially the same as initializing the member 
variable with a value.  That is, there is no practical difference between:

@ConfigurationParameter(defaultValue='MST')
String timeZone;

@ConfigurationParameter
String timeZone = 'MST';

I'm not sure how we might facilitate different default values for different 
scenarios.  My initial reaction after thinking this through is that maybe we 
should remove the 'defaultValue' because it confuses the semantics of 
"optional" and because if someone really wants to hardwire a single default 
value for all uses of a component, then they might as well do it in code with a 
direct initialization.  

Original comment by phi...@ogren.info on 27 Mar 2011 at 2:52

[GoogleCodeExporter]

If a configuration parameter is mandatory, then UIMA will barf if no value is 
provided when instantiating a component.

If we remove the defaultValue parameter, we cannot extract the default value 
and put it into an XML descriptor, e.g. for the purpose of documentation - we 
would gain type-safety though!

I often have @ConfigurationParameters that are mandatory but specify a default 
value. In my opinion it is by accident that uimaFIT pre-loads the descriptor 
with the default value. If a component is instantiated using a manually crafted 
descriptor, this is may not be the case. If we initialize a field directly - 
without the defaultParameter - this is not a problem, because there is no way 
that a user can accidentally provide no value.

For subclasses it would probably be easy to override a parameter value in the 
initializer if no defaultValue parameter would exist.

Reconfiguration of a component is an issue without defaultValue, because there 
would need to be some extra code that resets the components fields to the 
default values before applying the new configuration parameters.
Note though, that uimaFIT currently does not support reconfiguration in its 
convenience classes - we should probably open an issue for that.

Original comment by richard.eckart on 27 Mar 2011 at 4:24

[GoogleCodeExporter]

Note: No issue is necessary regarding reconfiguration- per default 
reconfigure() calls initialize() again, so uimaFIT is called during 
reconfiguration.

Original comment by richard.eckart on 27 Mar 2011 at 4:32

[GoogleCodeExporter]

Original comment by richard.eckart on 17 Apr 2011 at 1:40

• Added labels: Compatible-No

[GoogleCodeExporter]

Original comment by richard.eckart on 7 Jan 2013 at 4:51

• Added labels: ASFJira-No

[GoogleCodeExporter]

Migrated to Apache: https://issues.apache.org/jira/browse/UIMA-2779

Original comment by richard.eckart on 30 Mar 2013 at 4:14

• Changed state: Accepted
• Added labels: ASFJira-Yes
• Removed labels: ASFJira-No

[GoogleCodeExporter]

UIMA-2779 is fixed.

Original comment by richard.eckart on 30 Mar 2013 at 4:59

• Changed state: Fixed