[
https://issues.apache.org/jira/browse/UIMA-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15416697#comment-15416697
]
Richard Eckart de Castilho commented on UIMA-5043:
--------------------------------------------------
Well, there are different types of end-users, annotation implementors are one.
Pipeline implementors/deployers (that only use existing annotators) are an
example of another kind of end-user.
I think there should be a clear red flag that marks the boundary that marks
that things are scoped differently. UIMAFramework for example has a global
(static) scope. AFAIK UIMAContext is usually scoped to a component (which can
be an aggregate). Putting the word "Thread" into "getThreadContext()" makes the
scope of the returned context explicit: it is not the typical scope, but a
thread scope.
But considering this further, I believe that a UimaContextHolder following the
pattern used by Spring for holding thread-bound contexts (they have many of
them, e.g. SecurityContextHolder, LocaleContextHolder, RequestContextHolder,
etc.) is a good solution:
* it provides the clear read flag about scoping
* it doesn't change the API of existing classes
* it is very specifically focussed at solving the task of giving access to a
context without explicit chaining or dependency injection
There is already a getExternalOverrides() method in the UimaContextAdmin. So to
complete the changes for the annotator implementer, that method should also be
exposed through the UIMAContext interface.
No matter what access path to thread-bound external overrides is implemented,
the question remains what mechanisms can be used to set the overrides.
I still think that setting external overrides through a static mechanism like
system properties is not the way to go for UIMAJ-SDK. The mechanism to
initialize the external overrides from whatever source should be invoked
explicitly by the application/runtime context in which the UIMAJ-SDK is used,
e.g. by UIMA-AS or UIMA-DUCC or some other kind of application/runtime that
embeds the UIMAJ-SDK. The SDK can provide convenience methods to facilitate the
initialization of the external overrides (i.e.
Settings_impl.loadSystemDefaults()), but that method should not be called in
Resource_ImplBase but rather in the code that triggers the creation of a
component.
> Provide method to access individual external override settings
> --------------------------------------------------------------
>
> Key: UIMA-5043
> URL: https://issues.apache.org/jira/browse/UIMA-5043
> Project: UIMA
> Issue Type: Improvement
> Components: Core Java Framework
> Reporter: Burn Lewis
> Assignee: Burn Lewis
> Priority: Minor
> Fix For: 2.9.0SDK
>
>
> The framework loads the external override settings and uses them in any
> configuration parameter that has an external override name attached, Users
> have asked for the ability to access these values directly without the
> indirection of configuration parameter entries in descriptors. Currently the
> complete Settings object that holds all the external override settings loaded
> by the framework is accessible via UimaContextAdmin.
> An improvement would be to allow individual values to be read using a method
> in the UimaContext interface, perhaps:
> String getExternalOverride(String name)
> String[] getExternalOverrideArray{String name)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
