Hi José, the least hackish solution within uimaFIT may be to use type-conversion on the String parameters in a similar way we do it for types not supported as parameters for normal components (e.g. File, Pattern, URL, etc.).
Cf. ConfigurationParameterFactory.convertParameterValue(...) The difference here would be that also boolean and numeric types would need to be converted to/from strings, whereas that is not necessary on UIMA component parameters. Cheers, -- Richard > On 21.10.2015, at 18:21, José Tomás Atria <jtat...@gmail.com> wrote: > > Hi Richard, > > Thanks for your response. I'll take a look into it and see if there is > non-too-hackish way of working around that limitation in the uimafit > factory that does not involve changes to the underlying uima code... I'll > report if I come up with something :) > > best, > jta > > On Tue, Oct 20, 2015 at 2:22 PM, Richard Eckart de Castilho <r...@apache.org> > wrote: > >> Hi, >> >> UIMA supports different types of resource specifiers that can be used >> for external resources. Some of them support the same types of >> parameters as regular UIMA components, other support only String >> parameters. >> >> If you look a bit up from line 177, you'll see another part of an if >> statement which does not the cast - which is for resources created through >> a ConfigurableDataResourceSpecifier. >> >> At the time I wrote this, I didn't find a way to convince UIMA to accept >> non-String parameters on other kinds of resources... unless I guess I >> would have had to make changes to the factoryConfig.xml file and actually >> implement a new kind of specifier. >> >> See also https://issues.apache.org/jira/browse/UIMA-2978 >> >> Maybe you have an idea how to solve this ;) >> >> Best, >> >> -- Richard >> >>> On 20.10.2015, at 19:01, José Tomás Atria <jtat...@gmail.com> wrote: >>> >>> I had posted the message below to the old uimafit-users list and didn't >>> notice it was no onger being used. See message below. >>> >>> ===== >>> >>> Hello, >>> >>> i just noticed that the method for creation of analysis engines and >>> external resources is different. >>> >>> For AE's, this works: >>> >>> AnalysisEngineFactory.createEngineDescription( >>> SomeEngine.class,SomeEngine.PARAM_BOOLEAN, true >>> ) >>> >>> But for external resources, the same syntax fails with a >> ClassCastException >>> >>> ExternalResourceFactory.createExternalResourceDescription( >>> SomeResource.class, SomeResource.PARAM_BOOLEAN, true >>> ) >>> >>> Looking at the code, I see that >>> ExternalResourceFactory.createExternalResourceDescription(String,Class<? >>> extends Resource>,Object...), which is called by the method above, >> actually >>> casts parameter values to String on line 177. >>> >>> Why is this so? Wouldn't it be preferable to have a consistent interface >>> for all component types? >>> >>> Thanks! >>> jta >> >> > > > -- > entia non sunt multiplicanda praeter necessitatem