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 typing:
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. -Marshall 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 <r...@apache.org> wrote: >>> >>> On 20.10.2016, at 21:27, Marshall Schor <m...@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 >
