issue with the default no-arg constructor...

[Jim - FooBar();]

HI everyone,


is there any way to tell uima which constructor to use when
instantiating annotators?
Is it possible to make such a decision at runtime and provide the
arguments as configuration-data perhaps?
the 0-arg constructor is no good when someone needs to pass some
parameters in.

I'm literally on the verge of giving up with uima+Clojure...I ended up
writing my UIMAProxy in Java with the hope that UIMA would complain
less, but I need that extra constructor to pass in the functions that
will do the actual work...therefore I need to tell the framework "use
this constructor with these parameters"...can uimafit help here?

thanks a lot...

Jim

[Jens Haase]

Hi Jim,

if I remember correctly you never create a Annotator directly in UIMA by calling the constructor.

Instead you can use AnalysisEngineFactory.createPrimitive(...) methods of uimafit. But I do not

now if this will help you with your clojure approach.

Here is an example: http://code.google.com/p/uimafit/wiki/GettingStarted#Running_the_analysis_engine

By the way, I would be very interested in a small tutorial/code example of how you use clojure with

UIMA.

Cheers,

Jens

[Richard Eckart de Castilho]

Hi,

> is there any way to tell uima which constructor to use when instantiating annotators?
> Is it possible to make such a decision at runtime and provide the arguments as configuration-data perhaps?
> the 0-arg constructor is no good when someone needs to pass some parameters in.

UIMA always uses the no-args constructor. Parameters are passed in via the UIMAContext. uimaFIT takes care of extracting these parameters and filling them into fields annotated with @ConfigurationParameter.

Maybe you want to have a look at the ClosureResourceProvider [1] of DKPro Lab. I did that as a helper to pass functions (Closures) as parameters into UIMA components in Groovy.

> I'm literally on the verge of giving up with uima+Clojure…I ended up writing my UIMAProxy in Java with the hope that UIMA would complain less, but I need that extra constructor to pass in the functions that will do the actual work...therefore I need to tell the framework "use this constructor with these parameters"...can uimafit help here?

UIMA components are not Java beans. uimaFIT can help in that respect that you can have some "adapter" class which is a bean to which you pass the parameters, which then in turn calls the UIMA AnalysisEngineFactory after all parameters are set and creates an AE or AE descriptor for your component with these parameters set. Been there, done that, built a nice little framework for doing parameter sweeping and it's working with UIMA too, but it's Groovy, not Clojure, called DKPro Lab.

Cheers,

-- Richard

[1] http://code.google.com/p/dkpro-lab/source/browse/de.tudarmstadt.ukp.dkpro.lab/de.tudarmstadt.ukp.dkpro.lab.groovy/src/main/groovy/de/tudarmstadt/ukp/dkpro/lab/groovy/uima/ClosureResourceProvider.java

[Richard Eckart de Castilho]

>> I'm literally on the verge of giving up with uima+Clojure…I ended up writing my UIMAProxy in Java with the hope that UIMA would complain less, but I need that extra constructor to pass in the functions that will do the actual work...therefore I need to tell the framework "use this constructor with these parameters"...can uimafit help here?
>
> UIMA components are not Java beans. uimaFIT can help in that respect that you can have some "adapter" class which is a bean to which you pass the parameters, which then in turn calls the UIMA AnalysisEngineFactory after all parameters are set and creates an AE or AE descriptor for your component with these parameters set. Been there, done that, built a nice little framework for doing parameter sweeping and it's working with UIMA too, but it's Groovy, not Clojure, called DKPro Lab.

Lie! DKPro Lab is written in Java with a special support module for Groovy, in particular for Closures!

-- Richard