[jira] Closed: (UIMA-1500) Deprecate UIMA 1.x classes in org.apache.uima.analysis_engine.annotator
[ https://issues.apache.org/jira/browse/UIMA-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörn Kottmann closed UIMA-1500. --- Deprecate UIMA 1.x classes in org.apache.uima.analysis_engine.annotator --- Key: UIMA-1500 URL: https://issues.apache.org/jira/browse/UIMA-1500 Project: UIMA Issue Type: Improvement Components: Core Java Framework Reporter: Jörn Kottmann Assignee: Tommaso Teofili Fix For: 2.3 Attachments: uima1500_1patch.txt, uima1500patch.txt The mentioned package contains 1.x classes and interfaces, which have a comment which suggest using 2.0 API. These classes and interfaces should be deprecated, namely these are: Annotator_ImplBase.java AnnotatorContext.java AnnotatorContext.java GenericAnnotator_ImplBase.java GenericAnnotator.java JTextAnnotator_ImplBase.java JTextAnnotator.java TextAnnotator.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
FsVariables docbook build problem on Unix
When building the FsVariables on Unix I get the following error message: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] An Ant BuildException has occured: The following error occurred while executing this line: /home/joern/uima-dev3/uima-docbook-tool/build/build-docbook.xml:29: The following error occurred while executing this line: /home/joern/uima-dev3/uima-docbook-tool/build/common-properties-per-book.xml:80: /home/joern/uima-dev3/FsVariables/docbook/fsVariablesUserGuide/images not found. The build_documentation.xml contains the following line: property name=book_name value=fsVariablesUserGuide/ If value is changed to FsVariablesUserGuide the image folder can be found. Can I check-in the correction ? Jörn
Lucas artifactId does not match folder name in svn
The maven eclipse plugin expects that the folder name of the project matches the artifactId, but that is not the case for Lucas. The artifactId is lucas and the folder name is Lucas. On Unix eclipse cannot find the lucas project, because its named Lucas. I suggest that we either change the folder name or the artifactId to be identical. Jörn
Re: Lucas artifactId does not match folder name in svn
+1 -Marshall Jörn Kottmann wrote: The maven eclipse plugin expects that the folder name of the project matches the artifactId, but that is not the case for Lucas. The artifactId is lucas and the folder name is Lucas. On Unix eclipse cannot find the lucas project, because its named Lucas. I suggest that we either change the folder name or the artifactId to be identical. Jörn
Re: FsVariables docbook build problem on Unix
Jörn Kottmann wrote: When building the FsVariables on Unix I get the following error message: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] An Ant BuildException has occured: The following error occurred while executing this line: /home/joern/uima-dev3/uima-docbook-tool/build/build-docbook.xml:29: The following error occurred while executing this line: /home/joern/uima-dev3/uima-docbook-tool/build/common-properties-per-book.xml:80: /home/joern/uima-dev3/FsVariables/docbook/fsVariablesUserGuide/images not found. The build_documentation.xml contains the following line: property name=book_name value=fsVariablesUserGuide/ If value is changed to FsVariablesUserGuide the image folder can be found. Can I check-in the correction ? Yes, this sounds right. -Marshall Jörn
Re: Files in svn for uima-as-distr for activemq-4.1.1 and activemq-5.0.0
Marshall Schor wrote: There are directories in the uima-as-distr under src/main/ for these two versions of activemq. I think the 5.0.0 isn't used. I think this should be deleted; is that right? Jerry confirms this should be deleted. What is the current thought re: which version of activeMq we include for 2.3.0? Note that changing the version percolates into some osgi plugins and other places, perhaps. I'll be consolidating version info for uima-as things in one place in the pom hierarchy (probably in the uimaj-as pom). Jerry is testing 5.2.2 and it looks like we'll probably be switching to ship that level because it fixes several issues. -Marshall -Marshall
[jira] Reopened: (UIMA-1273) Pear runtime pulls in all jar files in pear lib directory, no matter if they're on the classpath or not
[ https://issues.apache.org/jira/browse/UIMA-1273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reopened UIMA-1273: -- A user has pointed out that this behavior is documented, and it's even suggested that things in the lib do not have to be explicitly put on the PEAR classpath, in the UIMA References, section 6.1.4.5, where it says: The buildComponentClasspath method of the PackageBrowser class builds a classpath string from what it finds in the CLASSPATH specification here, plus adds a classpath entry for all Jars in the lib directory. Because of this, *there is no need to specify Class Path entries for Jars in the lib directory*. Because of this, there's a good likelyhood that this fix will break their Pear packages. Also, I saw that the existing PEAR Wrapper implementation does log (at the CONFIG level) the final Classpath and Datapath that it sets up for the PEAR, so for debugging purposes, this information should be available in the uima log. Also, if a user puts a Jar into a PEAR lib file, and packages it as part of the PEAR, it seems to me that the intent of the user is to have that Jar on the classpath. I think for these reasons, this change should be reversed. Pear runtime pulls in all jar files in pear lib directory, no matter if they're on the classpath or not --- Key: UIMA-1273 URL: https://issues.apache.org/jira/browse/UIMA-1273 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.2.2 Reporter: Thilo Goetz Fix For: 2.3 The pear runtime will not only use the classpath as defined in metadata/install.xml, it will also pick up any jar in the lib directory. It even recurses down into subdirectories. This is undocumented, and most unexpected. I chatted with Michael about this. He thinks it may be because the same code that creates the classpath in the pear packager is used in the runtime. The packager does collect all jar files it can find and puts them in the classpath, and the pear file. That's fine for the packager, but not the runtime. We should *either* have an explicit classpath, *or* use all jar files in the lib dir, but not both. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1561) UIMA Reference docs 5.5.4 DocumentAnnotation is misspelled
[ https://issues.apache.org/jira/browse/UIMA-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-1561. Resolution: Fixed Assignee: Marshall Schor UIMA Reference docs 5.5.4 DocumentAnnotation is misspelled -- Key: UIMA-1561 URL: https://issues.apache.org/jira/browse/UIMA-1561 Project: UIMA Issue Type: Bug Components: Documentation Affects Versions: 2.3 Reporter: Jörn Kottmann Assignee: Marshall Schor Priority: Trivial Fix For: 2.3 5.5.4. Adding Features to DocumentAnnotation There is one built-in type, uima.tcas.DocumentAnnotion, to which applications can add additional features. (All other built-in types are feature-final and you cannot add additional features to them.) Frequently, additional features are added to uima.tcas.DocumentAnnotion to provide a place to store document-level metadata. ... Should be uima.tcas.DocumentAnnotation and not uima.tcas.DocumentAnnotion, in the two mentions of it above. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1571) FsVariables book_name should be FsVariablesUserGuide instead of fsVariablesUserGuide
FsVariables book_name should be FsVariablesUserGuide instead of fsVariablesUserGuide Key: UIMA-1571 URL: https://issues.apache.org/jira/browse/UIMA-1571 Project: UIMA Issue Type: Bug Components: Sandbox-FsVariable Affects Versions: 2.3S Reporter: Jörn Kottmann Assignee: Jörn Kottmann Fix For: 2.3S When building the FsVariables on Unix I get the following error message: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] An Ant BuildException has occured: The following error occurred while executing this line: /home/joern/uima-dev3/uima-docbook-tool/build/build-docbook.xml:29: The following error occurred while executing this line: /home/joern/uima-dev3/uima-docbook-tool/build/common-properties-per-book.xml:80: /home/joern/uima-dev3/FsVariables/docbook/fsVariablesUserGuide/images not found. The build_documentation.xml contains the following line: property name=book_name value=fsVariablesUserGuide/ The book_name value should be changed to FsVariablesUserGuide. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1571) FsVariables book_name should be FsVariablesUserGuide instead of fsVariablesUserGuide
[ https://issues.apache.org/jira/browse/UIMA-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörn Kottmann closed UIMA-1571. --- Resolution: Fixed FsVariables book_name should be FsVariablesUserGuide instead of fsVariablesUserGuide Key: UIMA-1571 URL: https://issues.apache.org/jira/browse/UIMA-1571 Project: UIMA Issue Type: Bug Components: Sandbox-FsVariable Affects Versions: 2.3S Reporter: Jörn Kottmann Assignee: Jörn Kottmann Fix For: 2.3S When building the FsVariables on Unix I get the following error message: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] An Ant BuildException has occured: The following error occurred while executing this line: /home/joern/uima-dev3/uima-docbook-tool/build/build-docbook.xml:29: The following error occurred while executing this line: /home/joern/uima-dev3/uima-docbook-tool/build/common-properties-per-book.xml:80: /home/joern/uima-dev3/FsVariables/docbook/fsVariablesUserGuide/images not found. The build_documentation.xml contains the following line: property name=book_name value=fsVariablesUserGuide/ The book_name value should be changed to FsVariablesUserGuide. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1572) Lucas artifactId does not match folder name in svn
Lucas artifactId does not match folder name in svn -- Key: UIMA-1572 URL: https://issues.apache.org/jira/browse/UIMA-1572 Project: UIMA Issue Type: Bug Components: Sandbox-Lucas Affects Versions: 2.3S Reporter: Jörn Kottmann Assignee: Jörn Kottmann Fix For: 2.3S The maven eclipse plugin expects that the folder name of the project matches the artifactId, but that is not the case for Lucas. The artifactId is lucas and the folder name is Lucas. On Unix eclipse cannot find the lucas project, because its named Lucas. The artifactId should be changed to Lucas to solve this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1572) Lucas artifactId does not match folder name in svn
[ https://issues.apache.org/jira/browse/UIMA-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörn Kottmann closed UIMA-1572. --- Resolution: Fixed Lucas artifactId does not match folder name in svn -- Key: UIMA-1572 URL: https://issues.apache.org/jira/browse/UIMA-1572 Project: UIMA Issue Type: Bug Components: Sandbox-Lucas Affects Versions: 2.3S Reporter: Jörn Kottmann Assignee: Jörn Kottmann Fix For: 2.3S The maven eclipse plugin expects that the folder name of the project matches the artifactId, but that is not the case for Lucas. The artifactId is lucas and the folder name is Lucas. On Unix eclipse cannot find the lucas project, because its named Lucas. The artifactId should be changed to Lucas to solve this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (UIMA-1120) UIMA AS use of TimeToLive can lead to service request failures.
[ https://issues.apache.org/jira/browse/UIMA-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik reopened UIMA-1120: - Assignee: Jerry Cwiklik UIMA AS client should support -DNoTTL to disable setting time to live. Currently the code sets this TTL on JMS Producer object. UIMA AS use of TimeToLive can lead to service request failures. --- Key: UIMA-1120 URL: https://issues.apache.org/jira/browse/UIMA-1120 Project: UIMA Issue Type: Bug Components: Async Scaleout Affects Versions: 2.2.2 Reporter: Eddie Epstein Assignee: Jerry Cwiklik Attachments: uimaj-as-activemq-UIMA-1120-patch-Release-2-2-2.txt, uimaj-as-activemq-UIMA-1120-patch.txt One common scenario is that a service crashes while processing a processCas request, and additional requests are left in the service request queue. UIMA AS allows timeout values to be set for service requests so that if a reply not received within the timeout period, an error is generated on the client and appropriate actions taken. What happens to the queued service requests? If the service is restarted, it will attempt to process them and reply to the originating client. If a client receives a reply to a request that had timeout out, it will log and ignore it. If the client has gone away, the service will log and ignore the error when trying to reply. However, some requests may be expensive to process and it is desirable to avoid this work. Other requests may contain stale content that will cause problems for the new service to process. In order to avoid these problems, when a timeout value is specified UIMA AS sets TimeToLive to the timeout period. A TimeToLive setting allows the JMS system to dispose of requests that cannot be delivered in time, normally transferring them to a dead letter queue. AMQ 5.0 fully supports this mechanism, but given some blocking issues with AMQ 5.0, UIMA AS had to revert back to v4.1.1 for the first release. Up until recently our experience was that TimeToLive was ignored in AMQ 4.1.1, but this is not the case. With a AMQ C++ consumer, expired messages will be removed from the queue and thrown away. With a 4.1.1 Java consumer running under some JRE versions (e.g. Sun 1.6_02 on Linux), expired messages will be ignored and left in the queue. If this is not confusing enough, there is the AMQ definition of TimeToLive: it is based on the absolute time the message was created. Any clock skew between the producer and consumer machines will *not* be accounted for. For example, if a UIMA AS client is running on a machine whose clock is more than 60 seconds behind the machine running the UIMA AS service, a message request with a timeout of 60 seconds or less will expire before it is sent. In the future UIMA AS may implement an option to not use TimeToLive at all. The workaround for now is to make sure the clocks on all client and service machines are synchronized. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1573) setUimaClassPath fixes
setUimaClassPath fixes -- Key: UIMA-1573 URL: https://issues.apache.org/jira/browse/UIMA-1573 Project: UIMA Issue Type: Bug Components: Async Scaleout, Core Java Framework Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 2.3, 2.3AS as part of the work on UIMA-1555 we're consolidating the uima-as versions of setUimaClassPath into the base versions. As part of this process, through comparision of the 4 version (UIMA / UIMA-AS, windows / unix) many small differences became apparent, which should be fixed: 1) Some scripts missing $CATALINA_HOME/webapps/axis/WEB-INF/lib/mail.jar - Adam recalls this can be needed if the SOAP transport is set up to use attachments for binary info, instead of base64 encoding these. 2) Some scripts need updating for the .sh to export variables intended to be environment variables. 3) Some scripts need updating to account for using UIMACPP_HOME (if set). 4) The ordering of classpath Jars is different between Windows and Linux 5) CLASSPATH var, if set, is prepended to classpath - should be appended after whatever the script sets UIMA_CLASSPATH pre-existing value is prepended - should be appended after whatever the script sets LD_LIBRARY_PATH is sometimes prepended - should be appended after whatever the script sets DYLD_LIBRARY_PATH (for MacOS) is sometimes prepended - should be appended after whatever the script sets -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1573) setUimaClassPath fixes
[ https://issues.apache.org/jira/browse/UIMA-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-1573. Resolution: Fixed setUimaClassPath fixes -- Key: UIMA-1573 URL: https://issues.apache.org/jira/browse/UIMA-1573 Project: UIMA Issue Type: Bug Components: Async Scaleout, Core Java Framework Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 2.3, 2.3AS as part of the work on UIMA-1555 we're consolidating the uima-as versions of setUimaClassPath into the base versions. As part of this process, through comparision of the 4 version (UIMA / UIMA-AS, windows / unix) many small differences became apparent, which should be fixed: 1) Some scripts missing $CATALINA_HOME/webapps/axis/WEB-INF/lib/mail.jar - Adam recalls this can be needed if the SOAP transport is set up to use attachments for binary info, instead of base64 encoding these. 2) Some scripts need updating for the .sh to export variables intended to be environment variables. 3) Some scripts need updating to account for using UIMACPP_HOME (if set). 4) The ordering of classpath Jars is different between Windows and Linux 5) CLASSPATH var, if set, is prepended to classpath - should be appended after whatever the script sets UIMA_CLASSPATH pre-existing value is prepended - should be appended after whatever the script sets LD_LIBRARY_PATH is sometimes prepended - should be appended after whatever the script sets DYLD_LIBRARY_PATH (for MacOS) is sometimes prepended - should be appended after whatever the script sets -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (UIMA-1569) Marker should be make invalid when CAS is reset.
[ https://issues.apache.org/jira/browse/UIMA-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reassigned UIMA-1569: Assignee: Marshall Schor (was: Bhavani Iyer) Marker should be make invalid when CAS is reset. Key: UIMA-1569 URL: https://issues.apache.org/jira/browse/UIMA-1569 Project: UIMA Issue Type: Bug Components: Core Java Framework Reporter: Bhavani Iyer Assignee: Marshall Schor Attachments: UIMA-1569.patch When the CAS is reset any Marker created prior to the reset are invalid and should not be used for a later delta CAS serialization. The reset() should make the Marker invalid and calls to delta serialization should test whether the Marker is valid. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1569) Marker should be make invalid when CAS is reset.
[ https://issues.apache.org/jira/browse/UIMA-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-1569. Resolution: Fixed Fix Version/s: 2.3 Marker should be make invalid when CAS is reset. Key: UIMA-1569 URL: https://issues.apache.org/jira/browse/UIMA-1569 Project: UIMA Issue Type: Bug Components: Core Java Framework Reporter: Bhavani Iyer Assignee: Marshall Schor Fix For: 2.3 Attachments: UIMA-1569.patch When the CAS is reset any Marker created prior to the reset are invalid and should not be used for a later delta CAS serialization. The reset() should make the Marker invalid and calls to delta serialization should test whether the Marker is valid. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1570) Unable to set mimetime on a view post the data being added
[
https://issues.apache.org/jira/browse/UIMA-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12755316#action_12755316
]
Eddie Epstein commented on UIMA-1570:
-
I think Burn is correct:
{quote}
Well I'd thought the mimetype was tied to the sofa data, rather than to the
view. I've been using the setSofaDataXXX methods to set both the data the
mimetype. Setting the mimetype after setting the data sounds as if you're
changing the mimetype ... since it provides a way to represent the format of
the sofa data shouldn't it also be immutable once set?
{quote}
The createSofa() was deprecated in favor of createView, but not the
setSofaDataXXX() methods. These all take a mimetype argument which
must be set when the data is specified and then neither can be changed.
Sorry for the confusion,
Eddie
Unable to set mimetime on a view post the data being added
--
Key: UIMA-1570
URL: https://issues.apache.org/jira/browse/UIMA-1570
Project: UIMA
Issue Type: Improvement
Components: Core Java Framework
Reporter: Tim Cawley
Priority: Trivial
I wish to be able to set the mimetype on a view post setting the data. There
is currently a getMimtype() function but I can't find a setMimtype() function.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
