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 jcas.getTypeSystem().getType(<Annotation>.class.getCanonicalName()) 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. Thanks! --Rogan
