[
https://issues.apache.org/jira/browse/UIMA-6386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Eckart de Castilho updated UIMA-6386:
---------------------------------------------
Description:
When initializing a component, then {{Resource_ImplBase}} sets the {{Session}}
of the {{ConfigurationManager}} of the current {{UimaContext}} using the
{{Session}} of the current {{UimaContext}}:
{org.apache.uima.resource.Resource_ImplBase.initialize(ResourceSpecifier,
Map<String, Object>)}
{code}
mUimaContextAdmin.getConfigurationManager()
.setSession(mUimaContextAdmin.getSession());
{code}
However, this can set the wrong session on the {ConfigurationManager}. In a
hierarchy of {UimaContexts}, there is only one {ConfigurationManager}
associated with the {RootUimaContext_impl}. The {ChildUimaContext_impl}
delegate to their respective root in their {getConfigurationManager()} methods.
So far so good.
But the {Session} of returned by {ChildUimaContext_impl.getSession()} is a
scoped {SessionNamespaceView_impl} instance which limits the view to the
parameters applicable to the child context. The problematic lines above cause
this scoped session view to be injected into the {ConfigurationManager} of the
{RootUimaContext_impl} which can cause configuration parameters at the root
level to become inaccessible.
At least, the code would need to be changed to
{code}
mUimaContextAdmin.getConfigurationManager()
.setSession(mUimaContextAdmin.getRootContext().getSession());
{code}
but instead of doing that, the code could probably also be change to inject the
session when creating the {RootUimaContext_impl} in the first place.
> Wrong session set on ConfigurationManager in aggregates
> -------------------------------------------------------
>
> Key: UIMA-6386
> URL: https://issues.apache.org/jira/browse/UIMA-6386
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
> Reporter: Richard Eckart de Castilho
> Assignee: Richard Eckart de Castilho
> Priority: Major
> Fix For: 3.2.1SDK
>
>
> When initializing a component, then {{Resource_ImplBase}} sets the
> {{Session}} of the {{ConfigurationManager}} of the current {{UimaContext}}
> using the {{Session}} of the current {{UimaContext}}:
> {org.apache.uima.resource.Resource_ImplBase.initialize(ResourceSpecifier,
> Map<String, Object>)}
> {code}
> mUimaContextAdmin.getConfigurationManager()
> .setSession(mUimaContextAdmin.getSession());
> {code}
> However, this can set the wrong session on the {ConfigurationManager}. In a
> hierarchy of {UimaContexts}, there is only one {ConfigurationManager}
> associated with the {RootUimaContext_impl}. The {ChildUimaContext_impl}
> delegate to their respective root in their {getConfigurationManager()}
> methods.
> So far so good.
> But the {Session} of returned by {ChildUimaContext_impl.getSession()} is a
> scoped {SessionNamespaceView_impl} instance which limits the view to the
> parameters applicable to the child context. The problematic lines above cause
> this scoped session view to be injected into the {ConfigurationManager} of
> the {RootUimaContext_impl} which can cause configuration parameters at the
> root level to become inaccessible.
> At least, the code would need to be changed to
> {code}
> mUimaContextAdmin.getConfigurationManager()
> .setSession(mUimaContextAdmin.getRootContext().getSession());
> {code}
> but instead of doing that, the code could probably also be change to inject
> the session when creating the {RootUimaContext_impl} in the first place.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
