Return-Path: Delivered-To: apmail-incubator-uima-user-archive@locus.apache.org Received: (qmail 55606 invoked from network); 31 Aug 2007 06:37:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 31 Aug 2007 06:37:10 -0000 Received: (qmail 75394 invoked by uid 500); 31 Aug 2007 06:37:05 -0000 Delivered-To: apmail-incubator-uima-user-archive@incubator.apache.org Received: (qmail 75265 invoked by uid 500); 31 Aug 2007 06:37:05 -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 75256 invoked by uid 99); 31 Aug 2007 06:37:05 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Aug 2007 23:37:05 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_HELO_PASS,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [212.227.126.188] (HELO moutng.kundenserver.de) (212.227.126.188) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 31 Aug 2007 06:37:00 +0000 Received: from blueice1n1.de.ibm.com [195.212.29.163] (helo=[9.152.14.86]) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1IR07R3Zea-0000lw; Fri, 31 Aug 2007 08:36:38 +0200 Message-ID: <46D7B6F2.7080302@michael-baessler.de> Date: Fri, 31 Aug 2007 08:36:34 +0200 From: Michael Baessler Reply-To: mba@michael-baessler.de User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: uima-user@incubator.apache.org Subject: Re: UIMA 2.2 Class Loader References: <46D63BC7.3020205@schor.com> <46D68732.6070800@michael-baessler.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1/STiYonsnT2kQXt4hN2aekOguhi0P4LkiVNzC QVeroHypEs/wq9ApnKYH7pv4IWJ7OZbhRMbdex2QG5rH8IiaB5 SdVDLeTQfq2ZDNnPWCWWw== X-Virus-Checked: Checked by ClamAV on apache.org Adding the PEAR descriptor as delegate to a aggregate AE should work. I have tested this successfully. PEAR descriptors can be used similar to a primitive or aggregate AE descriptor. If that doesn't work please provide me some detailed information about the error. You can also try for testing to load the PEAR descriptor directly in the CVD or DocumentAnalyzer tooling. That should also work. So you can verify that the PEAR descriptor referring an AE works as expected. Hope that helps. -- Michael Danai Wiriyayanyongsuk wrote: > Thanks Michael. Yes, I have my primitive engines available as PEAR files. I > also have the auto-generated PEAR descriptors. > > Michael's Quote: "This descriptor have to be used in the aggregate to refer > to the primitive AEs." > Question: How to refer the PEAR descriptors to their primitive AEs in the > aggregate? Is it documented somewhere? In the aggregate AE description, I > tried to specify the location of the PEAR descriptors in > "delegateAnalysisEngine/import" but didn't work. > > Thanks, > Danai Wiriyayanyongsuk > > > On 8/30/07, Michael Baessler wrote: > >> Are your primitive engines available as PEAR files? That is needed since >> only if you have them as PEAR files >> you can use the PEAR descriptor. >> >> After you have installed the PEAR files a PEAR descriptor is >> automatically generated (located in the install directory). This >> descriptor have to >> be used in the aggregate to refer to the primitive AEs. >> >> -- Michael >> >> Danai Wiriyayanyongsuk wrote: >> >>> Thanks Marshall for the information and for asking :) >>> >>> What I have tried is that I have a description of an aggregate analysis >>> engine which has 4 primitive analysis engine defined. Those primitive AE >>> descriptions are all fully defined (no imports) under the >>> "delegateAnalysisEngine/analysisEngineDescription" tag. I do this >>> >> because >> >>> those primitive AE descriptions are generated on the fly. For one thing, >>> each primitive AE has its own PEAR-compliant directory. In this case, I >>> could not figure out how to tell UIMA the location those directories. >>> >>> Excerpt from section 5.8 in the UIMA References page: >>> "As of version 2.2, the framework supports component descriptors which >>> >> are >> >>> PEAR descriptors. These descriptors define components plus include >>> information on the class path needed to run them." >>> Question: To get the individual class loader for each primitive AE >>> >> defined >> >>> in an aggregate AE, do we have to specify/map the PEAR descriptor >>> (_pear.xml?) for each of every primitive AE? If so, where >>> >> and >> >>> how to do it? >>> >>> Any comments/recommendations would be appreciated. >>> >>> Thanks, >>> Danai Wiriyayanyongsuk >>> >>> >>> >>> On 8/29/07, Marshall Schor < msa@schor.com> wrote: >>> >>> >>>> Version 2.2 includes support for aggregates composed of PEAR >>>> descriptors, which include the class path information. >>>> >>>> This should allow you to run a pipeline where each annotator could have >>>> different versions of classes. >>>> See >>>> >>>> >>>> >> http://incubator.apache.org/uima/downloads/releaseDocs/2.2.0-incubating/docs/html/references/references.html#ugr.ref.jcas.pear_support >> >>>> Is that what you're trying to do? >>>> >>>> -Marshall >>>> >>>> Danai Wiriyayanyongsuk wrote: >>>> >>>> >>>>> Hi Guys, >>>>> >>>>> I'd like to ask a couple of questions regarding the classloader in >>>>> >> UIMA >> >>>> 2.2. >>>> >>>> >>>>> For an aggregate analysis engine, is there a way to have/set different >>>>> >>>>> >>>> class >>>> >>>> >>>>> loaders for each aggregated primitive analysis engines, so that the >>>>> >>>>> >>>> classes >>>> >>>> >>>>> won't interfere each others? >>>>> >>>>> If there is so, could you please shed some light how to do it? I've >>>>> >>>>> >>>> looked >>>> >>>> >>>>> into the source code and documentation but no luck :( >>>>> >>>>> Many Thanks, >>>>> Danai Wiriyayanyongsuk >>>>> >>>>> >>>>> >>>>> >>> >> > >