The proposal to add ${xxxx} kinds of things into descriptors is one way to
specify the parameter being overridden.
Another way is to have the properties file, itself, contain a direct
specification of the parameter being overridden, perhaps using the same syntax
we already use:
keyname1/keyname2/.../keynamen/propertyName = value
where the keyname1 ... n are the key names of the delegates in the aggregates.
There are pluses and minuses for both approaches. Here are some:
The same annotator component, using the same XML descriptor, might be included
in two different places in a big aggregate. With the ${xxx} approach, the
override would affect both, and it would not be possible to have different
overrides for each one (unless of course, you changed that component's
descriptor to, for example, use ${xxx} in one instance, and ${yyy} in the
other).
Using the keyname1/keyname2/... approach makes it pretty explicit, in one spot,
what is being overridden. The ${xxx} approach creates a bit of an indirection -
it would be necessary to grep through all the xml files, whereever they may be
located, to see what was being overridden.
-Marshall
On 7/22/2011 12:21 PM, Adam Lally wrote:
> On Wed, Apr 6, 2011 at 8:17 AM, Eddie Epstein <[email protected]> wrote:
>
>> On Tue, Apr 5, 2011 at 5:57 PM, Richard Eckart de Castilho
>> <[email protected]> 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.
>> 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.
>>
>>
> I think I will soon be ready to try implementing something like this
> (allowing setting configuration parameters from properties files). I am
> thinking there are a couple of extensions I may want to make in core UIMA.
>
> 1) I think one issue with the postprocessing-only apporach is that for
> non-string parameters, you cannot in your descriptor write something like:
> <value>
> <integer>${myPropertyName}</integer>
> </value>
> which would cause a parse error.
>
> So I am thinking of adding a new element in the descriptor syntax:
> <value>
> <propertyref>myPropertyName</propertyref>
> </value>
>
> This could be used for any parameter type. Also there is no ambiguity in
> case someone actually wanted to set their parameter to a string of the form
> ${....}.
>
> 2) It would be good if there was a way for existing UIMA applications
> (DocumentAnalyzer, CVD, and also our users' own applications) to support
> such descriptors, without having to add an extra line of code in all of them
> to resolve the properties. So, I'm imagining that the property replacement
> happens automatically in the core, when the AE is instantiated. We could
> define a system property to specify the configuration file (e.g.
> -Dorg.apache.uima.configuration_parameter_file=my.properties). I would also
> have a programmatic approach (like something in the additionalParams map
> when instantiating the AE), to support applications that need multiple
> configuration properties files in the same JVM.
>
> Thoughts?
>
> -Adam
>
