You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@uima.apache.org by Matthias Wendt <ma...@neofonie.de> on 2009/10/21 11:58:37 UTC
compatibility issues of uimacpp vs. uimaj using uima-as
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
AW: compatibility issues of uimacpp vs. uimaj using uima-as
Posted by Matthias Wendt <we...@neofonie.de>.
Hmm, seems as if this was just false alarm. The test works fine today. Must have been some kind of wrong configuration. Things get rather complex, when you're distributing them.
Matthias
-----Ursprüngliche Nachricht-----
Von: Eddie Epstein [mailto:eaepstein@gmail.com]
Gesendet: Donnerstag, 7. Januar 2010 15:28
An: uima-user@incubator.apache.org
Betreff: Re: compatibility issues of uimacpp vs. uimaj using uima-as
I cannot reproduce the problem with the latest code.
My test scenario is the one described in
http://markmail.org/message/zqmjfxad66mbssfy
with the addition of multipleReferencesAllowed to the type David in
DaveDetector.xml:
<featureDescription>
<name>variants</name>
<description/>
<rangeTypeName>uima.cas.StringArray</rangeTypeName>
<multipleReferencesAllowed>true</multipleReferencesAllowed>
</featureDescription>
Can you try this scenario using your build, and if it fails, try again
using the binary build
at p.a.o. ~schor/public_html/uima-release-candidates/2.3.0-RC8/uimacpp/ ?
Thanks,
Eddie
On Thu, Jan 7, 2010 at 5:46 AM, Matthias Wendt <we...@neofonie.de> wrote:
> Hi,
>
> I was using the 2.3.0 branch code, primarily to test the fix for the "deserializeCasFromXmi" bug sent by Christoph Büscher later in December. By the way, that test was positive :)
>
>
> Regards,
> Matthias
>
> -----Ursprüngliche Nachricht-----
> Von: Eddie Epstein [mailto:eaepstein@gmail.com]
> Gesendet: Donnerstag, 7. Januar 2010 04:54
> An: uima-user@incubator.apache.org
> Betreff: Re: compatibility issues of uimacpp vs. uimaj using uima-as
>
> Matthias,
>
> Which 2.3.0 code did you use? The fix is not yet in the trunk, it is in
> /incubator/uima/uimacpp/branches/uimacpp-2.3.0/src/cas/xmiwriter.cpp
>
> Did you use a binary build?
>
> Thanks,
> Eddie
>
> On Wed, Jan 6, 2010 at 9:51 AM, Matthias Wendt <we...@neofonie.de> wrote:
>> Hello Eddie,
>>
>> when trying the new 2.3.0 version of uimacpp yesterday, it turned out that the problem still occurs. Judging from the JIRA (issue: UIMA-1653), however, there is a fix for this. Could it be, that the test cases provided with the fix do not exactly reproduce the same behavior?
>>
>> Regards,
>> Matthias
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Eddie Epstein [mailto:eaepstein@gmail.com]
>> Gesendet: Freitag, 6. November 2009 22:51
>> An: uima-user@incubator.apache.org
>> Betreff: Re: compatibility issues of uimacpp vs. uimaj using uima-as
>>
>> On Fri, Nov 6, 2009 at 10:37 AM, Matthias Wendt
>> <ma...@neofonie.de> wrote:
>>> I finally found out the difference between the two scenarios. My Annotator
>>> has "multipleReferencesAllowed" set to true.
>>
>> Bingo! Problem reproduced here too. Is a bug in Xmi serialization
>> replies. Normally all features of a type to be sent are checked to
>> look for FS references. This check is done correctly for new types
>> created in the service, but missed for types received by a C++
>> service.
>>
>> As you already guessed, a workaround with the current code is to add
>> the new StringArrayFS to the index repository. Will be fixed in the
>> upcoming release.
>>
>> Many thanks for your time isolating this.
>> Eddie
>>
>
Re: compatibility issues of uimacpp vs. uimaj using uima-as
Posted by Eddie Epstein <ea...@gmail.com>.
I cannot reproduce the problem with the latest code.
My test scenario is the one described in
http://markmail.org/message/zqmjfxad66mbssfy
with the addition of multipleReferencesAllowed to the type David in
DaveDetector.xml:
<featureDescription>
<name>variants</name>
<description/>
<rangeTypeName>uima.cas.StringArray</rangeTypeName>
<multipleReferencesAllowed>true</multipleReferencesAllowed>
</featureDescription>
Can you try this scenario using your build, and if it fails, try again
using the binary build
at p.a.o. ~schor/public_html/uima-release-candidates/2.3.0-RC8/uimacpp/ ?
Thanks,
Eddie
On Thu, Jan 7, 2010 at 5:46 AM, Matthias Wendt <we...@neofonie.de> wrote:
> Hi,
>
> I was using the 2.3.0 branch code, primarily to test the fix for the "deserializeCasFromXmi" bug sent by Christoph Büscher later in December. By the way, that test was positive :)
>
>
> Regards,
> Matthias
>
> -----Ursprüngliche Nachricht-----
> Von: Eddie Epstein [mailto:eaepstein@gmail.com]
> Gesendet: Donnerstag, 7. Januar 2010 04:54
> An: uima-user@incubator.apache.org
> Betreff: Re: compatibility issues of uimacpp vs. uimaj using uima-as
>
> Matthias,
>
> Which 2.3.0 code did you use? The fix is not yet in the trunk, it is in
> /incubator/uima/uimacpp/branches/uimacpp-2.3.0/src/cas/xmiwriter.cpp
>
> Did you use a binary build?
>
> Thanks,
> Eddie
>
> On Wed, Jan 6, 2010 at 9:51 AM, Matthias Wendt <we...@neofonie.de> wrote:
>> Hello Eddie,
>>
>> when trying the new 2.3.0 version of uimacpp yesterday, it turned out that the problem still occurs. Judging from the JIRA (issue: UIMA-1653), however, there is a fix for this. Could it be, that the test cases provided with the fix do not exactly reproduce the same behavior?
>>
>> Regards,
>> Matthias
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Eddie Epstein [mailto:eaepstein@gmail.com]
>> Gesendet: Freitag, 6. November 2009 22:51
>> An: uima-user@incubator.apache.org
>> Betreff: Re: compatibility issues of uimacpp vs. uimaj using uima-as
>>
>> On Fri, Nov 6, 2009 at 10:37 AM, Matthias Wendt
>> <ma...@neofonie.de> wrote:
>>> I finally found out the difference between the two scenarios. My Annotator
>>> has "multipleReferencesAllowed" set to true.
>>
>> Bingo! Problem reproduced here too. Is a bug in Xmi serialization
>> replies. Normally all features of a type to be sent are checked to
>> look for FS references. This check is done correctly for new types
>> created in the service, but missed for types received by a C++
>> service.
>>
>> As you already guessed, a workaround with the current code is to add
>> the new StringArrayFS to the index repository. Will be fixed in the
>> upcoming release.
>>
>> Many thanks for your time isolating this.
>> Eddie
>>
>
Re: compatibility issues of uimacpp vs. uimaj using uima-as
Posted by Matthias Wendt <we...@neofonie.de>.
Hi,
I was using the 2.3.0 branch code, primarily to test the fix for the "deserializeCasFromXmi" bug sent by Christoph Büscher later in December. By the way, that test was positive :)
Regards,
Matthias
-----Ursprüngliche Nachricht-----
Von: Eddie Epstein [mailto:eaepstein@gmail.com]
Gesendet: Donnerstag, 7. Januar 2010 04:54
An: uima-user@incubator.apache.org
Betreff: Re: compatibility issues of uimacpp vs. uimaj using uima-as
Matthias,
Which 2.3.0 code did you use? The fix is not yet in the trunk, it is in
/incubator/uima/uimacpp/branches/uimacpp-2.3.0/src/cas/xmiwriter.cpp
Did you use a binary build?
Thanks,
Eddie
On Wed, Jan 6, 2010 at 9:51 AM, Matthias Wendt <we...@neofonie.de> wrote:
> Hello Eddie,
>
> when trying the new 2.3.0 version of uimacpp yesterday, it turned out that the problem still occurs. Judging from the JIRA (issue: UIMA-1653), however, there is a fix for this. Could it be, that the test cases provided with the fix do not exactly reproduce the same behavior?
>
> Regards,
> Matthias
>
>
> -----Ursprüngliche Nachricht-----
> Von: Eddie Epstein [mailto:eaepstein@gmail.com]
> Gesendet: Freitag, 6. November 2009 22:51
> An: uima-user@incubator.apache.org
> Betreff: Re: compatibility issues of uimacpp vs. uimaj using uima-as
>
> On Fri, Nov 6, 2009 at 10:37 AM, Matthias Wendt
> <ma...@neofonie.de> wrote:
>> I finally found out the difference between the two scenarios. My Annotator
>> has "multipleReferencesAllowed" set to true.
>
> Bingo! Problem reproduced here too. Is a bug in Xmi serialization
> replies. Normally all features of a type to be sent are checked to
> look for FS references. This check is done correctly for new types
> created in the service, but missed for types received by a C++
> service.
>
> As you already guessed, a workaround with the current code is to add
> the new StringArrayFS to the index repository. Will be fixed in the
> upcoming release.
>
> Many thanks for your time isolating this.
> Eddie
>
Re: compatibility issues of uimacpp vs. uimaj using uima-as
Posted by Eddie Epstein <ea...@gmail.com>.
Matthias,
Which 2.3.0 code did you use? The fix is not yet in the trunk, it is in
/incubator/uima/uimacpp/branches/uimacpp-2.3.0/src/cas/xmiwriter.cpp
Did you use a binary build?
Thanks,
Eddie
On Wed, Jan 6, 2010 at 9:51 AM, Matthias Wendt <we...@neofonie.de> wrote:
> Hello Eddie,
>
> when trying the new 2.3.0 version of uimacpp yesterday, it turned out that the problem still occurs. Judging from the JIRA (issue: UIMA-1653), however, there is a fix for this. Could it be, that the test cases provided with the fix do not exactly reproduce the same behavior?
>
> Regards,
> Matthias
>
>
> -----Ursprüngliche Nachricht-----
> Von: Eddie Epstein [mailto:eaepstein@gmail.com]
> Gesendet: Freitag, 6. November 2009 22:51
> An: uima-user@incubator.apache.org
> Betreff: Re: compatibility issues of uimacpp vs. uimaj using uima-as
>
> On Fri, Nov 6, 2009 at 10:37 AM, Matthias Wendt
> <ma...@neofonie.de> wrote:
>> I finally found out the difference between the two scenarios. My Annotator
>> has "multipleReferencesAllowed" set to true.
>
> Bingo! Problem reproduced here too. Is a bug in Xmi serialization
> replies. Normally all features of a type to be sent are checked to
> look for FS references. This check is done correctly for new types
> created in the service, but missed for types received by a C++
> service.
>
> As you already guessed, a workaround with the current code is to add
> the new StringArrayFS to the index repository. Will be fixed in the
> upcoming release.
>
> Many thanks for your time isolating this.
> Eddie
>
AW: compatibility issues of uimacpp vs. uimaj using uima-as
Posted by Matthias Wendt <we...@neofonie.de>.
Hello Eddie,
when trying the new 2.3.0 version of uimacpp yesterday, it turned out that the problem still occurs. Judging from the JIRA (issue: UIMA-1653), however, there is a fix for this. Could it be, that the test cases provided with the fix do not exactly reproduce the same behavior?
Regards,
Matthias
-----Ursprüngliche Nachricht-----
Von: Eddie Epstein [mailto:eaepstein@gmail.com]
Gesendet: Freitag, 6. November 2009 22:51
An: uima-user@incubator.apache.org
Betreff: Re: compatibility issues of uimacpp vs. uimaj using uima-as
On Fri, Nov 6, 2009 at 10:37 AM, Matthias Wendt
<ma...@neofonie.de> wrote:
> I finally found out the difference between the two scenarios. My Annotator
> has "multipleReferencesAllowed" set to true.
Bingo! Problem reproduced here too. Is a bug in Xmi serialization
replies. Normally all features of a type to be sent are checked to
look for FS references. This check is done correctly for new types
created in the service, but missed for types received by a C++
service.
As you already guessed, a workaround with the current code is to add
the new StringArrayFS to the index repository. Will be fixed in the
upcoming release.
Many thanks for your time isolating this.
Eddie
Re: compatibility issues of uimacpp vs. uimaj using uima-as
Posted by Matthias Wendt <ma...@neofonie.de>.
Eddie Epstein schrieb:
> As you already guessed, a workaround with the current code is to add
> the new StringArrayFS to the index repository. Will be fixed in the
> upcoming release.
>
Ah, fine. Looking forward to the next release :)
> Many thanks for your time isolating this.
> Eddie
>
Thank you as well,
Matthias
Re: compatibility issues of uimacpp vs. uimaj using uima-as
Posted by Eddie Epstein <ea...@gmail.com>.
On Fri, Nov 6, 2009 at 10:37 AM, Matthias Wendt
<ma...@neofonie.de> wrote:
> I finally found out the difference between the two scenarios. My Annotator
> has "multipleReferencesAllowed" set to true.
Bingo! Problem reproduced here too. Is a bug in Xmi serialization
replies. Normally all features of a type to be sent are checked to
look for FS references. This check is done correctly for new types
created in the service, but missed for types received by a C++
service.
As you already guessed, a workaround with the current code is to add
the new StringArrayFS to the index repository. Will be fixed in the
upcoming release.
Many thanks for your time isolating this.
Eddie
Re: compatibility issues of uimacpp vs. uimaj using uima-as
Posted by Matthias Wendt <ma...@neofonie.de>.
Hello Eddie,
I finally found out the difference between the two scenarios. My
Annotator has "multipleReferencesAllowed" set to true.
I adapted the DaveDetector.xml, also setting multi-ref to true. This
resulted in the same error. To see what's going on, I looked into the
package that was sent (using ngrep):
......(.........................n....K[..........$..T,...2....<?xml
version
="1.0" encoding="UTF-8"?><xmi:XMI
xmlns:examples="http:///org/apache/uima/e
xamples.ecore" xmlns:cas="http:///uima/cas.ecore"
xmlns:tcas="http:///uima/
tcas.ecore" xmlns:xmi="http://www.omg.org/XMI"
xmi:version="2.0"><cas:NULL
xmi:id="0"/> <cas:Sofa xmi:id="1" sofaNum="1" sofaID="_InitialView"
mimeTy
pe="text" sofaString="Load or edit text here."/>.
<tcas:DocumentAnnotation
xmi:id="2" sofa="1" begin="0" end="23" language="en"/>.
<examples:David xmi
:id="3" sofa="1" begin="0" end="1" variants="4"/>.<cas:View sofa="1"
member
s="2
3"/></xmi:XMI>....9......CasReference...-37f4a0fc:124c9361c79:-7feb..C
ommand.......IdleTime.......?...MessageFrom...DAVEDETECTORQ..MessageType...
....Payload.......ServerURI...tcp://localhost:61616..TimeInAnalytic........
`..TimeInProcessCAS........`..TimeInService...........TimeToDeserializeCAS.
.......P..TimeToSerializeCAS...................
variants gets an id-ref value of "4", but there is no object having
xmi:id="4". I was wondering if this is behaviour-as-defined. Does the
object have to be added to the indexes.? If so, I would have to check
for multi-ref allowed when initializing the typesystem. The
documentation only says: "this setting may affect how the CAS is
serialized". But why does the array make it into the CAS when Dave is
created in the annotator itself?:
while ( NULL !=
(gotDaveP = u_strFindFirst(remainingTextP, remainingLen,
DaveStringP, uiMatchLen)) ) {
size_t uiExprBeginPos = gotDaveP - cpszDocTextBegin;
size_t uiExprEndPos = uiExprBeginPos + uiMatchLen;
remainingLen = uiDocLen - uiExprBeginPos;
remainingTextP = gotDaveP + uiMatchLen;
cout << "DaveDetector::process() .. Gotta Dave begin: " <<
uiExprBeginPos << " end: "
<< uiExprEndPos << " remaining: " << remainingLen << endl;
AnnotationFS aDave =
tcas.createAnnotation(david, uiExprBeginPos, uiExprEndPos);
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);
indexRep.addFS(aDave);
}
Confused,
Matthias
Matthias Wendt schrieb:
> so, I rebuilt the uimacpp source distribution (the one on the download
> page). With this build the simple scenario works indeed, but my
> original scenario still doesn't.
>
> Against my first intuition, the old build was not the source of the
> error.
>
> I'm just trying to figure out if there are any major differences in
> both scenarios...
>
> Regards
> Matthias
>
>
> Eddie Epstein schrieb:
>> Hi Matthias,
>>
>> Just FYI, I've built the current source from svn on a 64-bit machine
>> and run this scenario with no problems. Note that it needs the latest
>> UIMA and UIMA AS builds to use deployAsyncService.
>>
>> I also had problems building activemq 2.1.3, until installing their
>> recommended versions before running autogen.sh:
>>
>> autoconf >= 2.60
>> automake >= 1.10
>> libtool >= 1.5.24
>>
>> These exact versions worked. I also installed cppunit, but not sure
>> this mattered.
>>
>> Regards,
>> Eddie
>>
>> On Wed, Nov 4, 2009 at 9:00 AM, Matthias Wendt <we...@neofonie.de>
>> wrote:
>>
>>> Hi,
>>>
>>> I am using a 64-bit build of the source distribution that was
>>> available on the download page of the website. However, I don't know
>>> exactly how it was built and from which version. The version suffix
>>> of the .so library file is 2.2. I am currently trying to make a
>>> fresh 64-bit build but stuck with problems with the required
>>> activemq version (only compatible up to 2.1.3), which somehow I
>>> cannot build.
>>>
>>> I did not try the minimal scenario but it's fairly similar to mine.
>>>
>>> I will continue testing and be back as soon as I found out something
>>> more.
>>>
>>> Matthias
>>>
>>>
>>>
>>>
>>> So the only difference in your scenario is to use deployAsyncService?
>>> Both use the same deployCppService executable. The only functional
>>> difference could be the environment picked up from specified
>>> <environmentVariables>.
>>>
>>> Since yours has name="LD_LIBRARY_PATH">${lib.dir}, I also tried with a
>>> Linux build, but had no problem there either.
>>>
>>> Just to be clear, you are seeing the problem with the minimal
>>> DaveDetector scenario? If so, using fairly recent SVN code for both
>>> uimaj and uimacpp? There were some changes recently dealing with
>>> quiesce and shutdown of deployCppService, but no changes in XMI CAS
>>> serialization on either side for some months.
>>>
>>> The only other thing I can think to suggest is putting an XMI dump in
>>> the uimacpp annotator service on entry and before it returns the CAS
>>> to confirm that the service inputs and outputs are what you expect.
>>>
>>> Eddie
>>>
>>> On Tue, Nov 3, 2009 at 2:08 PM, Matthias Wendt
>>> <ma...@neofonie.de> wrote:
>>>
>>>> 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
>>>>
>>>>
>
>
Re: compatibility issues of uimacpp vs. uimaj using uima-as
Posted by Matthias Wendt <ma...@neofonie.de>.
so, I rebuilt the uimacpp source distribution (the one on the download
page). With this build the simple scenario works indeed, but my original
scenario still doesn't.
Against my first intuition, the old build was not the source of the error.
I'm just trying to figure out if there are any major differences in both
scenarios...
Regards
Matthias
Eddie Epstein schrieb:
> Hi Matthias,
>
> Just FYI, I've built the current source from svn on a 64-bit machine
> and run this scenario with no problems. Note that it needs the latest
> UIMA and UIMA AS builds to use deployAsyncService.
>
> I also had problems building activemq 2.1.3, until installing their
> recommended versions before running autogen.sh:
>
> autoconf >= 2.60
> automake >= 1.10
> libtool >= 1.5.24
>
> These exact versions worked. I also installed cppunit, but not sure
> this mattered.
>
> Regards,
> Eddie
>
> On Wed, Nov 4, 2009 at 9:00 AM, Matthias Wendt <we...@neofonie.de> wrote:
>
>> Hi,
>>
>> I am using a 64-bit build of the source distribution that was available on the download page of the website. However, I don't know exactly how it was built and from which version. The version suffix of the .so library file is 2.2. I am currently trying to make a fresh 64-bit build but stuck with problems with the required activemq version (only compatible up to 2.1.3), which somehow I cannot build.
>>
>> I did not try the minimal scenario but it's fairly similar to mine.
>>
>> I will continue testing and be back as soon as I found out something more.
>>
>> Matthias
>>
>>
>>
>>
>> So the only difference in your scenario is to use deployAsyncService?
>> Both use the same deployCppService executable. The only functional
>> difference could be the environment picked up from specified
>> <environmentVariables>.
>>
>> Since yours has name="LD_LIBRARY_PATH">${lib.dir}, I also tried with a
>> Linux build, but had no problem there either.
>>
>> Just to be clear, you are seeing the problem with the minimal
>> DaveDetector scenario? If so, using fairly recent SVN code for both
>> uimaj and uimacpp? There were some changes recently dealing with
>> quiesce and shutdown of deployCppService, but no changes in XMI CAS
>> serialization on either side for some months.
>>
>> The only other thing I can think to suggest is putting an XMI dump in
>> the uimacpp annotator service on entry and before it returns the CAS
>> to confirm that the service inputs and outputs are what you expect.
>>
>> Eddie
>>
>> On Tue, Nov 3, 2009 at 2:08 PM, Matthias Wendt
>> <ma...@neofonie.de> wrote:
>>
>>> 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
>>>
>>>
--
--------------------------------
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
--------------------------------
Re: compatibility issues of uimacpp vs. uimaj using uima-as
Posted by Eddie Epstein <ea...@gmail.com>.
Hi Matthias,
Just FYI, I've built the current source from svn on a 64-bit machine
and run this scenario with no problems. Note that it needs the latest
UIMA and UIMA AS builds to use deployAsyncService.
I also had problems building activemq 2.1.3, until installing their
recommended versions before running autogen.sh:
autoconf >= 2.60
automake >= 1.10
libtool >= 1.5.24
These exact versions worked. I also installed cppunit, but not sure
this mattered.
Regards,
Eddie
On Wed, Nov 4, 2009 at 9:00 AM, Matthias Wendt <we...@neofonie.de> wrote:
> Hi,
>
> I am using a 64-bit build of the source distribution that was available on the download page of the website. However, I don't know exactly how it was built and from which version. The version suffix of the .so library file is 2.2. I am currently trying to make a fresh 64-bit build but stuck with problems with the required activemq version (only compatible up to 2.1.3), which somehow I cannot build.
>
> I did not try the minimal scenario but it's fairly similar to mine.
>
> I will continue testing and be back as soon as I found out something more.
>
> Matthias
>
>
>
>
> So the only difference in your scenario is to use deployAsyncService?
> Both use the same deployCppService executable. The only functional
> difference could be the environment picked up from specified
> <environmentVariables>.
>
> Since yours has name="LD_LIBRARY_PATH">${lib.dir}, I also tried with a
> Linux build, but had no problem there either.
>
> Just to be clear, you are seeing the problem with the minimal
> DaveDetector scenario? If so, using fairly recent SVN code for both
> uimaj and uimacpp? There were some changes recently dealing with
> quiesce and shutdown of deployCppService, but no changes in XMI CAS
> serialization on either side for some months.
>
> The only other thing I can think to suggest is putting an XMI dump in
> the uimacpp annotator service on entry and before it returns the CAS
> to confirm that the service inputs and outputs are what you expect.
>
> Eddie
>
> On Tue, Nov 3, 2009 at 2:08 PM, Matthias Wendt
> <ma...@neofonie.de> wrote:
>> 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
>>
>
AW: compatibility issues of uimacpp vs. uimaj using uima-as
Posted by Matthias Wendt <we...@neofonie.de>.
Hi,
I am using a 64-bit build of the source distribution that was available on the download page of the website. However, I don't know exactly how it was built and from which version. The version suffix of the .so library file is 2.2. I am currently trying to make a fresh 64-bit build but stuck with problems with the required activemq version (only compatible up to 2.1.3), which somehow I cannot build.
I did not try the minimal scenario but it's fairly similar to mine.
I will continue testing and be back as soon as I found out something more.
Matthias
So the only difference in your scenario is to use deployAsyncService?
Both use the same deployCppService executable. The only functional
difference could be the environment picked up from specified
<environmentVariables>.
Since yours has name="LD_LIBRARY_PATH">${lib.dir}, I also tried with a
Linux build, but had no problem there either.
Just to be clear, you are seeing the problem with the minimal
DaveDetector scenario? If so, using fairly recent SVN code for both
uimaj and uimacpp? There were some changes recently dealing with
quiesce and shutdown of deployCppService, but no changes in XMI CAS
serialization on either side for some months.
The only other thing I can think to suggest is putting an XMI dump in
the uimacpp annotator service on entry and before it returns the CAS
to confirm that the service inputs and outputs are what you expect.
Eddie
On Tue, Nov 3, 2009 at 2:08 PM, Matthias Wendt
<ma...@neofonie.de> wrote:
> 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
>
Re: compatibility issues of uimacpp vs. uimaj using uima-as
Posted by Eddie Epstein <ea...@gmail.com>.
So the only difference in your scenario is to use deployAsyncService?
Both use the same deployCppService executable. The only functional
difference could be the environment picked up from specified
<environmentVariables>.
Since yours has name="LD_LIBRARY_PATH">${lib.dir}, I also tried with a
Linux build, but had no problem there either.
Just to be clear, you are seeing the problem with the minimal
DaveDetector scenario? If so, using fairly recent SVN code for both
uimaj and uimacpp? There were some changes recently dealing with
quiesce and shutdown of deployCppService, but no changes in XMI CAS
serialization on either side for some months.
The only other thing I can think to suggest is putting an XMI dump in
the uimacpp annotator service on entry and before it returns the CAS
to confirm that the service inputs and outputs are what you expect.
Eddie
On Tue, Nov 3, 2009 at 2:08 PM, Matthias Wendt
<ma...@neofonie.de> wrote:
> 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
>
Re: compatibility issues of uimacpp vs. uimaj using uima-as
Posted by Matthias Wendt <ma...@neofonie.de>.
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 <we...@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
>> <ma...@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
--------------------------------
Re: compatibility issues of uimacpp vs. uimaj using uima-as
Posted by Eddie Epstein <ea...@gmail.com>.
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 <we...@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
> <ma...@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
>>
>>
>>
>>
>
AW: compatibility issues of uimacpp vs. uimaj using uima-as
Posted by Matthias Wendt <we...@neofonie.de>.
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
<ma...@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
>
>
>
>
Re: compatibility issues of uimacpp vs. uimaj using uima-as
Posted by Eddie Epstein <ea...@gmail.com>.
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
<ma...@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
>
>
>
>