Ok, but I mean actually in code. How would it look like? - how to specify one "object B" as a parameter to another "object A" and finally "object A" to a component? - how to set non-String parameters? - while setting parameters, how to disambiguate between multiple instances of a such a shared resource?
Cheers, -- Richard > On 19.10.2016, at 19:22, Marshall Schor <m...@schor.com> wrote: > > re: how to realize the scenarios illustrated in [1] could be implemented > using the External Configuration parameters? > > Here's the high level thoughts: > > 1) Implementor designs several "objects" that require configuration. They > decide on the configuration parameters, giving each of them unique names > (perhaps using a kind of package-naming-scheme). > > 2) Key assumption: These objects are to be UIMA Shared External Resources. > This means that > 2a) there is one instance shared among many things > 2b) there might be multiple instances if "parameterized" versions of the > external resource are being used (e.g. dictionary, parameterized by > language) > > 3) When a user puts a system together, it consists of a pipeline and a set of > these external resources, and an external configuration settings (usually a > file, but could be a computed Java Object, in general). > > 4) The framework runs; the external resources are created, some at > initialization time (for the pipeline component that is declaring it), some > at getResource( parameter) time, for parameterized resources (where, for > instance you don't know the language until you get a CAS with a document and > determine it). > > 5) When the resource code starts running, it sees that it needs to read its > configuration parameters, so it gets the external settings object and reads > whatever parameters it wants to, using its unique key names. > > -------------- > Missing from this scenario is one of the things UIMA (but not uimaFIT) can > offer as a "feature" - the externalization into some metadata information > about configuration parameters. Note that this could be added - the external > resource could make use of the resourcMetaData xml element to specify > configuration parameter definitions. The UIMA framework currently ignores > these, but other tooling could make use of this, if it seems desirable. > > > Hoping that I've not overlooked some basic flaw, > > -Marshall > > On 10/19/2016 4:17 AM, Richard Eckart de Castilho wrote: >> Hi Marshall, >> >>> On 18.10.2016, at 23:28, Marshall Schor <m...@schor.com> wrote: >>> >>> Several Jiras talk about wanting external shared resources that can be >>> configured using the standard UIMA configuration settings and parameters. >>> >>> For example: https://issues.apache.org/jira/browse/UIMA-2979. >>> >>> Currently, there is one UIMA external resource descriptor that supports >>> this, >>> which is the configurableDataResourceSpecifier. It has a resourceMetaData >>> sub-element, which, in turn, has the configurationParameters and >>> configurationParameterSettings elements. >>> >>> There is an alternate, simpler approach to configuring external resources, >>> now >>> available (as of UIMA 2.9.0) - using direct access to the External >>> Configuration >>> parameters. See section 2.4.3.5 in the UIMA Reference book. The idea is >>> that >>> each External Resource would define its own set of key-value parameter >>> settings, >>> and retrieve them at run time. >> Could you comment how to realize the scenarios illustrated in [1] could be >> implemented >> using the External Configuration parameters? The point in these scenarios is >> having complex (potentially nested) objects that are composed and used to >> customize >> the behavior of one or more components. The objects take parameters and >> contain logic. >> >> Best, >> >> -- Richard >> >> [1] >> https://issues.apache.org/jira/browse/UIMA-2903?focusedCommentId=13708539&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13708539 >> >> >
