uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: Problem with multiple type identifiers when loading pears
Date Sat, 05 Sep 2009 12:09:46 GMT

Rogan Creswick wrote:
> 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.

Can you say a bit more what the problem is?

The use-case for Pears is to provide a shielded environment where the
things in the PEAR can run with an independent classpath.  For example,
a Pear component can define a JCas class called Token, which might have
a different cover class than anyone else's Token.  While inside the
PEAR, its Token JCas class would be used, while, outside the PEAR, other
versions of this class might be used.  This is done on purpose.

If you don't want this shielding behavior, you can get the non-shielding
behavior by 1) installing the PEAR, 2) resolving any class path issues
by hand, 3) setting up a common, appropriate class path for both the
PEAR component(s) and the remaining components, and then 4) running with
the normal descriptor for the component (not the Pear-specifier descriptor).


View raw message