uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tommaso Teofili <tommaso.teof...@gmail.com>
Subject Re: handling of context saving in annotators
Date Mon, 06 Sep 2010 08:04:41 GMT
Hi all,
I had a look at:
and the initialize() method does not appear to be overridden so the
super.initialize() call is not mentioned.

If we go for the option of better documenting the super.initialize() need,
maybe a good choice would be to put it here :

or here:

Despite this, my opinion is that having not to write the
"super.initialize();" inside a method overriding initialize() would be much

I will take a look at other sandbox annotators and check for the
super.initialize() issue.

2010/9/3 Marshall Schor <msa@schor.com>

>  A recent "bug" in the Snowball annotator arose as follows:
> 1) It didn't implement the full annotator set of methods, but instead,
> depended
> on the implementation skeleton done by a "base" implementation class.
> 2) That base implementation class included an implementation of
> reconfigure()
> which is implemented as:
>  public void reconfigure() throws ResourceConfigurationException,
> ResourceInitializationException {
>    destroy();
>    initialize(mContext);
>  }
> where "mContext" is a field which might or might not be set (it isn't set
> by the
> framework).
> It is set by the base implementation class's implementation of the
> "initialize(uimaContext)" method.  If the user has their own initialize
> method,
> and doesn't set this variable (which he would not normally be aware of)
> himself,
> he can set it by calling "super.initialize(uimaContext)".
> The bug that arose happened when the annotator writer didn't call
> "super.initialize", and then the application writer (different people,
> different
> roles) called "reconfigure", which the framework eventually passed down to
> the
> annotator.
> The user didn't implement this, but instead depended on the base
> implementation
> class.  This referenced the null value for mContext, which caused the
> error.
> ========
> 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.
> 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.
> ========
> Are there other approaches to this, and which kind of fix do you think we
> should
> do for this?
> -Marshall
> P.S., the Snowball Annotator in our sandbox has been fixed
> (https://issues.apache.org/jira/browse/UIMA-1861).  The other annotators
> in our
> sandbox and our examples haven't been "reviewed" as yet to see if they have
> this
> issue.

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