For users of UIMA to converse about such things as configuration and operating of the software of the Project

Re: Problem with multiple type identifiers when loading pears

On Sat, Sep 5, 2009 at 5:09 AM, Marshall Schor <msa@...> wrote:
>
> Can you say a bit more what the problem is?
>

I think my problem is actually tangential to the issue with
JCasRegistry.  After retrieving types from the jcas TypeSystem, I
still ran into issues with multiple Redaction definitions because of
multiple copies of the bytecode being loaded (multiple class loaders,
I think).  I've worked around that -- see below if you're interested.
I'd like to hear suggestions to make it cleaner, but at least it's
working.

I still don't understand why  JCasRegistry.register(...) shouldn't be
a true function.  It seems like there are at least two parallel ways
to retrieve types, and in my experience, they don't return the same
results--at least when getting filtered annotation indices.  (The ways
being: JCasRegistry.getClassForIndex(MyAnnotationType.type) and
aJCas.getTypeSystem().getTypeByName(MyAnnotationType.class.getType())

Anyhow, here's an overview of what we're doing -- it may shed some
light on this issue:

The UIMA portion of our application is a self-contained module (lets
call it 'core') that (once instantiated) takes a Document as input,
and returns a Collection<Violation>.  Violations are moderately
complex data structures that contain the fields of an Annotation
object -- specifically, a Redaction (Redaction is a JCasGen-generated
annotation subtype with some minor additional metadata that the
Annotators populate).

(Continue reading)

headers

Marshall Schor | 6 Sep 05:43

Re: Problem with multiple type identifiers when loading pears


Rogan Creswick wrote:
> On Sat, Sep 5, 2009 at 5:09 AM, Marshall Schor <msa@...> wrote:
>   
>> Can you say a bit more what the problem is?
>>
>>     
>
> I think my problem is actually tangential to the issue with
> JCasRegistry.  After retrieving types from the jcas TypeSystem, I
> still ran into issues with multiple Redaction definitions because of
> multiple copies of the bytecode being loaded (multiple class loaders,
> I think).  I've worked around that -- see below if you're interested.
> I'd like to hear suggestions to make it cleaner, but at least it's
> working.
>
> I still don't understand why  JCasRegistry.register(...) shouldn't be
> a true function.  It seems like there are at least two parallel ways
> to retrieve types, and in my experience, they don't return the same
> results--at least when getting filtered annotation indices.  (The ways
> being: JCasRegistry.getClassForIndex(MyAnnotationType.type) and
> aJCas.getTypeSystem().getTypeByName(MyAnnotationType.class.getType())
>   
hmmm.  The method JCasRegistry.getClassForIndex... returns a Java cover
class corresponding to a particular CAS type.
As previously discussed, there can be multiple definitions for these.

The second form I think is written incorrectly - it won't compile for me
because the TypeSystem object returned by aJCas.getTypeSystem() doesn't
have a method getTypeByName... so I'm not sure what you meant.

(Continue reading)

headers

Rogan Creswick | 6 Sep 19:31

Re: Problem with multiple type identifiers when loading pears

On Sat, Sep 5, 2009 at 8:43 PM, Marshall Schor <msa@...> wrote:
>
> The method JCasRegistry.getClassForIndex... returns a Java
> cover class corresponding to a particular CAS type.
> As previously discussed, there can be multiple definitions for
> these.

How do you map from one to the other, or how do you make use of the
annotation types that come out of a PEAR if they are different
CAS/cover types (I'm still a bit fuzzy on that distinction) than those
the invoking code is aware of?  The definition for the cover class
that is used to annotate the content is contained within the pear (as
a jar that reside's in the PEARs lib dir, and on the pear's
classpath), so the calling code (the 'core' module in my case) can't
see that definition.

I could treat it as an Annotation instance, but then I can't access
the data I need -- nor can I filter the types that way.  Since the
type id isn't a compile-time constant, I can't store that somewhere
that core can access, so filtering based on that is out too.  I could
possibly filter with the Type from
jcas.getTypeSystem.getType(canonicalName), but that would require a
magic string somewhere that would have to be maintained along side the
definition of Redaction (without access to the Redaction class file, I
can't use the Redaction.class.getCanonicalName() trick below).

> Rogan Creswick wrote:
>>
>> a true function.  It seems like there are at least two parallel ways
>> to retrieve types, and in my experience, they don't return the same

(Continue reading)

headers

Marshall Schor | 7 Sep 05:23

Re: Problem with multiple type identifiers when loading pears


Rogan Creswick wrote:
> On Sat, Sep 5, 2009 at 8:43 PM, Marshall Schor <msa@...> wrote:
>   
>> The method JCasRegistry.getClassForIndex... returns a Java
>> cover class corresponding to a particular CAS type.
>> As previously discussed, there can be multiple definitions for
>> these.
>>     
>
> How do you map from one to the other, or how do you make use of the
> annotation types that come out of a PEAR if they are different
> CAS/cover types (I'm still a bit fuzzy on that distinction) than those
> the invoking code is aware of?  
The actual data is contained inside the CAS.  Within the PEAR, the
PEAR's JCas cover classes are used.  Outside of the PEAR, the outside
JCas cover classes are used. 

So, imagine that inside the PEAR, it created an instance of a CAS type
FOO and set the feature FooFeature to some value, all using the PEAR's
JCas cover classes.

Now, when the CAS is passed out of the PEAR, it can be accessed with the
JCas cover classes being used there.  So, outside the PEAR, the CAS has
the same FOO instance, with FooFeature set, and it can be accessed.

> The definition for the cover class
> that is used to annotate the content is contained within the pear (as
> a jar that reside's in the PEARs lib dir, and on the pear's
> classpath), so the calling code (the 'core' module in my case) can't

(Continue reading)