Alternative to inheriting from org.uimafit.component.JCasAnntator_ImplBase

[croeder6000]

I'm working to adapt some code, that's not mine, an AE, to uimaFIT with 

parameter annotations. As a first stab, I'd like to avoid modifying it,

so the first solution below is out. The problem I'm running into is that to 

use an AE with uimaFit, it needs to inherit from uimaFIT's JCasAnnotator_ImplBase.

I see a few solutions:

- modify the AE's code to inherit from uimaFIT's base instead of UIMA's

- cast it

- modify uimaFIT so that AnalysisEngineFactory.createAnalysisEngineDescription can take

  an AE that inherits from UIMA, but implements a marker interface to show that it 

  is calling ConfigurationParameterInitializer.initialize() and 

ExternalResourceInitializer.initialize().

thoughts? am I missing something?

-Chris

[Richard Eckart de Castilho]

Hi Chris,

sounds like what you need/want are mainly default values for parameters, so that uimaFIT can generate valid descriptors. You can subclass the AE and introduce dummy fields to carry the @ConfigurationParameter annotations. The AE does already contain code to read the parameter values from the UIMA context, so you don't have to worry about ConfigurationParameterInitializer and ExternalResourceInitializer.

I recently used that approach to make the TextMarker AE more usable with uimaFIT:

http://code.google.com/p/dkpro-core-asl/source/browse/de.tudarmstadt.ukp.dkpro.core-asl/trunk/de.tudarmstadt.ukp.dkpro.core.textmarker-asl/src/main/java/de/tudarmstadt/ukp/dkpro/core/textmarker/TextMarker.java

Cheers,

-- Richard

> --
> You received this message because you are subscribed to the Google Groups "uimafit-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to uimafit-user...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Chris Roeder]

On 2/19/13 12:20 PM, Richard Eckart de Castilho wrote:
> Hi Chris,
>
> sounds like what you need/want are mainly default values for parameters, so that uimaFIT can generate valid descriptors. You can subclass the AE and introduce dummy fields to carry the @ConfigurationParameter annotations. The AE does already contain code to read the parameter values from the UIMA context, so you don't have to worry about ConfigurationParameterInitializer and ExternalResourceInitializer.

of course. I fixated on uimaFIT and forgot about the existing infrastructure.

thanks Richard, and thanks for the example
-Chris

>
> I recently used that approach to make the TextMarker AE more usable with uimaFIT:
>
> http://code.google.com/p/dkpro-core-asl/source/browse/de.tudarmstadt.ukp.dkpro.core-asl/trunk/de.tudarmstadt.ukp.dkpro.core.textmarker-asl/src/main/java/de/tudarmstadt/ukp/dkpro/core/textmarker/TextMarker.java
>
> Cheers,
>
> -- Richard
>
> Am 19.02.2013 um 20:12 schrieb croeder6000 <croed...@gmail.com>:
>
>> I'm working to adapt some code, that's not mine, an AE, to uimaFIT with
>> parameter annotations. As a first stab, I'd like to avoid modifying it,
>> so the first solution below is out. The problem I'm running into is that to
>> use an AE with uimaFit, it needs to inherit from uimaFIT's JCasAnnotator_ImplBase.
>>
>> I see a few solutions:
>> - modify the AE's code to inherit from uimaFIT's base instead of UIMA's
>> - cast it
>> - modify uimaFIT so that AnalysisEngineFactory.createAnalysisEngineDescription can take
>> an AE that inherits from UIMA, but implements a marker interface to show that it
>> is calling ConfigurationParameterInitializer.initialize() and
>> ExternalResourceInitializer.initialize().
>>
>> thoughts? am I missing something?
>> -Chris
>>
>> --
>> You received this message because you are subscribed to the Google Groups "uimafit-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to uimafit-user...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>

--
Christophe Roeder | Software Engineer
University of Colorado Anschutz Medical Campus | Computational Bioscience Program
303-724-7562 | chris....@ucdenver.edu | http://compbio.ucdenver.edu

[croeder6000]

Oh Joy. The AE in question is ConceptMapper and I see it is a 1.x style that inherits from the TextAnnotator lineage.

Can I assume the descriptors are different and this won't work?

I have code that uses XML descriptors, but am looking for a neat way to

avoid version conflicts between that code and some XSLT stuff I'm using.

...and it's odd having a uimaFIT style ConceptMapperFactory that relies

on the XML descriptor file from the distribution.

any ideas?

-Chris

[Richard Eckart de Castilho]

Am 19.02.2013 um 22:57 schrieb croeder6000 <croed...@gmail.com>:

> Oh Joy. The AE in question is ConceptMapper and I see it is a 1.x style that inherits from the TextAnnotator lineage.
> Can I assume the descriptors are different and this won't work?

Oh well, uimaFIT/UIMA should be able to deal nicely with that, but you need to fool the compiler. Try casting ConceptMapper.class to Class:

// fooling generic type checking
AnalysisEngineFactory.createPrimitive((Class) ConceptMapper.class);

uimaFIT should generate a nice modern descriptor. You still have to specify all the mandatory parameters in the createPrimitive(Description) call or using default values in @ConfigurationParameter annotations in your convenience-sub-class.

Is that what you are looking for?

Cheers,

-- Richard