From uima-user-return-2525-apmail-incubator-uima-user-archive=incubator.apache.org@incubator.apache.org Sat Sep 05 12:10:22 2009 Return-Path: Delivered-To: apmail-incubator-uima-user-archive@minotaur.apache.org Received: (qmail 75868 invoked from network); 5 Sep 2009 12:10:22 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 5 Sep 2009 12:10:22 -0000 Received: (qmail 7499 invoked by uid 500); 5 Sep 2009 12:10:22 -0000 Delivered-To: apmail-incubator-uima-user-archive@incubator.apache.org Received: (qmail 7447 invoked by uid 500); 5 Sep 2009 12:10:22 -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 7436 invoked by uid 99); 5 Sep 2009 12:10:22 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 05 Sep 2009 12:10:22 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of msa@schor.com designates 69.93.164.2 as permitted sender) Received: from [69.93.164.2] (HELO gateway04.websitewelcome.com) (69.93.164.2) by apache.org (qpsmtpd/0.29) with SMTP; Sat, 05 Sep 2009 12:10:10 +0000 Received: (qmail 15255 invoked from network); 5 Sep 2009 12:20:34 -0000 Received: from gator74.hostgator.com (67.18.27.130) by gateway04.websitewelcome.com with SMTP; 5 Sep 2009 12:20:34 -0000 Received: from d24-235-153-40.home1.cgocable.net ([24.235.153.40]:2684 helo=[192.168.1.101]) by gator74.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Mju5W-00031W-5D for uima-user@incubator.apache.org; Sat, 05 Sep 2009 07:09:50 -0500 Message-ID: <4AA2550A.80602@schor.com> Date: Sat, 05 Sep 2009 08:09:46 -0400 From: Marshall Schor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: uima-user@incubator.apache.org Subject: Re: Problem with multiple type identifiers when loading pears References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator74.hostgator.com X-AntiAbuse: Original Domain - incubator.apache.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - schor.com X-Virus-Checked: Checked by ClamAV on apache.org 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). -Marshall