uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eddie Epstein <eaepst...@gmail.com>
Subject Re: Configuration parameters (was Working on a new API to enable creation of UIMA AS deployment descriptors programmatically)
Date Wed, 06 Apr 2011 12:17:20 GMT
Implementing as a post-processing step does sound right. It would be
nice if the logic was in the core so that every execution engine could
just make a single method call. This would also allow an execution
environment to use separate properties files when instantiating
multiple AEs, as for example when the UIMA-AS client API does in
process deployment of services.

Thanks,
Eddie

On Tue, Apr 5, 2011 at 5:57 PM, Richard Eckart de Castilho
<eckartde@tk.informatik.tu-darmstadt.de> wrote:
> It sounds like this could easily be implemented as a post-processing step on an (aggregate)
descriptor.
>
> 1) load aggregate (descriptor) - AnalysisEngineDescriptor desc = ...
> 2) load properties - Properties config = ...
> 3) set configuration parameters in descriptor from values used in properties - applyConfiguration(desc,
properties);
>
> Such a feature could then be integrated into an execution engine like the CPE or UIMA-AS.
>
> Is that what you had in mind or did you think about a deeper integration into UIMA?
>
> Cheers,
>
> Richard
>
> Am 05.04.2011 um 22:44 schrieb Eddie Epstein:
>
>> We've also been discussing the need for a new mechanism to
>> set configuration values outside of descriptors. A rough idea is
>> to use Java properties with a notation that allows specification
>> of a parameter value at any level in a nested aggregate.
>>
>> For example, a single property file specified at runtime could
>> define all "non-default" parameter values in the aggregate.
>> This mechanism would bypass the need to create override
>> parameters for intermediate aggregates in order for a top
>> level parameter to specify a parameter value for a delegate
>> several layers below.
>>
>> Parameter overrides would still work, so that a single setting
>> at an upper level could specify the value to use in multiple
>> delegates.
>>
>> This approach would allow descriptors to become independent
>> of "application" version changes due to parameter value changes.
>>
>> Eddie
>>
>> On Tue, Apr 5, 2011 at 1:36 PM, Jörn Kottmann <kottmann@gmail.com> wrote:
>>> On 4/5/11 6:56 PM, Richard Eckart de Castilho wrote:
>>>>
>>>> Am 05.04.2011 um 18:34 schrieb Jörn Kottmann:
>>>>
>>>>> Yes, if you use UimaFIT the AE cannot run without it, which makes it
>>>>> difficult to use it in various solutions
>>>>> which use our APIs to embed an AE e.g. like the new Solr integration
>>>>> does, or am I mistaken?
>>>>
>>>> You can use uimaFIT factories for testing without using annotations and
>>>> without introducing a runtime dependency on uimaFIT.
>>>>
>>>> You can use uimaFIT annotations and uimaFIT's context injection helper and
>>>> still instantiate or run components in any manner you like. Your code will
>>>> not notice the presence of uimaFIT at all. However, it becomes a
>>>> runtime-dependency in this case. Since uimaFIT is licensed under Apache 2.0,
>>>> it should be compatible with UIMA/UIMA-AS at that point.
>>>>
>>>> Does this address your concerns?
>>>>
>>> Yes mostly,  but I still believe that we should have support for defining
>>> the configuration parameters and optionally injecting the
>>> values inside the framework itself.
>>>
>>> Jörn
>>>
>
> Richard Eckart de Castilho
>
> --
> -------------------------------------------------------------------
> Richard Eckart de Castilho
> Technical Lead
> Ubiquitous Knowledge Processing Lab
> FB 20 Computer Science Department
> Technische Universität Darmstadt
> Hochschulstr. 10, D-64289 Darmstadt, Germany
> phone +49 (6151) 16-7477, fax -5455, room S2/02/E225
> eckartde@tk.informatik.tu-darmstadt.de
> www.ukp.tu-darmstadt.de
> -------------------------------------------------------------------
>
>
>
>
>
>

Mime
View raw message