[
https://issues.apache.org/jira/browse/UIMA-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649727#action_12649727
]
Marshall Schor commented on UIMA-1107:
--------------------------------------
I've done some experiments taking the approach (1, prev comment), where I
modified the UIMA_Context to allow it to hold overriding version of the
Resource Manager. Unfortunately, the ResourceManager holds a lot of other
things, which need to be held just once, at the top level. An example of this
is the type system that is built up from all the component metadata.
To solve this problem, I created subclass of ResourceManager_impl, which has
private fields representing the overridden classpath/data path parts, and
shares all the other fields with its parent; this seems to work.
ResourceManager_impl is one of the classes created using the UIMAFramework
factory mechanism, meaning that the class name for this class can be
overridden. The mechanism for this solution, however, now depends on the
particular implementation of this class.
How important is it to preserve the flexibility to substitute different
implementations of ResourceManager into UIMA using the
UIMAFramework.newDefaultResourceManager()? If this is important, I could add a
new method here, UIMAFramework.newDefaultResourceManagerPearWrapper() ....
My opinion is that I think nobody is using the UIMA Factory capability to
substitute certain parts of UIMA with other classes (Please speak up if that's
not true!).
> Annotator context not set when annotator loaded from PEAR
> ---------------------------------------------------------
>
> Key: UIMA-1107
> URL: https://issues.apache.org/jira/browse/UIMA-1107
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
> Affects Versions: 2.2.2
> Reporter: Aaron Kaplan
> Assignee: Marshall Schor
> Fix For: 2.3
>
>
> I have an aggregate annotator consisting of an annotator A1 that creates a
> new sofa, and an annotator A2 that annotates the new sofa. A2 is not
> sofa-aware, so in the aggregate descriptor I have defined a sofa mapping.
> In the delegateAnalysisEngine element of the aggregate descriptor, if I point
> to A2's component descriptor (A2/desc/A2.xml), the sofa mapping works: A2
> processes the new sofa created by A1. If I point instead to A2's pear
> installation descriptor (A2/A2_pear.xml), the sofa mapping seems not to be
> applied: A2 processes the initial sofa instead.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
