uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthias Wendt <matthias.we...@neofonie.de>
Subject Re: compatibility issues of uimacpp vs. uimaj using uima-as
Date Tue, 03 Nov 2009 19:08:21 GMT
Eddie Epstein schrieb:
> 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:
> 2. Modify DaveDetector.cpp to add the array to an FS in the incoming CAS:
Pretty much the same
> 3. Launch DaveDetector as a service (with broker running on
> tcp://localhost:61616)
>     C:\uimacpp\examples>deploycppservice descriptors\DaveDetector.xml
> DaveDetector
3.a Create a deployment descriptor:

<?xml version="1.0" encoding="UTF-8"?>
  <deployment protocol="jms" provider="activemq">
      <inputQueue endpoint="DaveDetector" 
brokerURL="tcp://localhost:61616" prefetch="1"/>
      <!-- if arrays don't survive, comment custom element -->
      <custom name="run_top_level_CPP_service_as_separate_process"/>
        <import location="descriptors\DaveDetector.xml"/>
      <analysisEngine async="false">
        <scaleout numberOfInstances="1"/>

3.b Start the Service from uimaj:
deployAsyncService DeployDaveDetector.xml

Try steps 4-6 again.
That seems to be the only obvious difference. To be sure, I also tried 
the cvd as in the example below and had the same effect when I send a 
handcrafted .xmi to my service.


> 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
>>> 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

Matthias Wendt
Junior Softwareentwickler

Technologieentwicklung und
Informationsmanagement GmbH
Robert-Koch-Platz 4
10115 Berlin
fon: +49.30 24627 529
fax: +49.30 24627 120

Berlin-Charlottenburg: HRB 67460

Helmut Hoffer von Ankershoffen
Nurhan Yildirim

View raw message