uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Eckart de Castilho <eckar...@tk.informatik.tu-darmstadt.de>
Subject Re: UIMA and uimaFIT
Date Wed, 19 Oct 2011 06:06:01 GMT
Hello everybody,

thanks for the feedback. I'll reply to Marshal's first mail.

> I'm thinking (outloud) here of another kind of approach.  Suppose we keep the
> idea that the main "place" for parameter definitions / settings, is in the XML. 
> Perhaps we could use injection ideas + Java annotations to simplify the Java code.

uimaFIT is about several things. The part I have described so far is only how 
*context injection* works. I still have not fully described the part about the 
factories, which  is what the "description", "mandatory" and "defaultValue"
parameters of the @ConfigurationParameter annotation are for. 

Maybe we could postpone that discussion until I have written up a spec and some
examples for that part. 

> Here's how it might work.  You would define the parameters, etc., externally in
> the XML, as is now done.  But in the Java code, you would write something like
>   // this form if the name of the external parm differs from the variable name
>   @uimaParameter(ExternalParmName1) 
>   String myStringParm;
>   // this form if the name of the external parm is the same as the variable name
>   @uimaParameter
>   int myIntParam;
> etc.
> And then we would have the normal UIMA initialize code path, before it called
> initialize, find the @uimaParameter items and set them from the XML parameter
> settings.

That's the context injection part and that is how it's currently done in uimaFIT
(with minor differences, e.g. names of annotations and default parameter names).

In the component base classes uimaFIT provides, the initialize() method is overwritten
to do the context injection part. Optimally, that would be done before by the UIMA core
framework before ever reaching the initialize() method, as you say.

Please mind that there are currently two aspects to the @ConfigurationParameter annotation:
- its a marker for context injection
- its a declaration for information from which an XML descriptor can be generated

I was expecting that this may lead to confusion and discussion here. For an integration into
the UIMA core, it may be a good idea to separate these concerns, e.g. into several annotations
(possibly JSR-250 compatible). This has not been done so far because it was considered that
a single @ConfigurationParameter annotation is "nicer" that a set of annotation:

>   // For a mandatory parameter with the default name "myStringParam" and the default
value "Hello"
>   @Parameter @DefaultValue("Hello") @Required
>   String myStringParam;
>   // For an optional shared resource with the name "StopWords"
>   @Resource(name="StopWords")
>   StopWordList stopWordList;

Regarding XML vs. Annotations as the definitive specification: both approaches should be supported.
Take a look at Hibernate for example. Either Java <-> DB mapping can be provided in
the form of XML
mapping files or in the form of annotations. Each has its benefits and draw-backs. 

In Darmstadt we completely rely on descriptors generated at runtime form the annotations in
the Java
files and find that very very convenient. I understand others will prefer static XML files
runtime-generated descriptors.

I do not suggest to obsolete XML files as the definitive specification and in fact uimaFIT
does not
prohibit that. It is perfectly possible to use XML files with context injection.

From the discussion, I gather that the form of the specification is ok. I'll continue to write
something for the factories part next.



Richard Eckart de Castilho
Technical Lead
Ubiquitous Knowledge Processing Lab 
FB 20 Computer Science Department      
Technische Universit├Ąt Darmstadt 
Hochschulstr. 10, D-64289 Darmstadt, Germany 
phone [+49] (0)6151 16-7477, fax -5455, room S2/02/B117
Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de

View raw message