uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: messed up the impl of UIMA-2977 - calling destroy() method on External Resources
Date Fri, 21 Oct 2016 14:09:02 GMT
Hi Richard (and other interested parties),

First, in order to make this discussion clearer, I'm going to define a new term,
"InnerImplementation", to refer the class specified as the element
"implementationName" in the externalResource. 

The externalResource spec has
  * name
  * description
  * one of a choice of 5 specifier kinds:
    fileResourceSpecifier, fileLanguageResourceSpecifier,
customResourceSpecifier, configurableDataResourceSpecifier, and uriSpecifier
  * implementationName (which is optional)

The one-of-5 specifier kinds are made into objects that implement Resource,
using the produceResource mechanism of UIMA.  But this says nothing about
whether or not the InnerImplmentation implements Resource.

Only the customResourceSpecifier is documented as requiring the
InnerImplementation implement Resource.  We have examples in UIMA where the
InnerImplementation does not implement Resource; it is only required that the
InnerImplementation class implements the interface specified in the associated
bindings (this is checked by the framework).

Based on your observation, it looks like I was wrong to conclude that the
existence of an assignment of the InnerImplementation class to a variable
declared to be of type Class<? extends Resource> was checking for this.  So
existing code, for external resources other than customResourceSpecifier kinds,
may have InnerImplementation classes that don't implement Resource.

The ResourceManager, when preparing the tables it uses to return the resource
instance when getResource(...) is called, stores the implementationName (if
there is one), and that's what's returned from getResource(...).

The new "getExternalResources()" API which returns a list of all the external
resources managed by a ResourceManager, will then have a set of objects with no
common super type or interface.  Some of these might implement Resource, others
not. Some might implement SharedResourceObject, others not.

The new "destroy()" method on ResourceManager will have to filter the
propagating of this to the external resources in this list, only doing this call
for InnerImplementations that implement the destroy() method.  There's no API
other than "Resource" for declaring this, so I propose to use this in filtering
the destroy calls, something like:
  if (candidate instanceof Resource) ((Resource)candidate).destroy();

I plan to revert the change that required InnerImplementation classes to
implement Resource, along these lines.

What do you think?

-Marshall

On 10/20/2016 3:45 PM, Richard Eckart de Castilho wrote:
> The uimaFIT ExternalResourceFactoryTest has examples of resources that
> derive from Resource and others that derive from SharedResourceObject.
>
> Cheers,
>
> -- Richard
>
> https://svn.apache.org/repos/asf/uima/uimafit/trunk/uimafit-core/src/test/java/org/apache/uima/fit/factory/ExternalResourceFactoryTest.java
>
>> On 20.10.2016, at 21:29, Richard Eckart de Castilho <rec@apache.org> wrote:
>>
>> On 20.10.2016, at 21:27, Marshall Schor <msa@schor.com> wrote:
>>> The interesting part is the Java type of the returned value - it is specified
as
>>>
>>> Class<? extends Resource>
>>>
>>> which will throw a cast exception if the implementing class can't be cast to
>>> Resource. 
>> I believe due to type erasure, this does not throw a cast exception as long
>> as the value is a Class.
>>
>> Best,
>>
>> -- Richard
>


Mime
View raw message