uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: Test case failing
Date Thu, 14 Aug 2008 21:34:05 GMT

Adam Lally wrote:
> On Wed, Aug 13, 2008 at 5:23 PM, Marshall Schor <msa@schor.com> wrote:
>> Some analysis:
>> The test constructs an aggregate descriptor, having a Pear Specifier as one
>> of the delegates.
>> ASB_impl iterates through all of the aggregates delegates, (as part of the
>> produceResource method) and calls produceAnalysisEngine on each delegate.
>> This goes thru the CompositeResourceFactory_impl, which looks at its list of
>> produceResource impls for one that matches, and ends up dispatching to
>> SimpleResourceFactory.produceResource, for the PearSpecifier_impl.
>> This (correctly) instantiates a PearAnalysisEngineWrapper class instance for
>> this.
>> The initialize method of the wrapper calls getResourceManager() which
>> returns null (line 176).
> Well, that code seems wrong to me.  It looks like
> this.getResourceManager() will always return null.
> PearAnalysisEngineWrapper.initialize never calls super.initialize
Yes, it does call this on line 215 - it just hasn't called it *yet* :-)
The intent appears to be to get the containing aggregate's (or perhaps 
the application's) Resource Manager, not the resource manager that will 
be made for the Pear (see comment below on caching).
> (perhaps there is some reason why not, I don't know), and I think that
> calling super.initialize would be necessary to allow
> this.getResourceManager() to work.

Calling super.initialize will call:
  1) AnalysisEngineImplBase's initialize, which will:
     a) call it's super.initialize (see #2 next)
     b) add its metadata to the cas manager
     c) set jmx stuff, mbeanServer things from additional params.

  2) Resource_Impl Base's initialize, which will
     a) throw error if already initialized
     b) get or create the UimaContextAdmin from the additionalParameters
        If creating one, it will use the additionalParameters' 
ResourceManager (which is the aggregates' RM, not the Pear's) - but, in 
this case, there already is a UimaContextAdmin

>> It creates an innerRM - the resource manager it will use, from the pear's
>> classpath and datapath, on line 184.
>> It then calls produceAnalysisEngine, passing in both the innerRM which does
>> have the class loader set to the right place (a temp dir where the class
>> file is), plus additionalParams, which *also* has a resource manager (the
>> containing aggregate's ).
> This is the problem.  It doesn't work to just pass the
> aAdditionalParms map to the wrapped analysis engine (which was
> introduced in UIMA-1107 without appropriate testing).  The way the
> PEAR Wrapper was originally designed, the wrapped AE is supposed to be
> completely insulated from the aggregate that contains it, but this is
> now broken.
> All AEs within a single (possibly nested) aggregate share the same
> RootUimaContext, and it's at the RootUimaContext where the
> ResourceManager is attached.  So all AEs in a single aggregate must
> share the same ResourceManager.  Since we don't want that behavior,
> the PEAR Wrapper cannot share the same RootUimaContext.  But when you
> pass along aAdditionalParams, that's exactly what happens - one of the
> things in aAdditionalParams is the parent UimaContext to use.
> To fix UIMA-1107, which is about passing the Sofa mappings through,
> the wrapper should extract the Sofa mappings from the parent's
> aAdditionalParms and pass just those along to the wrapped AE.
I think something more complex is being attempted in the 
PearAnalysisEngineWrapper.  It's call to "this.getResourceManager()" on 
line 176, is supposed to return the containing aggregate's Resource 
Manager.  The PearAnalysisEngineWrapper appears to be using a map 
"cachedResourceManagers" as follows:

 cachedResourceManagers map key is the containing aggregate's resource 
manager.  The value is another map: Key = string-pair of 
classPath/DataPath for the Pear, value is the corresponding 
ResourceManager set up for that classPath/dataPath.

  This cache seems to be attempting to avoid re-creating the 
ResourceManager when the classpath/datapath are the same.

It sounds like you are saying that passing both a ResourceManager and a 
UimaContext in additional parameters to produceAnalysisEngine, results 
in the passed-in ResourceManager begin ignored because one is already 
"attached" to the UimaContext - is that right?

>   -Adam

View raw message