Some more thoughts on the details of the design:
The use of <propertyref> *in addition to* <value> in our descriptor XML seems
good in that it could be defined so that <value> provides a "default" value to
use in case <propertyref> didn't have a setting.
But in this case, it might be good to issue a warning - in case the setting was
accidentally omitted.
(You might also want to have a warning if some properties were defined but never
used).
If the parameter is overridden by a containing aggregate, I assume that override
would still be in force? Or is the intent to allow "reaching in" to contained
delegates and having that override containing aggregate specifications?
A little utility which showed what the actual parameters, in force, for a
particular aggregate + override property file, would be good - something like
maven's help:effective-pom. This utility could also show what properties were
defined / not used, and what was specified in the properties file as a key, but
not matched in the descriptor.
(From discussion with others) it would be maybe nice to allow a <propertyref>
value to be a string which contains ${xxx}'s in it - so one could write
<propertyref>${baseDirectory}/a/b/${model}</propertyRef> as a value - in other
words, allowing string concatenation and multiple ${xxx}s to be used to make up
the string representation of the value.
Many other languages allow both ${xxx} and $xxx - the latter for cases where the
xxx's are limited to chars + numbers + maybe underscores, dashes, and periods;
the first character not allowed "stops" the parsing of the name. You still need
the {} form for such things like ${xxx}yyy or for ${x!_($*} (if you want to
allow that as a "name" - property files do, apparently).
-Marshall Schor
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
>
