Use PropertyEditors to convert parameter values

[GoogleCodeExporter]

So given a configuration parameter:

  @ConfigurationParameter
  List<File> dirs;
  static String PARAM_DIRS = ConfigurationParameterFactory.createConfigurationParameterName(...);

As far as I can tell, you can only pass a String[], not a List<File> or even a 
File[]:

  // pass a list of Files
  List<File> dirs = new ArrayList<File>();
  dirs.add("...");
  ... setConfigurationParameter(PARAM_DIRS, dirs) ...

Exception in thread "main" org.apache.uima.UIMA_IllegalArgumentException: The 
value "java.util.ArrayList" does not match the data type of metadata attribute 
"type".
org.uimafit.factory.ConfigurationParameterFactory.createPrimitiveParameter(Confi
gurationParameterFactory.java:279)
org.uimafit.factory.ConfigurationParameterFactory.createConfigurationData(Config
urationParameterFactory.java:353)

  // pass an array of Files
  File[] dirs = new File[]{new File("...")};
  ... setConfigurationParameter(PARAM_DIRS, dirs) ...

Exception in thread "main" org.apache.uima.UIMA_IllegalArgumentException: The 
value "java.io.File" does not match the data type of metadata attribute "type".
org.uimafit.factory.ConfigurationParameterFactory.createPrimitiveParameter(Confi
gurationParameterFactory.java:279)
org.uimafit.factory.ConfigurationParameterFactory.createConfigurationData(Config
urationParameterFactory.java:353)

In general, it seems unintuitive that you can declare a field with a particular 
type, but you can't pass that type in as a configuration parameter. I don't 
know how hard this is to fix, but if we can't fix it, can we at least add a 
more informative error message?

Original issue reported on code.google.com by steven.b...@gmail.com on 6 Apr 2011 at 10:30

• Blocked on: #118

[GoogleCodeExporter]

I would suggest that we should upgrade uimaFIT to make use of PropertyEditors 
[1] that are part of the standard Java bean API. Implementations of 
PropertyEditors need to provide for a object-to-string and string-to-object 
conversion. Simple ProperyEditors only need to implement the conversion logic, 
even though the mechanism provides for much more powerful objects that may even 
include a UI part.

Java provides a registry [2] where a user can register such editors and provide 
a set of default ones.
Several libraries (e.g. Spring, opencsv, Apache Camel, Active MQ) and 
applications provide or use PropertyEditors. 

There like most likely some utility code in Spring which we could use, if we do 
not wish to code the whole conversion logic ourselves.

[1] 
http://download.oracle.com/javase/1.5.0/docs/api/java/beans/PropertyEditor.html
[2] 
http://download.oracle.com/javase/1.5.0/docs/api/java/beans/PropertyEditorManage
r.html

Original comment by richard.eckart on 6 Apr 2011 at 8:11

[GoogleCodeExporter]

I agree that it is unintuitive the way that it is.  Just as a reminder the 
values you can pass in directly map to the allowed param values in the 
UimaContext.  If we were directly initializing the member variables annotated 
with @ConfigurationParameter with the values passed into 
setConfigurationParameter, then we wouldn't have this limitation. 

(This comment is more for those who come along later and read this rather than 
adding to the discussion.)

Richard, I like your suggestion.  I have never used either of these but I like 
that it is part of the java language and seems to fit our usecase fairly well.  
My assumption here is that the use of PropertyEditors in uimaFIT would be 
completely hidden from a user because it used by e.g. 
org.uimafit.factory.ConfigurationParameterFactory.createConfigurationData(Object
...)  Is that right?

Original comment by phi...@ogren.info on 7 Apr 2011 at 3:38

[GoogleCodeExporter]

Yep. Just like our converters are currently hidden. However, unlike with out 
converters now, there would be a defined way to register new PropertyEditors.

Original comment by richard.eckart on 7 Apr 2011 at 5:46

[GoogleCodeExporter]

Yep, this sounds like the right way to go. We can provide the same default 
conversions that we supply now, and then if someone needs to add something, 
they can do so by defining their own PropertyEditor. 

