uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rogan Creswick <cresw...@gmail.com>
Subject Problem with multiple type identifiers when loading pears
Date Thu, 03 Sep 2009 19:34:26 GMT
I just ran into what looks like a bug in the way ids are assigned for
JCas Cover types.

I'm loading annotators from PEARs, and each annotator (generally,
aggregate annotators, but I don't think that matters) produces
Redaction annotations.  The application that makes use of these
annotators needs to get filtered annotation indexes that only contain
these Redaction annotations.  Because of this, both the pears and the
invoking code have a dependency on the generated (by jcasgen)
Redaction class.

If I'm understanding the loading procedure, the ResourceManager
encapsulates a class loader that loads the PEAR dependencies, and
which triggers the creation of an instance of Redaction.class -- the
Redaction static initializer invokes
JCasRegistry.register(Redaction.class) to get a unique id.
Unfortunately, this seems to be happening *twice* for the same class,
since it is used by both the loaded pear and by the code doing the
loading.  JCasRegistry doesn't bother to check the input to see if it
has already assigned an ID for that class or not, so two IDs are
generated for Redaction.type, and that field is no longer a valid
identifier for the class.

One solution is to use a Map<Class<T extends Annotation>, Integer>
instead of the array list that JCasRegistry.register makes use of, and
do a look up on the class, returning the same id for subsequent calls.
That is probably not sufficient to properly solve the problem I'm
having, but I think it is necessary -- JCasRegistry.register(...) very
clearly does not return the same output for the same input on
subsequent invocations.

I've been able to work around my problem my eschewing use of
<Annotation>.type fields, and using
instead, so there does seem to be a viable workaround.

I'd like to hear about better solutions / workarounds, however.  It
seems like this would be a fairly common problem, and it was no the
simplest thing to debug.


View raw message