Hi all, I also found the external resources part a bit confusing when I did the external resources support for uimaFIT...
If I remember correctly, then there is at least one place in uimaFIT where I do rely on type erasure in order to smuggle some class object through that does actually not fit the generic type defined in uimaFIT... ... I am not proud of it, but it works. > On 21.10.2016, at 16:09, Marshall Schor <m...@schor.com> wrote: > > 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(); +1 > I plan to revert the change that required InnerImplementation classes to > implement Resource, along these lines. +1 So here are some good/bad things about "customResourceSpecifier" [+] it allows arbitrary InnerImplementation [+] no need to implement Resource [+] no mandatory built-in "properties" (like e.g. the setUrl in configurableDataResourceSpecifier) [-] no life-cycle events, in particular no destroy() [-] only string parameters ... and here some good/bad things about "configurableDataResourceSpecifier" [+] life-cycle events [+] same type of parameters (String, bool, lists, etc.) as for AEs etc. in UIMA [-] mandatory built-in "properties" (setUrl()); What I would really find useful would be a "configurableResourceSpecifier" with these properties: [+] gets life-cycle events (if it implements Resource interface, otherwise not) [+] same type of parameters (String, bool, lists, etc.) as for AEs etc. in UIMA [+] no mandatory properties (like setUrl()) Cheers, -- Richard
