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 to
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 up
something for the factories part next.
Best,
Richard
--
-------------------------------------------------------------------
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
[email protected]
www.ukp.tu-darmstadt.de
Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de
-------------------------------------------------------------------
