uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Eckart de Castilho <...@apache.org>
Subject Re: @ConfParam initialization of values from symbol name of static instance?
Date Tue, 02 May 2017 00:11:31 GMT
Hi,

> On 26.04.2017, at 22:29, José Tomás Atria <jtatria@gmail.com> wrote:
> 
> Hello all!
> 
> I know that UIMA-FIT is capable of initializing enum-typed configuration parameters from
a string equal to the name of one of the values in an enum class. i.e. this works as documented:
> 
> public static enum SomeEnum {
>     A_VALUE;
> }
> 
> @ConfigurationParameter( name = "example", mandatory = false, defaultValue="A_VALUE"
)
> private SomeEnum enumValue;
> 
> However, I recently had to refactor one my enums into a normal class with static members,
and I found that UIMA-FIT is equally capable of initializing these parameters from a string
equal to the symbol of a class instance set up as a static member i.e. this also works:
> 
> public static class SomeClass {
>     public static final SomeClass A_VALUE = new SomeClass()
> }
> 
> @ConfigurationParameter( name = "example", mandatory = false, defaultValue="A_VALUE"
)
> private SomeClass classValue;
> 
> Is this known behaviour? I tried stepping through the conf param initialization logic,
but I got lost in the depths of Spring, and I get the feeling that this is basically a side-effect
of spring's implementation of enum initialization details, which seems a little unreliable...

I wasn't aware that this is possible. But it sounds rather like a nice feature than like something
that is unreliable. 

> Then again, enum types are basically immutable collections of class instances as static
members, no?

I don't know how exactly enums are translated into byte-code, but what you say makes sense.

> Is it reasonable to use this "feature"? if so, should it be mentioned in the documentation?

Puh... why not. I am sometimes considering to drop the dependency on Spring to avoid/reduce
potential dependency version conflicts - but then I never have the time and since Spring does
a great job of maintaining compatibility, issues have never turned out really problematic...

Regarding mentioning it in the documentation - not sure. Do we have to document all the behaviors
of Spring in detail? If it were documented, we should also have unit tests for it. Would you
like to turn your code into a unit test and to contribute it + the related documentation?

Cheers,

-- Richard

P.S.: I am aware that you have contributed a patch to uimaFIT which has so far not been integrated
(https://issues.apache.org/jira/browse/UIMA-4212). The main reason is that the patch does
not include
unit tests (cf. my comment from Dec 2015). Contributions are really welcome, but without tests,
it is
somewhat tedious to integrate them.
Mime
View raw message