uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Lally" <ala...@alum.rpi.edu>
Subject Re: Cannot share Session object when using PEAR class loaders.
Date Mon, 01 Oct 2007 14:38:29 GMT

On 9/28/07, Danai Wiriyayanyongsuk <danaiw@gmail.com> wrote:
> Hi folks,
> I'm trying the PEAR class loaders in UIMA 2.2. I think I found an issue
> that, if a PEAR description file is specified in the aggregate analysis
> engine description, the session object returned from the method
> org.apache.uima.analysis_component.JCasAnnotator_ImplBase.getContext().getSession()
> from the related annotator will be different from other annotators. In other
> words, the annotators cannot share the same session object if the PEAR class
> loader is used.

Actually the Session objects aren't really fully implemented - we
should have said this in the javadocs, sorry about that.  Here's the
idea, though:

Even without PEARs, the Session objects of two different annotators
are supposed to be different.  The Session object was intended as a
way for multiple instances of the *same* annotator to share
information (within a remote service deployment where multiple
instances were created for performance reasons), not as a way to share
information between different annotators.  Each annotator gets a
different Session object so that there would not be conflicts with the
key names chosen by the different annotators.

The idea is that in a remote service deployment where there are
multiple instances of an annotator and multiple clients, that the
Session object is a place for an annotator to store information on
behalf of a particular client.  So if client A makes a remote call and
this is handled by annotator instance 1, and that instance puts
information in the Session object, then if client A makes another call
which is handled by annotator instance 2, that annotator instance
could retrieve the information put there by annotator instance 1.

That part works, but currently if another client B comes in, it will
not get a distinct Session object.  That functionality has to be
implemented in the service wrapper and this was never done.

> Here is more detail on the situation.
> I have two annotators. Both of them sharing the same piece of information
> via the Session object (Session session = getContext().getSession();). I
> assume that both annotators will have access to the same session object. I
> tried it and found the inconsistent behavior between the following cases:
> Case 1: The aggregate analysis engine description contains full descriptions
> of both annotators  (no import tags).
> Case 2: The aggregate analysis engine description contains import tags with
> the PEAR description files specified (xxx_pear.xml) for both annotators.
> In case 1, for both annotators, the *same* session object are returned from
> the method
> org.apache.uima.analysis_component.JCasAnnotator_ImplBase.getContext().getSession().
> However in case 2, the *different* session objects are returned from the
> method.

I'm surprised that Case 1 actually works.  I wrote a little test annotator:

  public void process(JCas aJCas) throws AnalysisEngineProcessException {
    String val = (String)getContext().getSession().get("foo");
    System.out.println("foo = " + val);
    getContext().getSession().put("foo", "bar");
    val = (String)getContext().getSession().get("foo");
    System.out.println("Set foo = " + val);

and made an aggregate with two such annotators, and showed that the
information put there by annotator 1 is not seen by annotator 2.

You still have a point, though, about the PEAR components.  Normally
the way for different annotators to share information is through a
SharedResourceObject.  However this won't work for PEAR components
because they don't share the same ResourceManager.  The way the PEAR
component works, it is completely isolated from the rest of the
aggregate AE (the main thing is that it can have its own class loader)
and can't share information.  This ought to be better documented.


View raw message