Original comment by steven.b...@gmail.com on 7 Apr 2011 at 7:33

[GoogleCodeExporter]

It would also be nice if uimaFIT could handle multi-value parameters more 
intelligently.
I would like to be able to write:

   createPrimitiveDescriptor(AE.class, AE.PARAM_MULTI_VALUE, "singleValue");

instead of 

   createPrimitiveDescriptor(AE.class, AE.PARAM_MULTI_VALUE, new String[] { "singleValue" });

Original comment by richard.eckart on 7 Apr 2011 at 12:21

• Added labels: Priority-Medium

[GoogleCodeExporter]

I think there will not be enough time to get this into 1.2.0. I'd like to 
schedule this for a 1.3.0 release - tentatively towards the end of summer.

Original comment by richard.eckart on 11 Apr 2011 at 5:00

[GoogleCodeExporter]

Can we at least get a more informative error message for the 1.2.0 release?

Original comment by steven.b...@gmail.com on 11 Apr 2011 at 5:23

[GoogleCodeExporter]

We can let uimaFIT throw an exception when something value is used as a 
parameter that is not supported by UIMA.

Original comment by richard.eckart on 11 Apr 2011 at 5:31

[GoogleCodeExporter]

That would be fine - as long as the message is better than the current one, 
which is so uninformative that it took forever to figure out what I was doing 
wrong.

Original comment by steven.b...@gmail.com on 11 Apr 2011 at 6:23

[GoogleCodeExporter]

Original comment by richard.eckart on 2 May 2011 at 9:22

• Added labels: Milestone-1.3.0
• Removed labels: Milestone-1.2.0

[GoogleCodeExporter]

I have improved the error message and moved this issue to 1.3.0 now.

Original comment by richard.eckart on 2 May 2011 at 9:22

[GoogleCodeExporter]

Original comment by richard.eckart on 4 Jan 2012 at 10:51

• Added labels: Milestone-1.4.0

[GoogleCodeExporter]

Changed title. Was: setConfigurationParameters with List<File> as target

Original comment by richard.eckart on 14 Apr 2012 at 12:11

• Changed title: _Use PropertyEditors to convert parameter values _

[GoogleCodeExporter]

Initialization of "Boolean" fields in current implementation seems not to be 
clean (see issue 118). This needs to be fixed for a consistent behavior when 
PropertyEditors are introduced.

Original comment by richard.eckart on 22 Apr 2012 at 10:23

• Added labels: Type-Enhancement

[GoogleCodeExporter]

Since I didn't want to reimplement significant parts of the Spring property 
value injection code for uimaFIT, I just used Spring's code, in particular 
DataBinder and SimpleTypeConverter and their infrastructures. This results in 
two additional dependencies: spring-context (DataBinder) and spring-beans 
(SimpleTypeConverter and default PropertyEditors) Previously, uimaFIT already 
supported quite advanced handling of generic collections, which is only 
supported since Spring 3.1.0.

- Switch from custom bean value injection code to Spring
- Allow using any classes for which Spring/Java provide conversions or 
PropertyEditors as parameter values
- Update to Spring 3.1.0.RELEASE because previous versions cannot deal properly 
with generic collection types" -

So far it looks like the change is backwards compatible. Please test 
extensively.
--
Committed revision 821.

Original comment by richard.eckart on 22 Apr 2012 at 9:35

• Changed state: Started

[GoogleCodeExporter]

Enum values can currently not be set as parameters. Trying to do so causes an 
exception.

Original comment by richard.eckart on 5 Jun 2012 at 8:41

[GoogleCodeExporter]

Enum values work now.
---
Committed revision 828.

Original comment by richard.eckart on 5 Jun 2012 at 9:00

[GoogleCodeExporter]

This seems to work good now. It's also compatible (minus that Spring is updated 
which may require that applications using uimaFIT may also need to update 
Spring).

Original comment by richard.eckart on 5 Jul 2012 at 8:14

• Changed state: Fixed
• Added labels: Compatible-Yes
• Now blocked on: #118