Hello Richard!
 
I would like to have a writer that writes all mentions of a given type. The 
type is given by name as a AE parameter. The way the mentions are formatted 
should be interchangeable. So the formatter varies and should be encapsulated 
as a AE resource (or maybe not?).

public class AnnotationWriter extends CasConsumer_ImplBase {
        public static final String PARA_TYPE_NAME = "typeName";

        /**
         * The name of the type whose mentions are to be written.
         */
        @ConfigurationParameter(name = PARA_TYPE_NAME, mandatory = true)
        private String mTypeName;

        /**
         * The type whose mentions are to be written.
         */
        private Type mType;

        public static final String RES_ANNOTATION_FORMATTER = 
"annotationFormatter";
        @ExternalResource(key = RES_ANNOTATION_FORMATTER, mandatory = true)
        private AnnotationFormatter mFormatter;

        @Override
        public void typeSystemInit(final TypeSystem typeSystem) throws 
AnalysisEngineProcessException {
                super.typeSystemInit(typeSystem);
                mType = typeSystem.getType(typeName);
        }
        
        @Override
        public final void process(final CAS cas) throws 
AnalysisEngineProcessException {
                /*
                 * Write all annotations of the given type.
                 */
                try (final Writer writer = // build a writer) {
                        for (final AnnotationFS annotation : 
CasUtil.select(cas, type)) {
                                
writer.append(mAnnotationFormatter.format(annotation));
                        }
                } catch (IOException cause) {
                        throw new AnalysisEngineProcessException(cause);
                }
        }
}


This is the interface for all formatters.

public interface AnnotationFormatter {
        String format(final AnnotationFS annotation);
}


This is a concrete implementation of a formatter. The problem is that this is 
not an external resource. There is no file, no dictionary, no data base 
connection, or what ever. It is just a simple object. Most likely, this is not 
how a UIMA resource should be used.

public class TsvAnnotationFormatter extends Resource_ImplBase implements 
AnnotationFormatter {
        public static final String PARA_FEATURE_NAMES = "featureNames";

        /**
         * This would be nice but does not work.
                 */
        @ConfigurationParameter(name = PARA_FEATURE_NAMES, mandatory = true)
        private String[] mFeatureNames;
        
        @Override
        public final String format(final AnnotationFS annotation) {
                // Pretty print the given features' values.
        }
} 

As you said, String[] works fine with SharedResourceObject. But 
SharedResourceObject demands a real resource to be loaded which I don't have.

There is a simple solution to this: Omit the pseudo resource and make 
featureNames a parameter of AnnotationWriter. I can still use the formatter 
interface but only internally to the writer. But I have to code a new writer 
for each annotation formatter. That works fine but is not the kind of 
modularization I would like to have.

Cheers,
Armin




-----Ursprüngliche Nachricht-----
Von: Richard Eckart de Castilho [mailto:r...@apache.org] 
Gesendet: Dienstag, 3. Juni 2014 16:05
An: user@uima.apache.org
Betreff: Re: uimafit - String[] parameter in Resource_ImplBase

Hi Armin,

is it a problem of injection (uimaFIT) or a problem of running as a managed 
component in a container context (UIMA)? I would assume the later. For further 
reference, it might be useful if you could provide an illustrative example.

Cheers,

-- Richard

On 03.06.2014, at 16:00, <armin.weg...@bka.bund.de> <armin.weg...@bka.bund.de> 
wrote:

> Hi,
> 
> I cancelled it. Actually, I don't have a resource. I just tried to modularize 
> my code a little bit. But uimafit's use of injection makes this difficult and 
> no fun at all.
> 
> Some people consider using injection to be a good programming style. I 
> personally hate it. It kills my highly modularized and reusable OO design.
> 
> Cheers,
> Armin
> 
> -----Ursprüngliche Nachricht-----
> Von: armin.weg...@bka.bund.de [mailto:armin.weg...@bka.bund.de]
> Gesendet: Montag, 19. Mai 2014 11:14
> An: user@uima.apache.org
> Betreff: AW: uimafit - String[] parameter in Resource_ImplBase 
> [Signatur gültig]
> 
> Hi Richard,
> 
> I will try that and report back.
> 
> Thanks
> Armin
> 
> -----Ursprüngliche Nachricht-----
> Von: Richard Eckart de Castilho [mailto:r...@apache.org]
> Gesendet: Montag, 19. Mai 2014 11:11
> An: user@uima.apache.org
> Betreff: Re: uimafit - String[] parameter in Resource_ImplBase
> 
> Hi Armin,
> 
> UIMA only supports simple String parameters on Resource_ImplBase. You can 
> alternatively implement SharedResourceObject and then you can also use 
> String[] and other types of parameters. There is some documentation on this 
> in the uimaFIT manual [1].
> 
> -- Richard
> 
> [1] 
> http://uima.apache.org/d/uimafit-current/tools.uimafit.book.html#d5e48
> 2
> 
> On 19.05.2014, at 11:03, <armin.weg...@bka.bund.de> 
> <armin.weg...@bka.bund.de> wrote:
> 
>> Hi!
>> 
>> I can't use a configuration parameter of type String[] in a class extending 
>> Resource_ImplBase. A cast exception is thrown. A simple String works fine. 
>> Arrays doesn't. Is it even possible to use an array of String as parameter 
>> with Resource_ImplBase?
>> 
>> Cheers
>> Armin

Attachment: pgpQN5e68owfM.pgp
Description: PGP signature

Reply via email to