sudeep87 / uimafit

Automatically exported from code.google.com/p/uimafit
0 stars 0 forks source link

config parameter values from system properties #41

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
I found the following method in ClearTK while restructuring some code today:

public static String getParameterValue(String paramName, String defaultValue) {
  String value = System.getProperty(paramName);
  if (value == null) {
     value = defaultValue;
  }
  return value;
}

I wonder if we should do this in uimaFIT when we are setting configuration 
parameters?

Original issue reported on code.google.com by pvogren@gmail.com on 15 Oct 2010 at 10:52

GoogleCodeExporter commented 8 years ago
I wish I hadn't pasted the actual method in now...  Well, you get the idea.  It 
seems like there might be a place in ConfigParamInitializer for obtaining 
system properties as configuration parameter values.

Original comment by pvogren@gmail.com on 15 Oct 2010 at 10:54

GoogleCodeExporter commented 8 years ago
Seems like it can't hurt given the typical names of UimaFIT configuration 
parameters (i.e. there's not much of a chance of property name collision) and 
it might be nice to be able to configure your whole UimaFIT pipeline from a 
single properties file...

Original comment by steven.b...@gmail.com on 16 Oct 2010 at 8:52

GoogleCodeExporter commented 8 years ago
Hmm... Thinking about that more, a single properties file can't possibly work 
if you have more than one instance of the same annotator, e.g. if you have 
several CleartkAnnotators, you need to define 
org.cleartk.classifier.CleartkAnnotator.classifierFactoryClassName several 
times with different values. So I guess I'm -0 on the proposal - it probably 
wouldn't hurt, but it also doesn't seem like it would gain us much.

Original comment by steven.b...@gmail.com on 16 Oct 2010 at 8:55

GoogleCodeExporter commented 8 years ago
We do not use long configuration parameter names. Typical parameter names we 
use are "Path" or "Input", so we potentially have a lot of parameter name 
collision. I would not like having system properties bleed into uimaFIT. Some 
time back I had suggested using a static variable to configure the checking for 
mandatory values of configuration parameters when creating descriptors (Issue 
5) - which was much less prone to side effects but still was not accepted at 
the time.

I think when uimaFIT is used in the context of an application/framework that 
may choose to draw parameter values from additional sources, but it should not 
do so itself.

Original comment by richard.eckart on 16 Oct 2010 at 10:18

GoogleCodeExporter commented 8 years ago
I take Richard's comment as a -1.  I am convinced by your arguments so -1 from 
me too.

Original comment by pvogren@gmail.com on 4 Jan 2011 at 12:17