uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Lally <ala...@alum.rpi.edu>
Subject Re: handling of context saving in annotators
Date Wed, 08 Sep 2010 14:40:54 GMT
On Fri, Sep 3, 2010 at 3:28 PM, Marshall Schor <msa@schor.com> wrote:

> There are different kinds of things one could do here.  One would be to add
> some
> more notes to the manual(s) (I didn't check, the notes might actually
> already be
> there, but we could in that case make them stand out more :-) ) saying that
> if
> you use the base implementation classes as superclasses of your annotator
> implementation, you *must* call super.initialize.

Another would be to add some support in the getContext() default method
> which
> checks for null, and if found, issues a longer error message stating that
> the in
> user's implementations of initialize which extend xyz base class, the user
> *must* call super.initialize..., before calling getContext() or other
> framework
> methods that call getContext() (such as getEmptyCAS - used in CAS
> multipliers),
> or words to that effect.
> I agree with doing the above - better documentation and error messages are
always good.

> Another thing that could be done is to have the framework examine the
> annotator
> class before it calls its initialize method, to see if it is extending one
> of
> the base impl classes which has this field and makes use of it in the
> getContext() method, and if it finds that to be true, the framework could
> set
> this field itself.  This would eliminate the possible error from happening,
> but
> maybe it's overkill for what is a simple thing for users to do.
My thinking on this is that this adds additional complication that's not
worth it.  Currently we follow a straightfoward and often-used convention:

* The annotator interface defines the API between framework and the user's
* The abstract base class provides default implementations of the methods,
as a convenience

Your suggestion breaks this convention, basically by having the abstract
base class expose additional functionality (like a setContext() method) that
the framework knows about and calls.  In my experience things are not
normally done that way, so developers may be confused by what is happening.
It's kind of a "back door" way of accessing the annotator.

I also do not think that calling super.initialize() is that unusual of a
requirement when overriding a method.

I admit that the current annotator interface is not ideal.  If I had it to
do over again, I would have the UimaContext be a parameter to the
reconfigure method. But that is not really feasible at this point.  IMO, the
proposed patches for this problem all seem to have more downsides (in added
complexity) than upsides.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message