From uima-user-return-2665-apmail-incubator-uima-user-archive=incubator.apache.org@incubator.apache.org Wed Nov 18 11:40:43 2009 Return-Path: Delivered-To: apmail-incubator-uima-user-archive@minotaur.apache.org Received: (qmail 2973 invoked from network); 18 Nov 2009 11:40:42 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 18 Nov 2009 11:40:42 -0000 Received: (qmail 97244 invoked by uid 500); 18 Nov 2009 11:40:42 -0000 Delivered-To: apmail-incubator-uima-user-archive@incubator.apache.org Received: (qmail 97173 invoked by uid 500); 18 Nov 2009 11:40:42 -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 97161 invoked by uid 99); 18 Nov 2009 11:40:42 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Nov 2009 11:40:42 +0000 X-ASF-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of msa@schor.com designates 67.18.16.74 as permitted sender) Received: from [67.18.16.74] (HELO gateway06.websitewelcome.com) (67.18.16.74) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 18 Nov 2009 11:40:40 +0000 Received: (qmail 31921 invoked from network); 18 Nov 2009 11:57:33 -0000 Received: from gator74.hostgator.com (67.18.27.130) by gateway06.websitewelcome.com with SMTP; 18 Nov 2009 11:57:33 -0000 Received: from ool-44c6c63b.dyn.optonline.net ([68.198.198.59]:9184 helo=[192.168.1.100]) by gator74.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1NAitW-000766-CJ for uima-user@incubator.apache.org; Wed, 18 Nov 2009 05:40:18 -0600 Message-ID: <4B03DD25.9060408@schor.com> Date: Wed, 18 Nov 2009 06:40:21 -0500 From: Marshall Schor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: uima-user@incubator.apache.org Subject: Re: Overriding parameters in UIMA-AS References: <4B03D277.2080808@ilsp.gr> In-Reply-To: <4B03D277.2080808@ilsp.gr> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-7 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 Prokopis Prokopidis wrote: > Hello all, > > I have a UIMA-AS service associated with an aggregate AE, and I am > currently calling it with client code that is a modification of the > RunRemoteAsyncAE.java. All the primitive AEs are co-located. > > Now, I would like to override the parameter of one of the primitive > AEs (e.g. set a "useThisResource" parameter to true or false) from the > client code, and have the CAS'es processed accordingly. > > Is this possible? I've read in the UIMA-AS doc (1.4.4.2) that > "Parameter overrides only work for co-located delegates". Are there > any other docs that elaborate on how to achieve this? Parameters in UIMA are set up as part of the initialization (or reinitialization) of a component. For UIMA-AS, if you have components operating as a remote service, they can, in the general case, be servicing multiple clients. So, for instance, a service might be started (with some set of parameters) and then one or more clients could come and go, each connecting to that service (which could of course be scaled out), and each with potentially different "parameter" needs. When the service is started, it has its own set of descriptors; and these can specify overrides, but the started up service can then be used by many clients. So there's a mismatch between this kind of life-cycle arrangement and using parameters to override things by a particular client. To work around this, you can insert into the CAS additional "control" information, and then have your implementation read and act upon that. With this approach, having multiple clients using the same service, each with potentially different settings for "parameters" will work. HTH. -Marshall > > Thanks in advance, > > Prokopis > > >