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"?>
<analysisEngineDeploymentDescription
xmlns="http://uima.apache.org/resourceSpecifier">
<deployment protocol="jms" provider="activemq">
<service>
<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"/>
<environmentVariables>
<environmentVariable
name="LD_LIBRARY_PATH">${lib.dir}</environmentVariable>
</environmentVariables>
<topDescriptor>
<import location="descriptors\DaveDetector.xml"/>
</topDescriptor>
<analysisEngine async="false">
<scaleout numberOfInstances="1"/>
</analysisEngine>
</service>
</deployment>
</analysisEngineDeploymentDescription>
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.
Regards,
Matthias
> 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
>>>
>>>
>>>
>>>
>>>
--
--------------------------------
Matthias Wendt
Junior Softwareentwickler
F&E
neofonie
Technologieentwicklung und
Informationsmanagement GmbH
Robert-Koch-Platz 4
10115 Berlin
fon: +49.30 24627 529
fax: +49.30 24627 120
matthias.wendt@neofonie.de
http://www.neofonie.de
Handelsregister
Berlin-Charlottenburg: HRB 67460
Geschaeftsfuehrung
Helmut Hoffer von Ankershoffen
Nurhan Yildirim
--------------------------------
|