uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eddie Epstein <eaepst...@gmail.com>
Subject Re: compatibility issues of uimacpp vs. uimaj using uima-as
Date Tue, 03 Nov 2009 14:59:49 GMT
Hi Matthias,

I'm having trouble reproducing the problem with the latest uimacpp
code. Please correct this scenario:

1. Modify type definition for David in DaveDetector.xml to add a
StringArrayFS feature:
    <typeDescription>
      <name>org.apache.uima.examples.David</name>
      <description></description>
      <supertypeName>uima.tcas.Annotation</supertypeName>
      <features>
        <featureDescription>
          <name>variants</name>
          <description/>
          <rangeTypeName>uima.cas.StringArray</rangeTypeName>
        </featureDescription>
      </features>
    </typeDescription>

2. Modify DaveDetector.cpp to add the array to an FS in the incoming CAS:
    ANIndex daveIndex = tcas.getAnnotationIndex(david);
    ANIterator daveIter = daveIndex.iterator();
    daveIter.moveToFirst();
    if (daveIter.isValid()) {
      cout << "Found an incoming Dave" << endl;
      AnnotationFS aDave = daveIter.get();
      cout << "filling array" << endl;
      StringArrayFS anFsArray = tcas.createStringArrayFS(3);
      anFsArray.set(0, icu::UnicodeString("first"));
      anFsArray.set(1, icu::UnicodeString("second"));
      anFsArray.set(2, icu::UnicodeString("third"));
      Feature variants  = david.getFeatureByBaseName("variants");
      aDave.setFSValue(variants, anFsArray);
    }

3. Launch DaveDetector as a service (with broker running on
tcp://localhost:61616)
    C:\uimacpp\examples>deploycppservice descriptors\DaveDetector.xml
DaveDetector

4. Create a JMS service descriptor to access the service:
<customResourceSpecifier xmlns="http://uima.apache.org/resourceSpecifier">
   <resourceClassName>org.apache.uima.aae.jms_adapter.JmsAnalysisEngineServiceAdapter</resourceClassName>
   <parameters>
     <parameter name="brokerURL" value="tcp://localhost:61616"/>
     <parameter name="endpoint" value="DaveDetector"/>
     <parameter name="timeout" value="5000"/>
     <parameter name="getmetatimeout" value="5000"/>
     <parameter name="cpctimeout" value="5000"/>
   </parameters>
</customResourceSpecifier>

5. Create an XMI input CAS as specified:
<?xml version="1.0" encoding="UTF-8"?>
<xmi:XMI xmlns:cas="http:///uima/cas.ecore"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:tcas="http:///uima/tcas.ecore"
xmlns:examples="http:///org/apache/uima/examples.ecore"
xmi:version="2.0">
    <cas:NULL xmi:id="0"/>
    <cas:Sofa xmi:id="6" sofaNum="1" sofaID="_InitialView"
mimeType="text" sofaString="Load or edit text here."/>
    <tcas:DocumentAnnotation xmi:id="1" sofa="6" begin="0" end="23"
language="en"/>
    <examples:David xmi:id="13" sofa="6" begin="0" end="1">
    </examples:David>
    <cas:View sofa="6" members="1 13"/>
</xmi:XMI>

6. Use cvd to connect to the service, load the XMI input file, run the
service and look at the returned CAS:
  a. "Run->LoadAE" and point at the JMS service descriptor
  b. "File->Read XMI CAS File" and point at the XMI input CAS
  c. "Run->Run DaveDetector on CAS"
  d. expand uima.tcas.Annotation in the CAS Index Repository pane and
click on the David
  e. expand the David in the pane below and expand variants

Regards,
Eddie


On Tue, Nov 3, 2009 at 8:59 AM, Matthias Wendt <wendt@neofonie.de> wrote:
> Hello Eddie,
>
> thank you very much for your quick reaction. However, I am sorry to have to note that
another related issue turned out:
>
> I have a FeatureStructure type containing a StringArrayFS typed feature. When I create
this FeatureStructure in a C++ AE and fill the array, everything works fine. But when the
FeatureStructure is  created in another AE and handed into a C++ AE where the array is filled,
it does not come back into any Java application using it (AE/Application).
>
> The bug does not occur when the C++ TAE is deployed as a JNI driven AE - maybe there
is a bug/incompatibility in the serialization.? Running it as a native process, however, is
about 3-4 times faster.
>
> I would really appreciate to have this fixed in the upcoming release - if possible.
>
> Regards,
> Matthias
>
>
> -----Ursprüngliche Nachricht-----
> Von: Eddie Epstein [mailto:eaepstein@gmail.com]
> Gesendet: Mittwoch, 21. Oktober 2009 16:02
> An: uima-user@incubator.apache.org
> Betreff: Re: compatibility issues of uimacpp vs. uimaj using uima-as
>
> Matthias,
>
> Two issues have been created against UIMACPP, a documentation issue
> covering points 1&2 and a getMeta issue not returning <elementType>.
>
> Many thanks for the input,
> Eddie
>
>
> On Wed, Oct 21, 2009 at 5:58 AM, Matthias Wendt
> <matthias.wendt@neofonie.de> wrote:
>> Hello everybody,
>>
>> to integrate a uimacpp AE with uimaj AEs, I have tried to deploy the uimacpp
>> AE as a UIMA-AS service. During development some compatibility issues arose,
>> which I think is worthwile commenting.
>>
>> 1. uimacpp does not support import by name <import name="..." />, which I
>> think is not mentioned in the documentation.
>> 2. using <import location="..." /> employs a different path resolving
>> strategy from that of uimaj:
>>  -  both  support using absolute paths and relative paths (relative to the
>> descriptor in which the import occurs)
>>  -  uimacpp can be given the environment variable UIMACPP_DATAPATH which is
>> additionally used to resolve relative paths
>>  - However, uimaj does not support resolving relative <import location="..."
>> /> from it's datapath.
>> 3. I deployed the uimacpp AE service which has exactly the same typesystem
>> as a uimaj AE in the pipeline. However, the CASes are incompatible with the
>> following reason:
>>  - There is a type 'Constituent' which has a 'children' feature. 'children'
>> is of the range type 'FSArray' with the element type 'Constituent'.
>>  - However, when getting the typesystem from the uimacpp service, the
>> element type is ignored. Both components cannot be plugged into one
>> pipeline, because of an exception complaining about incompatible
>> typesystems.
>>
>> I will work around the last issue by altering the typesystem (removing the
>> element type), but this is not satisfactory.
>>
>> Kind regards
>> Matthias
>>
>>
>>
>>
>

Mime
View raw message