Am 10.06.2013 um 21:19 schrieb Marshall Schor <[email protected]>: >>> Additionally, ConfigurableDataResource_impl seems never to call >>> super.initialize(), so its mUimaContextAdmin is never initialized, hence >>> any getResourceManager() call returns null. >> This will take some more investigation / code research for me to offer any >> (hopefully useful) opinions... > ConfigurableDataResource seems to be an undocumented part of UIMA; I can't > find > any references to it in the tutorial or reference book. I see it has some > implementation, and even a test case. It also has an entry in the "xsd" for > UIMA component specifiers. > > UimaContext (from the Javadocs) applies to a subset of all resources. The > examples given are Annotators, Collection Readers, CAS Consumers, CAS > Initializers; these are things which are pipeline components (I should add, > Flow > Controllers are included). The purpose of the UimaContext is to give these > things access to data other than the CAS, including access to External > Resources > (of which ConfigurableDataResource is one kind).
Given that the Resource interface declares a getMetaData() method, I still think it'd be quite reasonable that all resources had meta data. You yourself commented that given Resource has a getResourceManager() method, it should be able to access a ResourceManager. > The ConfigurableDataResource seems to be a special case where its an External > Resource, but has MetaData (most other ExternalResources do not have this); so > it has a special way of setting up the metadata (outside of the UimaContext). If this expectation would had been met, the inferior parameter mechanism used in CustomResourceSpecifier (only Strings, no multi-valued parameters) wouldn't have been necessary. IMHO there shouldn't have been a need for a ConfigurableDataResource in the first place if Resource had already been configurable via meta data. > UimaContext has a way to get various attributes associated with External > Resources, but these methods all take a "key" (String) argument to identify > the > external resource. I'm not sure what you are trying to get at here. It is possible to get resources via a context instead of getting them directly from the ResourceManager. The context turns a resource name into a qualified resource name when looking up a resource. If my understanding is correct, this disambiguates the resource bindings within the resource manager, so that two components A and B can both declare a key K and I one can bind resource Foo to A.K and resource Bar to B.K. > There are two things a call to super.initialize() can set: the MetaData and > the > UimaContext references. The initialize method, instead of calling > super.initialize(), does an explicit call to set the MetaData reference, and > leaves the UimaContext reference null. > > If ConfigurableDataResource_impl called super.initialize(), the Resource > implementation of initialize() would think that the Resource was one which > should have, itself, a UIMA Context (and, therefore, have things like External > Resources, itself). I think this is the reason that the super method isn't > called. I see no reason why an external resource shouldn't be able to have external resources itself. In fact, me and some colleagues of mine find quite useful to work with such "nested" resources, which uimaFIT supports since version 1.4.0. Since UIMA doesn't allow declaring resource dependencies on resource, uimaFIT does these on the closest component. It uses a similar disambiguation as the UimaContext to allow binding to nested resources. Unfortunately, it currently has to resort to reflection in order to achieve nested resource support. I hope to be able replace this by something more official. Anyway… I suppose there is some agreement that a resource manager should be forwarded to external resources. Does that entail, that resource should actually have the means of accepting such a forwarded manager and that therefore resources inheriting from Resource_ImplBase should call super.initialize()? Otherwise, there wouldn't be much point in forwarding the manager in the first place. Of course uimaFIT would already profit from the simple forwarding, because current practice is to create custom external resources by inheriting from Resource_ImplBase. But there is also support for the SharedResourceObject-style of external resources, and there uimaFIT still wouldn't get the resource manager via the (Configurable)DataResource. Cheers, -- Richard [1] http://en.wikipedia.org/wiki/Liskov_substitution_principle
