[jira] Commented: (UIMA-1107) Annotator context not set when annotator loaded from PEAR

["Marshall Schor (JIRA)" <ui...@incubator.apache.org>]

    [ https://issues.apache.org/jira/browse/UIMA-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648317#action_12648317 ] 

Marshall Schor commented on UIMA-1107:
--------------------------------------

h2.Summary of the chronology of this issue and the related issue UIMA-1150

# First bug reported: Sofa mappings not being passed to Pear-wrapped annotators
# Fix: change the pear wrapper initialize() method, where it creates the inner analysis engine, to include the aAdditionalParams, which has the sofa mappings in the UIMA_CONTEXT, when calling the produceAnalysisEngineMethod (see svn link above).
# This broke some unit tests, reported in UIMA-1150. This was because the wrapped analysis engine got its resource manager from the passed-in UIMA_CONTEXT, ignoring the passed-in Resource Manager.
# The fix for this was to exclude the UIMA_CONTEXT from the aAdditionalParams.  This, now, broke the sofa mappings.

There are two (maybe more) alternatives for fixing this, going forward.  
# Change the mechanism for obtaining the ResourceManager, to allow it to be overridden in child instances of the UIMA_CONTEXT.
# Build a new UIMA_CONTEXT and pass it in.  This would have the new ResourceManager, plus *selected* values from the current UIMA_CONTEXT.

In any case, from a user point of view, are there any values (besides the Classpath, Datapath) that should be kept isolated from the wrapped Pear annotator?  The candidates to consider are:
* The configuration parameters
* The logger / instrumentation facilities
* Access to external resources (that are explicitly declared in externalResourceDependencies)
* Access to Session information
* Sofa maps (this is what's missing directly in this Jira - so this would not be kept isolated)
* CAS Pools for CAS multipliers

Which of these from the surrounding UIMA_CONTEXT should-or-could be made available to the PEAR (besides the sofa maps)?  
Which of these won't work if made available to the PEAR?
Are the sofa mappings passed in as part of the UIMA_CONTEXT or as separate "additionalParameters" items, or both?

Thanks in advance for knowledgeable opinions :-)

> 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.