Closed GoogleCodeExporter closed 8 years ago
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
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
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
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
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
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
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
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
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
Original comment by richard.eckart
on 2 May 2011 at 9:22
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
Original comment by richard.eckart
on 4 Jan 2012 at 10:51
Changed title. Was: setConfigurationParameters with List<File> as target
Original comment by richard.eckart
on 14 Apr 2012 at 12:11
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
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
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
Enum values work now.
---
Committed revision 828.
Original comment by richard.eckart
on 5 Jun 2012 at 9:00
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
Original issue reported on code.google.com by
steven.b...@gmail.com
on 6 Apr 2011 at 10:30