Re: jVinci and socket keepalive
I lean toward adding the keep-alive as the default for Vinci because it seems to fix firewall issues which we've seen, with little or no down-side. I would not complicate the UIMA descriptors with this detail at this point. If we later get some kind of new, separate deployment details descriptor, that could be a good spot to put this. How about for now, making this a UIMA framework property - like the logger to use, etc. -Marshall Adam Lally wrote: We've had some users who report that turning on socket keepAlive (by manually modifying the jVinci source) helped them with some firewall trouble, where otherwise the firewall seemed to be cutting the connection after some period of inactivity. Should we turn this on in UIMA? I asked the developer who's most knowledgable about the jVinci code and he had this to say: I went and tried to find out why not to set this flag on always, and basically found no compelling reason not to; however, I did find instances where people argue that it is poor design - for no real good reason other than it not ever being necessary and can be solved at an application level - also it potentially opens up security holes - by keeping a socket around for a long time allowing things to snoop - and that under heavy load/lots of sockets it can negatively impact throughput because the stack has to send keep alive packets down every socket. I sent a note to one of our devs here who did a lot of work with socket performance, his only response was that it might keep more sockets in CLOSE_WAIT state, which shouldn't pose a problem. He offered to maybe help implement this, but sometime in the future, not immediately. We could go ahead and do this ourselves, perhaps in v2.1. It doesn't seem too difficult. The main questions are (1) should the keepAlive be on by default (I think so, since it seems to help avoid problems and there's no clear indication that there is a downside), and (2) whether this should be configurable from UIMA descriptors. We could add a socketKeepAlive element to the uriSpecifier and to the CPE descriptor (it's unfortunate all this stuff is in two places :( ). Opinions? -Adam
Re: Problems with XCasAnnotationViewer
Hi, I am not sure, who is looking into this, but I assume that if you can provide a small XMI sample file, which produces this error it might help a lot. -- Mirko btw.: is the annotation correct in the XMI? well, I think at least the XMI is correct. At least it has all the info I am expecting. I added a demo xmi where the problem occurs. I found that the following erros is thrown by the XCasAnnotationViewer: -- snip --- Exception occurred during event dispatching: CASRuntimeException: Trying to access value of feature de.julielab.jules.types.MeshHeading:descriptorNameMajorTopic as feature structure, but is primitive type. --- snap --- Someone told me, there might be problems with primitives. Actually, here the feature descriptorNameMajorTopic is a Boolean. And the same error occures with other types when there is a Boolean feature. Any ideas how to solve this issue? bye, Katrin On 1/15/07, Katrin Tomanek [EMAIL PROTECTED] wrote: Hi, I am using the XCasAnnotationViewer (uima SDK 2.0.2). Normally, it works fine. However, some of my annotations it doesn't show for some reason. In detail, when I open an annotated document (xmi-format) within the viewer, I get a list of annotations below the document which I can select. When I then click in the text on the colored annotations I can see the annotation detail on the right. But there are some of my annotations, which I -- though I can click on them in the text -- cannot see in the right side of the window (annotation details). Does anybody know why this is ? Or what could be the error ? Thanks in advance, Katrin -- Katrin Tomanek Jena University Language and Information Engineering (JULIE) Lab Phone: +49-3641-944307 Fax: +49-3641-944321 email: [EMAIL PROTECTED] URL: http://www.coling.uni-jena.de -- Katrin Tomanek Jena University Language and Information Engineering (JULIE) Lab Phone: +49-3641-944307 Fax: +49-3641-944321 email: [EMAIL PROTECTED] URL: http://www.coling.uni-jena.de ?xml version=1.0 encoding=UTF-8?xmi:XMI xmlns:pubmed=http:///de/julielab/jules/types/pubmed.ecore; xmlns:cas=http:///uima/cas.ecore; xmlns:types=http:///de/julielab/jules/types.ecore; xmlns:tcas=http:///uima/tcas.ecore; xmlns:xmi=http://www.omg.org/XMI; xmi:version=2.0cas:NULL xmi:id=0/cas:Sofa xmi:id=1 sofaNum=1 sofaID=_InitialView mimeType=text sofaString=IL-10 is a well-known immunosuppressive.../tcas:DocumentAnnotation xmi:id=8 sofa=1 begin=0 end=42 language=x-unspecified/pubmed:ManualDescriptor xmi:id=166 sofa=1 begin=0 end=42 meSHList=178 chemicalList=376/types:MeshHeading xmi:id=211 sofa=1 begin=0 end=42 descriptorName=Antigens, CD qualifierName=analysis descriptorNameMajorTopic=false qualifierNameMajorTopic=false/types:MeshHeading xmi:id=222 sofa=1 begin=0 end=42 descriptorName=Antigens, CD14 qualifierName=analysis descriptorNameMajorTopic=false qualifierNameMajorTopic=false/types:MeshHeading xmi:id=233 sofa=1 begin=0 end=42 descriptorName=Antigens, Differentiation, Myelomonocytic qualifierName=analysis descriptorNameMajorTopic=false qualifierNameMajorTopic=false/types:MeshHeading xmi:id=244 sofa=1 begin=0 end=42 descriptorName=Biological Transport descriptorNameMajorTopic=false qualifierNameMajorTopic=false/types:MeshHeading xmi:id=255 sofa=1 begin=0 end=42 descriptorName=Cell Adhesion descriptorNameMajorTopic=false qualifierNameMajorTopic=false/types:MeshHeading xmi:id=266 sofa=1 begin=0 end=42 descriptorName=Cells, Cultured descriptorNameMajorTopic=false qualifierNameMajorTopic=false/types:MeshHeading xmi:id=277 sofa=1 begin=0 end=42 descriptorName=Cytokines qualifierName=biosynthesis descriptorNameMajorTopic=false qualifierNameMajorTopic=true/types:MeshHeading xmi:id=288 sofa=1 begin=0 end=42 descriptorName=Humans descriptorNameMajorTopic=false qualifierNameMajorTopic=false/types:MeshHeading xmi:id=299 sofa=1 begin=0 end=42 descriptorName=Interleukin-10 qualifierName=pharmacology descriptorNameMajorTopic=false qualifierNameMajorTopic=true/types:MeshHeading xmi:id=310 sofa=1 begin=0 end=42 descriptorName=Leukocytes, Mononuclear qualifierName=metabolism descriptorNameMajorTopic=false qualifierNameMajorTopic=false/types:MeshHeading xmi:id=321 sofa=1 begin=0 end=42 descriptorName=Lipopolysaccharides qualifierName=pharmacology descriptorNameMajorTopic=false qualifierNameMajorTopic=false/types:MeshHeading xmi:id=332 sofa=1 begin=0 end=42 descriptorName=NF-kappa B qualifierName=metabolism descriptorNameMajorTopic=false qualifierNameMajorTopic=false/types:MeshHeading xmi:id=343 sofa=1 begin=0 end=42 descriptorName=RNA, Messenger qualifierName=analysis descriptorNameMajorTopic=false qualifierNameMajorTopic=false/types:MeshHeading xmi:id=354 sofa=1 begin=0 end=42 descriptorName=Receptors, IgG qualifierName=analysis descriptorNameMajorTopic=false qualifierNameMajorTopic=false/types:MeshHeading xmi:id=365 sofa=1 begin=0 end=42 descriptorName=Tumor Necrosis Factor-alpha qualifierName=genetics descriptorNameMajorTopic=false
[jira] Resolved: (UIMA-185) Make CAS use same Exception concept as the rest of UIMA
[ https://issues.apache.org/jira/browse/UIMA-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thilo Goetz resolved UIMA-185. -- Resolution: Fixed Fix Version/s: 2.1 Assignee: Marshall Schor (was: Thilo Goetz) Done. Marshall: please review as changes affect quite a bit of JCas code. Eddie: please review as there are some Sofa exceptions with non-internationalized message texts that I suspect originated with you or Bhavani. I added TODOs, so they should be relatively easy to find. There was one instance where an exception was created, but not thrown nor anything else done with it. I added a throw. Make CAS use same Exception concept as the rest of UIMA --- Key: UIMA-185 URL: https://issues.apache.org/jira/browse/UIMA-185 Project: UIMA Issue Type: Improvement Components: Core Java Framework Reporter: Thilo Goetz Assigned To: Marshall Schor Priority: Minor Fix For: 2.1 The CAS for historical reasons uses a different exception localization mechanism than the rest of UIMA. This should be changed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: jVinci and socket keepalive
On 1/19/07, Marshall Schor [EMAIL PROTECTED] wrote: snip/ How about for now, making this a UIMA framework property - like the logger to use, etc. Good idea, I will plan to do that today if there are no objections. -Adam
UIMA 1.x / 2.x service compatibility
Eddie and I don't think we're going to get to this JIRA issue for 2.1: Apache UIMA client should be able to communicate with IBM UIMA (1.x or 2.0) service https://issues.apache.org/jira/browse/UIMA-125 As I noted in a JIRA comment, service compatibility between IBM UIMA 2.0 and Apache UIMA 2.x already works. Compatibility with 1.x may not be critical since 1.x users should be able in most cases to switch to using the IBM UIMA 2.0 runtime without changing any of their code, and thus acheive service-compatibility with Apache UIMA. Allowing UIMA 2.x to call 1.x services would involve implementing some way to find out what version of UIMA (version of the built-in type system, really) the service was using, probably by some new service call, which would return an error if called on a 1.x service. Then there would be changes to the XCAS serialization in 2.x to allow it to generate 1.x-compatible XCASes on request. And all of that would only work for single-sofa CASes. Any issues with not implementing this? -Adam
[jira] Created: (UIMA-212) Turn on socket keepAlive in jVinci
Turn on socket keepAlive in jVinci -- Key: UIMA-212 URL: https://issues.apache.org/jira/browse/UIMA-212 Project: UIMA Issue Type: Improvement Components: Transport Adapters - SOAP, Vinci Reporter: Adam Lally Assigned To: Adam Lally Fix For: 2.1 Turn on socket keepAlive by default in jVinci. Make configurable as a UIMA framework inernal config setting. Details here: http://www.mail-archive.com/uima-dev@incubator.apache.org/msg01527.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (UIMA-193) PEAR Encoding Test gives NullPointerException under Sun Java 1.4.2
[ https://issues.apache.org/jira/browse/UIMA-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally reassigned UIMA-193: --- Assignee: Adam Lally PEAR Encoding Test gives NullPointerException under Sun Java 1.4.2 -- Key: UIMA-193 URL: https://issues.apache.org/jira/browse/UIMA-193 Project: UIMA Issue Type: Bug Components: Core Java Framework Environment: Sun Java 1.4.2_12 Reporter: Adam Lally Assigned To: Adam Lally Fix For: 2.1 Attachments: PearEncodingTest.patch java.lang.NullPointerException at org.apache.uima.pear.util.PearEncodingTest.testUTF8WithSignature(PearEncodingTest.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (UIMA-210) faulty use of .read(buffer...) in several places - not checking for fewer than expected bytes/chars read
[
https://issues.apache.org/jira/browse/UIMA-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor reassigned UIMA-210:
---
Assignee: Marshall Schor
faulty use of .read(buffer...) in several places - not checking for fewer
than expected bytes/chars read
Key: UIMA-210
URL: https://issues.apache.org/jira/browse/UIMA-210
Project: UIMA
Issue Type: Bug
Components: Core Java Framework
Affects Versions: 2.1
Reporter: Marshall Schor
Assigned To: Marshall Schor
Fix For: 2.1
The definition of most instances of stream.read(bufferArray) says it reads
*up to* the length of the array. We had earlier an issue on a multi-core
machine where the length read was much less than the length of the buffer or
of the file. (This was in Vinci). The solution is to wrap these things in
code that looks like this from the XTalkTransporter (this assumes the file
length is known):
static public void readFully(byte[] b, int length, InputStream in) throws
IOException {
int read_so_far = 0;
while (read_so_far length) {
int count = in.read(b, read_so_far, length - read_so_far);
if (count 0) {
throw new EOFException();
}
read_so_far += count;
}
}
Code which is broken can be found by scanning for .read(
Ones I found scanning are:
VinciTAEClient
FileUtils (copyFile method)
(Note: similarly named class FileUtil (no final s) has a copyFile method
that is OK)
XMLUtil.java has fragment that could fail incorrectly in
detectXmlFileEncoding:
// store the 1st text byte and read next 6 bytes of XML file
buffer[byteCounter++] = (byte) nextByte;
if (iStream.read(buffer, byteCounter, bytes2put - 1) != bytes2put - 1)
//ERROR NOT ALLOWING FOR FEWER BYTES READ
throw new IOException(cannot read file);
There are multiple instances of code in JcasSofaTest don't allow for the
possiblity of reading fewer than buf size; here's one:
dest = new byte[4];
is.close();
is = intArrayView.getSofaDataStream();
assertTrue(is != null);
int i = 0;
while (is.read(dest) != -1) {
assertTrue(ByteBuffer.wrap(dest).getInt() == intArrayFS.get(i++));
;
}
And another one like this in SofaTest.
DebugControlThread method doCheckpoint has the problem
In our examples, the following have the problem:
CasMultiplierExampleApplication
FileSystemCollectionReader
ExampleApplication
PrintAnnotations
JetExpander
And in uimaj-tools:
FileSystemCollectionReader
CasTreeViewer
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r497842 - in /incubator/uima/uimaj/trunk/uimaj-core/src: main/java/org/apache/uima/cas/impl/FeatureStructureImplC.java main/java/org/apache/uima/jcas/cas/TOP.java test/java/org/apache/
[EMAIL PROTECTED] wrote:
Author: alally
Date: Fri Jan 19 07:15:38 2007
New Revision: 497842
URL: http://svn.apache.org/viewvc?view=revrev=497842
Log:
Fixed FeatureStructure.equals to compare base CAS refs, not view refs.
UIMA-209: http://issues.apache.org/jira/browse/UIMA-209
Modified:
incubator/uima/uimaj/trunk/uimaj-core/src/main/java/org/apache/uima/cas/impl/FeatureStructureImplC.java
incubator/uima/uimaj/trunk/uimaj-core/src/main/java/org/apache/uima/jcas/cas/TOP.java
incubator/uima/uimaj/trunk/uimaj-core/src/test/java/org/apache/uima/cas/test/SofaTest.java
Modified:
incubator/uima/uimaj/trunk/uimaj-core/src/main/java/org/apache/uima/cas/impl/FeatureStructureImplC.java
URL:
http://svn.apache.org/viewvc/incubator/uima/uimaj/trunk/uimaj-core/src/main/java/org/apache/uima/cas/impl/FeatureStructureImplC.java?view=diffrev=497842r1=497841r2=497842
==
---
incubator/uima/uimaj/trunk/uimaj-core/src/main/java/org/apache/uima/cas/impl/FeatureStructureImplC.java
(original)
+++
incubator/uima/uimaj/trunk/uimaj-core/src/main/java/org/apache/uima/cas/impl/FeatureStructureImplC.java
Fri Jan 19 07:15:38 2007
@@ -71,7 +71,7 @@
return false;
}
FeatureStructureImplC fs = (FeatureStructureImplC) o;
-if ((this.addr == fs.addr) (this.casImpl == fs.casImpl)) {
+if ((this.addr == fs.addr) (this.casImpl.baseCAS ==
fs.casImpl.baseCAS)) {
return true;
}
return false;
I'd vote for using the getBaseCAS() accessor instead of directly
accessing the baseCAS variable. That will make the eventual refactoring
into views and CASes easier (and improves on artistic impression ;-).
Otherwise the change looks fine to me.
--Thilo
Re: svn commit: r497842 - in /incubator/uima/uimaj/trunk/uimaj-core/src: main/java/org/apache/uima/cas/impl/FeatureStructureImplC.java main/java/org/apache/uima/jcas/cas/TOP.java test/java/org/apache/
On 1/19/07, Thilo Goetz [EMAIL PROTECTED] wrote: I'd vote for using the getBaseCAS() accessor instead of directly accessing the baseCAS variable. That will make the eventual refactoring into views and CASes easier (and improves on artistic impression ;-). Done. -Adam
Please review and comment on Project Guidelines and Contribution Policies
The UIMA website on Apache ( http://incubator.apache.org/uima/ ) has drafts of the Project Guidelines and Contributions Policies. Please review and comment on their content, including saying you agree - if you agree - so we can come to some concensus about this. The goals of these are to balance a low barrier to getting in new contributions, with the need of big company adopters of this framework to be able to do the necessary clearances to bring this into their products. -Marshall
Re: Please review and comment on Project Guidelines and Contribution Policies
Marshall Schor wrote: The UIMA website on Apache ( http://incubator.apache.org/uima/ ) has drafts of the Project Guidelines and Contributions Policies. Please review and comment on their content, including saying you agree - if you agree - so we can come to some concensus about this. The goals of these are to balance a low barrier to getting in new contributions, with the need of big company adopters of this framework to be able to do the necessary clearances to bring this into their products. -Marshall +1 to the overall content, nice work Marshall. Some minor comments: - Since we have our mailing list addresses in plain text in other places, I don't think it's necessary AT.DOT it on the project guidelines page, it just makes it hard to read. - In general, I don't think we should be talking about the product. That sounds too much like closed source software. If we need to talk in this abstract way, software might be a neutral term. However, I think it would be even better to talk about UIMA. - I'm not sure I'd want to talk about promotion when making a contributor a committer, or when making a committer a PMC member. We're not in the army ;-) I'd probably say something like a contributor can be granted commit access. - The Project Management Committee heading on the roles and responsibilities page is missing the Project - The mailing lists should be explained on the mailing lists' page. This good content, just not in the right place I think. - I have no idea what kind of votes should be majority votes, and what votes should be consensus votes. Does anybody know? - On the contributions policy page, I'm missing something on the use of externally developed libraries (such as DocBook). I looked, but found no place on the Apache site that we can just link to as far as compatible licenses go. If anybody finds one, let me know. If not, this might be a point to raise on [EMAIL PROTECTED] --Thilo
Re: Please review and comment on Project Guidelines and Contribution Policies
Thilo Goetz wrote: snip +1 to the overall content, nice work Marshall. Thanks! Some minor comments: - Since we have our mailing list addresses in plain text in other places, I don't think it's necessary AT.DOT it on the project guidelines page, it just makes it hard to read. I saw this style on some other pages. I agree it is inconsistent, and I too prefer just ordinary email names (I guess until my mail box starts filling up with too much spam). - In general, I don't think we should be talking about the product. That sounds too much like closed source software. If we need to talk in this abstract way, software might be a neutral term. However, I think it would be even better to talk about UIMA. Sounds right. - I'm not sure I'd want to talk about promotion when making a contributor a committer, or when making a committer a PMC member. We're not in the army ;-) I'd probably say something like a contributor can be granted commit access. OK. But we'll still keep the multiple role definitions, right? (e.g. contributor, committer, PMC member) - The Project Management Committee heading on the roles and responsibilities page is missing the Project OK - The mailing lists should be explained on the mailing lists' page. This good content, just not in the right place I think. OK - I have no idea what kind of votes should be majority votes, and what votes should be consensus votes. Does anybody know? - On the contributions policy page, I'm missing something on the use of externally developed libraries (such as DocBook). I looked, but found no place on the Apache site that we can just link to as far as compatible licenses go. If anybody finds one, let me know. If not, this might be a point to raise on [EMAIL PROTECTED] There is one: it's here: http://people.apache.org/~cliffs/3party.html -Marshall
[jira] Closed: (UIMA-212) Turn on socket keepAlive in jVinci
[ https://issues.apache.org/jira/browse/UIMA-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-212. --- Resolution: Fixed Turn on socket keepAlive in jVinci -- Key: UIMA-212 URL: https://issues.apache.org/jira/browse/UIMA-212 Project: UIMA Issue Type: Improvement Components: Transport Adapters - SOAP, Vinci Reporter: Adam Lally Assigned To: Adam Lally Fix For: 2.1 Turn on socket keepAlive by default in jVinci. Make configurable as a UIMA framework inernal config setting. Details here: http://www.mail-archive.com/uima-dev@incubator.apache.org/msg01527.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (UIMA-213) DocumentAnalyzer/RunAE tools don't support XML detagging and Remote Vinci AEs
[ https://issues.apache.org/jira/browse/UIMA-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally reassigned UIMA-213: --- Assignee: Adam Lally DocumentAnalyzer/RunAE tools don't support XML detagging and Remote Vinci AEs - Key: UIMA-213 URL: https://issues.apache.org/jira/browse/UIMA-213 Project: UIMA Issue Type: Bug Components: Tools Reporter: Adam Lally Assigned To: Adam Lally Fix For: 2.1 It generates invalid XCASes as output if you try to do this. This is because Sofa mapping is used to do XML detagging, but Sofa mapping isn't implemented correctly for Vinci services (in fact it seems completely broken now). Anyway it is slated to be completely removed for v2.1 (see UIMA-122). It may be possible to do Sofa mapping differently so that the detagged text is stored in the _InitialView, so that Sofa mapping isn't needed for the remote. Failing that, we'd just need to put in a better error message until such time as we implement Sofa mapping for remotes in a reliable way. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (UIMA-213) DocumentAnalyzer/RunAE tools don't support XML detagging and Remote Vinci AEs
DocumentAnalyzer/RunAE tools don't support XML detagging and Remote Vinci AEs - Key: UIMA-213 URL: https://issues.apache.org/jira/browse/UIMA-213 Project: UIMA Issue Type: Bug Components: Tools Reporter: Adam Lally Fix For: 2.1 It generates invalid XCASes as output if you try to do this. This is because Sofa mapping is used to do XML detagging, but Sofa mapping isn't implemented correctly for Vinci services (in fact it seems completely broken now). Anyway it is slated to be completely removed for v2.1 (see UIMA-122). It may be possible to do Sofa mapping differently so that the detagged text is stored in the _InitialView, so that Sofa mapping isn't needed for the remote. Failing that, we'd just need to put in a better error message until such time as we implement Sofa mapping for remotes in a reliable way. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (UIMA-213) DocumentAnalyzer/RunAE tools don't support XML detagging and Remote Vinci AEs
[ https://issues.apache.org/jira/browse/UIMA-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466142 ] Adam Lally commented on UIMA-213: - Unfortunately I don't think it's possible to make this work with any Sofa mapping as it's currently implemented. I thought I could map the CPE's _InitialView to the XmlDetagger's output Sofa (plainTextSofa), but that won't work since the XmlDetagger will get an error when it tries to create the _InitialView. DocumentAnalyzer/RunAE tools don't support XML detagging and Remote Vinci AEs - Key: UIMA-213 URL: https://issues.apache.org/jira/browse/UIMA-213 Project: UIMA Issue Type: Bug Components: Tools Reporter: Adam Lally Assigned To: Adam Lally Fix For: 2.1 It generates invalid XCASes as output if you try to do this. This is because Sofa mapping is used to do XML detagging, but Sofa mapping isn't implemented correctly for Vinci services (in fact it seems completely broken now). Anyway it is slated to be completely removed for v2.1 (see UIMA-122). It may be possible to do Sofa mapping differently so that the detagged text is stored in the _InitialView, so that Sofa mapping isn't needed for the remote. Failing that, we'd just need to put in a better error message until such time as we implement Sofa mapping for remotes in a reliable way. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Please review and comment on Project Guidelines and Contribution Policies
On 1/19/07, Marshall Schor [EMAIL PROTECTED] wrote: The UIMA website on Apache ( http://incubator.apache.org/uima/ ) has drafts of the Project Guidelines and Contributions Policies. Please review and comment on their content, including saying you agree - if you agree - so we can come to some concensus about this. +1 overall. I agree also with Thilo's comments. A few nits of my own: Roles and Responsibilities: * Says an ICLA is required for a Committer, but says nothing about this for Contributors. At first I thought this might mean we were not requiring an ICLA for contributors... until I got to the Contribution Guidelines and it corrected me. Maybe this could be clearer. * The PPMC section seems confusing. The title is PPMC where the first P is for podling, yet then it says it is a section that doesn't apply until after UIMA graduates. Decision Making: Says: 'Note: Lazy means the action item has immediate tactic approval'. I think this was intended to say tacit not tactic. Code Scanning Tool: http://code.google.com/p/arat/ should probably be a hyperlink. -Adam
[jira] Updated: (UIMA-125) Apache UIMA client should be able to communicate with IBM UIMA (1.x or 2.0) service
[ https://issues.apache.org/jira/browse/UIMA-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally updated UIMA-125: Fix Version/s: (was: 2.1) 2.2 As posted to uima-dev we're not going to get to this for 2.1. Pushing back to the next version, tenatively called 2.2 and scheduled for May 15. We can always change the number of release date later. Apache UIMA client should be able to communicate with IBM UIMA (1.x or 2.0) service --- Key: UIMA-125 URL: https://issues.apache.org/jira/browse/UIMA-125 Project: UIMA Issue Type: Improvement Components: Transport Adapters - SOAP, Vinci Reporter: Adam Lally Assigned To: Eddie Epstein Fix For: 2.2 Attachments: OmniFindTypeSystem.xml For ease of migration it is important that an application running Apache UIMA should be able to call services deployed under previous versions of UIMA. Previous discussions with Eddie have indicated this would be fairly straightforward for single-Sofa CASes, not necessarily for CASes containing multiple Sofas. Possibly support for single-Sofa CASes only is sufficient, as that would still help migration for the vast majority of UIMA users. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (UIMA-98) CDE Scrolling Problem on Mac
[ https://issues.apache.org/jira/browse/UIMA-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally reassigned UIMA-98: -- Assignee: Marshall Schor Marshall, I know you've been looking into Mac issues lately. Just making sure you didn't miss this one. CDE Scrolling Problem on Mac Key: UIMA-98 URL: https://issues.apache.org/jira/browse/UIMA-98 Project: UIMA Issue Type: Bug Components: Eclipse plugins Environment: Mac OS X Eclipse v3.2.1 Reporter: Adam Lally Assigned To: Marshall Schor Priority: Minor Go to the Type System definition page for a descriptor that defines many types (e.g. OpenNLPExampleTypes.xml in uimaj-examples). Resize the Editor so that the scrollbar is only partly visible (by dragging up the split bar that separates the CDE from the Console view or whatever happens to be below the CDE in your Eclipse layout). Then try to scroll in the list of types. On a Mac this does not work properly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (UIMA-214) DocumentAnalyzer shouldn't have to re-contact service to get the typesystem
DocumentAnalyzer shouldn't have to re-contact service to get the typesystem --- Key: UIMA-214 URL: https://issues.apache.org/jira/browse/UIMA-214 Project: UIMA Issue Type: Bug Components: Tools Reporter: Adam Lally Assigned To: Adam Lally Priority: Minor Fix For: 2.1 Currently when running a remote AE in the Document Analyzer, after anlaysis is complete but before the analysis results window is launched, the service is re-contacted to obtain its type system. In some situations this can be a noticeable delay. It would be better if the DocumentAnalyzer could remember the type system that was obtained earlier. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (UIMA-215) CasCopier constructor should take source CAS as argument
CasCopier constructor should take source CAS as argument Key: UIMA-215 URL: https://issues.apache.org/jira/browse/UIMA-215 Project: UIMA Issue Type: Improvement Components: Core Java Framework Reporter: Adam Lally Assigned To: Adam Lally Priority: Minor Fix For: 2.1 This would encourage users to create a new CasCopier for each source CAS. This can be important in a CAS merger, where the CasMultiplier wants to copy from multiple CASes that were passed to its process method. The CasCopier should be discarded after each call to process because its internal HashMap holds FeatureStructure references, which are not valid after the process method has completed and the source CAS has been reset. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (UIMA-215) CasCopier constructor should take source CAS as argument
[ https://issues.apache.org/jira/browse/UIMA-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally resolved UIMA-215. - Resolution: Fixed Assignee: Eddie Epstein (was: Adam Lally) CasCopier constructor should take source CAS as argument Key: UIMA-215 URL: https://issues.apache.org/jira/browse/UIMA-215 Project: UIMA Issue Type: Improvement Components: Core Java Framework Reporter: Adam Lally Assigned To: Eddie Epstein Priority: Minor Fix For: 2.1 This would encourage users to create a new CasCopier for each source CAS. This can be important in a CAS merger, where the CasMultiplier wants to copy from multiple CASes that were passed to its process method. The CasCopier should be discarded after each call to process because its internal HashMap holds FeatureStructure references, which are not valid after the process method has completed and the source CAS has been reset. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (UIMA-216) Add getSupportedXCasVersions to Vinci Services
Add getSupportedXCasVersions to Vinci Services -- Key: UIMA-216 URL: https://issues.apache.org/jira/browse/UIMA-216 Project: UIMA Issue Type: Improvement Components: Transport Adapters - SOAP, Vinci Reporter: Adam Lally Assigned To: Adam Lally Priority: Critical Fix For: 2.1 This needs to be done now, even if we don't make any use of it until v2.2. Otherwise we'll have no hope of distinguishing v1.x services from v2.1 services. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Release plan
On 1/17/07, Marshall Schor [EMAIL PROTECTED] wrote: What testing beyond the unit tests will we do for this release? Here are some items to consider: 1) test that all the Jira changes that would affect the documentation have had the documentation updated 2) Functional testing, Installation verification testing (I think we need a detailed list - how about a release test plan on the wiki?) Multi-platform testing (Win, *nix) Well for starters, I think it will be useful to for everyone to take some existing UIMA components they have available to them, try to run the migration script and follow the instructions i wrote in the manual, and try to those components in Apache UIMA. -Adam
Re: [jira] Closed: (UIMA-212) Turn on socket keepAlive in jVinci
On 1/19/07, Marshall Schor [EMAIL PROTECTED] wrote: I think you may have forgotten to check in changes to jVinci project? After I updated all the projects, build fails because The method setSocketKeepAliveEnabled(boolean) is undefined for the type VinciContext Hmmm.. I double-checked, and I have committed everything. And I can see the subversion commits attached to the JIRA issue. -Adam
Re: [jira] Closed: (UIMA-212) Turn on socket keepAlive in jVinci
Adam Lally wrote: snip Hmmm.. I double-checked, and I have committed everything. And I can see the subversion commits attached to the JIRA issue. Right you are - turned out to be operator problem (that would be me...) You see, I have some non UIMA projects in my workspace, so I have a habit of selecting all the uimaj-x projects and clicking on Update. Because jvinci follows a different naming convention, I missed updating it Sorry - Marshall
