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 <jtatria@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 <rec@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 <jtatria@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
|