Uploaded image for project: 'UIMA'
  1. UIMA
  2. UIMA-3591

Multi-values parameter does not accept single value when @ConfigurationParameter is not present

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 2.0.0uimaFIT
    • Fix Version/s: 2.1.0uimaFIT
    • Component/s: uimaFIT
    • Labels:
      None

      Description

      This is not working

      AnalysisEngineFactory.createEngineDescription(WhitespaceTokenizer.class,
                     "SofaNames", SimpleParserAE.SOFA_NAME_TEXT_ONLY);
      

      I got a ClassCastException

      Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to
      [Ljava.lang.String;
         at
      org.apache.uima.annotator.WhitespaceTokenizer.initialize(WhitespaceTokenizer.java:328)
         at
      org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.initializeAnalysisComponent(PrimitiveAnalysisEngine_impl.java:252)
      

        Activity

        Hide
        rec Richard Eckart de Castilho added a comment - - edited

        I'm afraid, this issue cannot be fixed.

        uimaFIT correctly coerces single values on multi-valued parameters if it knows that the parameter is multi-valued. This knowledge is obtained from the resource meta data that is part of a descriptor. The descriptor can come either from an XML file, or it can have been dynamically generated using uimaFIT. In this issue, the descriptor is dynamically created using uimaFIT.

        For uimaFIT to generate a descriptor with a parameter declarations, class fieldes must have been marked using the @ConfigurationParameter annotation. If a field is an array or collection type, then uimaFIT will correctly mark the parameter as multi-valued in the descriptor.

        In the present case, uimaFIT analyzes the WhitespaceTokenizer class which does not contain any @ConfigurationParameter annotations. Thus, the descriptor generated for this class does not contain any parameter declarations. Consequently, none of the type coercion mechanisms can function, as these rely on the parameter declarations. uimaFIT will still be able to initialize the component, but only if the parameters passed in the createEngineDescription-call match exactly the types expected by the UIMA component.

        Show
        rec Richard Eckart de Castilho added a comment - - edited I'm afraid, this issue cannot be fixed. uimaFIT correctly coerces single values on multi-valued parameters if it knows that the parameter is multi-valued . This knowledge is obtained from the resource meta data that is part of a descriptor. The descriptor can come either from an XML file, or it can have been dynamically generated using uimaFIT. In this issue, the descriptor is dynamically created using uimaFIT. For uimaFIT to generate a descriptor with a parameter declarations, class fieldes must have been marked using the @ConfigurationParameter annotation. If a field is an array or collection type, then uimaFIT will correctly mark the parameter as multi-valued in the descriptor. In the present case, uimaFIT analyzes the WhitespaceTokenizer class which does not contain any @ConfigurationParameter annotations. Thus, the descriptor generated for this class does not contain any parameter declarations. Consequently, none of the type coercion mechanisms can function, as these rely on the parameter declarations. uimaFIT will still be able to initialize the component, but only if the parameters passed in the createEngineDescription-call match exactly the types expected by the UIMA component.
        Hide
        rec Richard Eckart de Castilho added a comment -

        Added corresponding note to documentation.

        Show
        rec Richard Eckart de Castilho added a comment - Added corresponding note to documentation.
        Hide
        schor Marshall Schor added a comment -

        How about adding some @ConfigurationParameter annotations to our "add-on" annotators, where it makes sense, so they work better with uimaFIT?

        Show
        schor Marshall Schor added a comment - How about adding some @ConfigurationParameter annotations to our "add-on" annotators, where it makes sense, so they work better with uimaFIT?
        Hide
        lfoppiano Luca Foppiano added a comment -

        Marshall, with ''add-on'' annotator you mean the ones here: http://uima.apache.org/annotators?
        If so, unless you want to push uima-fit as part of the base components of uima, the risk is that they are adding an additional dependency.

        Richard, thanks for your work and explanation.

        Show
        lfoppiano Luca Foppiano added a comment - Marshall, with ''add-on'' annotator you mean the ones here: http://uima.apache.org/annotators? If so, unless you want to push uima-fit as part of the base components of uima, the risk is that they are adding an additional dependency. Richard, thanks for your work and explanation.
        Hide
        rec Richard Eckart de Castilho added a comment -

        Marshall, I like the idea of course

        However, I think Luca is right. Adding another dependency itself is not a problem, but uimaFIT-core also drags in a little bit of Spring. I think it would be a sensible idea to separate the Java annotations out into a separate module. This should not have any further dependencies, it should be small, and it should be conveniently includable with annotators - even if they do not use any of the other uimaFIT features.

        Show
        rec Richard Eckart de Castilho added a comment - Marshall, I like the idea of course However, I think Luca is right. Adding another dependency itself is not a problem, but uimaFIT-core also drags in a little bit of Spring. I think it would be a sensible idea to separate the Java annotations out into a separate module. This should not have any further dependencies, it should be small, and it should be conveniently includable with annotators - even if they do not use any of the other uimaFIT features.
        Hide
        schor Marshall Schor added a comment -

        I was actually thinking that there was no dependency created, because you're just adding an "@" style annotation. I thought that would not affect the non-uimaFIT usage?

        Show
        schor Marshall Schor added a comment - I was actually thinking that there was no dependency created, because you're just adding an "@" style annotation. I thought that would not affect the non-uimaFIT usage?
        Hide
        rec Richard Eckart de Castilho added a comment -

        Annotations are a concept similar to classes and interfaces. They are declared in their own source file, bear JavaDoc, are compiled to a class file etc etc. They can only be used if the JAR containing the class files that define them is on the classpath.

        Show
        rec Richard Eckart de Castilho added a comment - Annotations are a concept similar to classes and interfaces. They are declared in their own source file, bear JavaDoc, are compiled to a class file etc etc. They can only be used if the JAR containing the class files that define them is on the classpath.

          People

          • Assignee:
            rec Richard Eckart de Castilho
            Reporter:
            rec Richard Eckart de Castilho
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development