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 15:22:21 GMT
I found another piece of evidence of confusion about this topic.

The old versions of ResourceManager interface API have a method
"getResourceClass", which is specified to return an instance with the generic

Class<? extends Resource>

If an InnerImplementation implements only SharedResourceObject and some
user-specified interface, but not Resource, then this is a wrong typing, but
Java ignores this.

I'll change this to return <N> Class<N> as part of the fix.


On 10/21/2016 10:09 AM, Marshall Schor wrote:
> 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
>>>> Class<? extends Resource>
>>>> which will throw a cast exception if the implementing class can't be cast
>>>> Resource. 
>>> I believe due to type erasure, this does not throw a cast exception as long
>>> as the value is a Class.
>>> Best,
>>> -- Richard

View raw message