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

Reply via email to