Return-Path: Delivered-To: apmail-incubator-uima-user-archive@locus.apache.org Received: (qmail 70615 invoked from network); 1 Oct 2007 14:39:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 1 Oct 2007 14:39:00 -0000 Received: (qmail 81936 invoked by uid 500); 1 Oct 2007 14:38:50 -0000 Delivered-To: apmail-incubator-uima-user-archive@incubator.apache.org Received: (qmail 81918 invoked by uid 500); 1 Oct 2007 14:38:50 -0000 Mailing-List: contact uima-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: uima-user@incubator.apache.org Delivered-To: mailing list uima-user@incubator.apache.org Received: (qmail 81909 invoked by uid 99); 1 Oct 2007 14:38:50 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Oct 2007 07:38:50 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of lally.adam@gmail.com designates 209.85.162.181 as permitted sender) Received: from [209.85.162.181] (HELO el-out-1112.google.com) (209.85.162.181) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Oct 2007 14:38:51 +0000 Received: by el-out-1112.google.com with SMTP id j27so2116792elf for ; Mon, 01 Oct 2007 07:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=/f0rs9l2GJA8tYlmCmBZ9gvi3075fa0NOM0aRdPjfF8=; b=p1cwra8JiWdERaNMhJfX+FrOTEkS5Q3voR2kx1MVyBwEO3rpZSDzfn538ZgirEDlZlpfQ0Vkj3yyY8c7LEhAJnzPcBeA//H/I2c0Rm4MHRD11eafUqzOjx/PEIJxG++KB0IaiMUiCIb36iwz99d7isH3fSYEsvG6rAZ0jE6DjDE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=mxbDkHfMapxjwxVVVIhJ3Zx4bWoJfpd60/FNtjUgBMUuxX1TT7FK59AygQb59bAQ1e2hnRmRC4u2Jr2UNw5/P70IZLLl3cQUR4eIsVW4fB3470Ruj9T/2E3UEg6v44HnnbKy9LB/VHLc3OJtUjjO9HnTZ+btSDkpk/bOfefkxj4= Received: by 10.114.58.1 with SMTP id g1mr4344356waa.1191249509907; Mon, 01 Oct 2007 07:38:29 -0700 (PDT) Received: by 10.141.211.11 with HTTP; Mon, 1 Oct 2007 07:38:29 -0700 (PDT) Message-ID: <2787e08a0710010738h7695871m832a7141bcf0a089@mail.gmail.com> Date: Mon, 1 Oct 2007 10:38:29 -0400 From: "Adam Lally" Sender: lally.adam@gmail.com To: uima-user@incubator.apache.org Subject: Re: Cannot share Session object when using PEAR class loaders. In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Google-Sender-Auth: fa4de54c637be1e4 X-Virus-Checked: Checked by ClamAV on apache.org Danai, On 9/28/07, Danai Wiriyayanyongsuk 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. Regards, -Adam