[jira] Created: (UIMA-1735) Javadoc Link on Website is Broken
Javadoc Link on Website is Broken - Key: UIMA-1735 URL: https://issues.apache.org/jira/browse/UIMA-1735 Project: UIMA Issue Type: Bug Components: Website Reporter: Adam Lally The Javadoc Online link from http://incubator.apache.org/uima/documentation.html seems to be broken. It points at: http://incubator.apache.org/uima/downloads/releaseDocs/2.3.0-incubating/docs/api/index.html, but I get a 404 Not Found error for that URL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1722) CDE is very slow to open an aggregate containing a remote UIMA-AS component
CDE is very slow to open an aggregate containing a remote UIMA-AS component --- Key: UIMA-1722 URL: https://issues.apache.org/jira/browse/UIMA-1722 Project: UIMA Issue Type: Improvement Components: Async Scaleout, Eclipse plugins Affects Versions: 2.3 Reporter: Adam Lally I have an aggregate containing 3 remote UIMA-AS components. It takes about a minute (maybe more) to open this in the CDE, which makes it very cumbersome to use. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1593) AEs that declare multipleDeploymentAllowed=false can't be deployed as services and called from multiple clients in the same JVM
AEs that declare multipleDeploymentAllowed=false can't be deployed as services and called from multiple clients in the same JVM --- Key: UIMA-1593 URL: https://issues.apache.org/jira/browse/UIMA-1593 Project: UIMA Issue Type: Bug Components: Async Scaleout, Core Java Framework Affects Versions: 2.2.2 Reporter: Adam Lally If an AnalysisEngine descriptor declares multipleDeploymentAllowed=false, the intention is that there cannot be multiple instances of it in the same JVM. UIMA reports an error if you try to embed such an AE in an aggregate that declares multipleDeploymentAllowed=true. But this only makes sense for co-located components, not services. Currently, the service wrapper returns the multipleDeploymentAllowed=false as part of the getMetaData() call. The aggregate AE checks this metadata for consistency, and at that point it isn't aware that it came from a service, so the exception is thrown. Perhaps the service wrapper should be modified to set mutlipleDeploymentAllowed to true when responding to all getMetaData() calls? Alternatively it could be done on the client side, but to me it makes more sense for the service to do it - why expose this setting if clients have no use for it? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-629) Default file names produced by XmiWriterCasConsumer don't have .xmi extension and can't be read by XmiCollectionReader
[ https://issues.apache.org/jira/browse/UIMA-629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12750168#action_12750168 ] Adam Lally commented on UIMA-629: - +1 Default file names produced by XmiWriterCasConsumer don't have .xmi extension and can't be read by XmiCollectionReader -- Key: UIMA-629 URL: https://issues.apache.org/jira/browse/UIMA-629 Project: UIMA Issue Type: Bug Components: Examples, Tools Affects Versions: 2.2 Reporter: Adam Lally Priority: Minor If the original source file name is not present in the CAS, the XmiWriterCasConsumer names the output file doc0,doc1, etc,, with no .xmi extension. The XmiCollectionReader will only read files with .xmi extensions. This is quite annoying if you're trying to break up a pipeline into two parts, writing and reading XMI files in the middle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1113) DocumentAnalyzer falls down when running pear specifier and html result view
[ https://issues.apache.org/jira/browse/UIMA-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12749519#action_12749519 ] Adam Lally commented on UIMA-1113: -- To get the metadata from the PEAR specifier we'd need to instantiate it and then call AnalysisEngine.getMetaData. So the code that gets the metadata needs to get moved to a later point after initialization has occurred. The AE is instantiated inside a CPE right now; I can't remember if you can pull out the AnalysisEngine instance from there, but maybe. DocumentAnalyzer falls down when running pear specifier and html result view Key: UIMA-1113 URL: https://issues.apache.org/jira/browse/UIMA-1113 Project: UIMA Issue Type: Bug Components: Tools Affects Versions: 2.2.2 Reporter: Thilo Goetz Priority: Minor Fix For: 2.3 Throws an invalid XML exception. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-941) No ProcessTrace events for process calls that take 0ms
[ https://issues.apache.org/jira/browse/UIMA-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12749523#action_12749523 ] Adam Lally commented on UIMA-941: - In AnalysisEngineImplBase.buildProcessTraceFromMBeanStats, it is specifically checking for a time 0 before adding an event. We could remove that check. I think the intention of that check might have been for remote services where analysis time is not available (but service call time is), and so it was better to not log an analysis time than to log an artificial time of 0. A way to fix that would be to set times originally to -1 [indicating not applicable] and change them to 0 the first time any time is logged. A simpler alternative might be in the case where both service call time and analysis time are 0, to create an Analysis entry in the ProcessTrace, with a time of 0. No ProcessTrace events for process calls that take 0ms -- Key: UIMA-941 URL: https://issues.apache.org/jira/browse/UIMA-941 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.2.2 Environment: Windows XP, Java 1.5 Reporter: Thilo Goetz Priority: Minor Found when testing release candidate 4 of 2.2.2. Here's the text of an email I wrote. Adam responded that it's probably a bug. http://www.mail-archive.com/uima-dev%40incubator.apache.org/msg06565.html I was just testing CVD for the next release, and tried out the new performance report feature. Internally, this uses the ProcessTrace feature of AnalysisEngine.process(). It seems that if the process() call returns very quickly, i.e., in 0ms according to the Java timer, no ProcessTrace sub-events are recorded. For example, I'm running the tagger, and here's some output I get: This one looks fine, as expected: 3/27/08 4:29:52 PM - 10: org.apache.uima.tools.cvd.MainFrame.internalRunAE(1570): INFO: Process trace of AE run: Component Name: HmmTaggerTAE Event Type: Analysis Duration: 2078ms (100%) Sub-events: Component Name: WhitespaceTokenizer Event Type: Analysis Duration: 265ms (12.75%) Component Name: Hidden Markov Model - Part of Speech Tagger Event Type: Analysis Duration: 1813ms (87.25%) Component Name: Fixed Flow Controller Event Type: Analysis Duration: 0ms (0%) Next one seems to have lost the tagger: 3/27/08 4:30:08 PM - 10: org.apache.uima.tools.cvd.MainFrame.internalRunAE(1570): INFO: Process trace of AE run: Component Name: HmmTaggerTAE Event Type: Analysis Duration: 16ms (100%) Sub-events: Component Name: WhitespaceTokenizer Event Type: Analysis Duration: 16ms (100%) Component Name: Fixed Flow Controller Event Type: Analysis Duration: 0ms (0%) Finally, this one only has the flow controller: 3/27/08 4:30:19 PM - 10: org.apache.uima.tools.cvd.MainFrame.internalRunAE(1570): INFO: Process trace of AE run: Component Name: HmmTaggerTAE Event Type: Analysis Duration: 0ms Sub-events: Component Name: Fixed Flow Controller Event Type: Analysis Duration: 0ms Looking at this in the debugger, there are no subevents there, so it's not a problem with the printing. Is this expected, or is it a bug? Seems to me it is a bug, but I'm not sure from the documentation. --Thilo -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1496) Generics for CasCreationUtils
[ https://issues.apache.org/jira/browse/UIMA-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744064#action_12744064 ] Adam Lally commented on UIMA-1496: -- Seems okay. Generics for CasCreationUtils - Key: UIMA-1496 URL: https://issues.apache.org/jira/browse/UIMA-1496 Project: UIMA Issue Type: Improvement Components: Core Java Framework Affects Versions: 2.3 Reporter: Jörn Kottmann Assignee: Jörn Kottmann Fix For: 2.3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1417) ResourceConfigurationException to be thrown from the initialize(context) method
[ https://issues.apache.org/jira/browse/UIMA-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12742378#action_12742378 ] Adam Lally commented on UIMA-1417: -- I think the documentation is wrong and should be changed. ResourceConfigurationException to be thrown from the initialize(context) method --- Key: UIMA-1417 URL: https://issues.apache.org/jira/browse/UIMA-1417 Project: UIMA Issue Type: Improvement Components: Core Java Framework, Documentation Affects Versions: 2.2.2 Environment: Windows XP, Java 1.5 Reporter: nikolay georgiev Original Estimate: 0.5h Remaining Estimate: 0.5h Hello, In the UIMA Tutorial and Developer's Guide, section Throwing Exceptions from Annotators, it is written that one can throw 3 kinds of exceptions, one of which is the ResourceConfigurationException. And it is written that is good to read the configuration parameters in the inialize() method, but unfortunately the initialize() method can throw only ResourceInitializationException, so I am not able to throw the ResourceConfigurationException. The method signature is: public void initialize(UimaContext context) throws ResourceInitializationException Can you add also the ResourceConfigurationException or correct the documentation? Greetings, Nikolay -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1257) Type System Merging Should Produce Consistent Ordering of Types
[ https://issues.apache.org/jira/browse/UIMA-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-1257. Resolution: Fixed Issue declared fixed by popular demand. Type System Merging Should Produce Consistent Ordering of Types --- Key: UIMA-1257 URL: https://issues.apache.org/jira/browse/UIMA-1257 Project: UIMA Issue Type: Improvement Components: Core Java Framework Affects Versions: 2.2.2 Reporter: Adam Lally Assignee: Adam Lally Priority: Minor Fix For: 2.3 Currently when type systems are merged across annotators, the ordering of the types produced by the merge method is not defined, and varies according to the ordering in which the individual type system descriptors are passed to the merge method. The ordering depends on the order in which individual AEs are initialized, which is also not defined, and may even vary according to JVM version. One reason to improve this is that UIMA-AS has a feature to allow binary serialization, but it requires that type systems be identical on both sides of the connection, and it is difficult to ensure this if ordering cannot be relied on. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1257) Type System Merging Should Produce Consistent Ordering of Types
[ https://issues.apache.org/jira/browse/UIMA-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12735825#action_12735825 ] Adam Lally commented on UIMA-1257: -- I've rethought my last comment. I recently happened to accidentally discover that default type priorities can change even from something like changing from Java 5 to Java 6. So given that we already have unpredictable default type priorities, I don't feel so bad about introducing a different change that shakes them up. In fact, once this change is implemented, it will add more stability going forward. Any objection if I close this issue and leave the code in there that sorts types alphabetically prior to creating the CAS? Type System Merging Should Produce Consistent Ordering of Types --- Key: UIMA-1257 URL: https://issues.apache.org/jira/browse/UIMA-1257 Project: UIMA Issue Type: Improvement Components: Core Java Framework Affects Versions: 2.2.2 Reporter: Adam Lally Assignee: Adam Lally Priority: Minor Fix For: 2.3 Currently when type systems are merged across annotators, the ordering of the types produced by the merge method is not defined, and varies according to the ordering in which the individual type system descriptors are passed to the merge method. The ordering depends on the order in which individual AEs are initialized, which is also not defined, and may even vary according to JVM version. One reason to improve this is that UIMA-AS has a feature to allow binary serialization, but it requires that type systems be identical on both sides of the connection, and it is difficult to ensure this if ordering cannot be relied on. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1344) XCAS Serialization doesn't handle StringArrays with null elements
[ https://issues.apache.org/jira/browse/UIMA-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-1344. Resolution: Fixed Fixed to write empty array element to XCAS instead of throwing NPE. XCAS Serialization doesn't handle StringArrays with null elements - Key: UIMA-1344 URL: https://issues.apache.org/jira/browse/UIMA-1344 Project: UIMA Issue Type: Bug Components: Core Java Framework, Transport Adapters - SOAP, Vinci Affects Versions: 2.2.2 Reporter: Adam Lally Assignee: Adam Lally Fix For: 2.3 This code illustrates the problem: //create string array where some elements are unset (null) StringArrayFS strArray = cas.createStringArrayFS(3); strArray.set(1, value); cas.getIndexRepository().addFS(strArray); //serialize to XCAS ByteArrayOutputStream baos = new ByteArrayOutputStream(); XCASSerializer.serialize(cas,baos); This problem affects Vinci services -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1344) XCAS Serialization doesn't handle StringArrays with null elements
XCAS Serialization doesn't handle StringArrays with null elements - Key: UIMA-1344 URL: https://issues.apache.org/jira/browse/UIMA-1344 Project: UIMA Issue Type: Bug Components: Core Java Framework, Transport Adapters - SOAP, Vinci Affects Versions: 2.2.2 Reporter: Adam Lally Assignee: Adam Lally Fix For: 2.3 This code illustrates the problem: //create string array where some elements are unset (null) StringArrayFS strArray = cas.createStringArrayFS(3); strArray.set(1, value); cas.getIndexRepository().addFS(strArray); //serialize to XCAS ByteArrayOutputStream baos = new ByteArrayOutputStream(); XCASSerializer.serialize(cas,baos); This problem affects Vinci services -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-857) Change startup of framework to support versioned Jars and simplified classpath
[ https://issues.apache.org/jira/browse/UIMA-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674628#action_12674628 ] Adam Lally commented on UIMA-857: - I'm not sure if there's a way to check in the Eclipse library definitions to SVN and share them. If there is then this would probably be an okay way to deal with this. But so far the only experience I've had with the Eclipse libraries is checking out somebody's .classpath file that referred to library and not being able to compile anything because the library was undefined, which is not nice. The bottom line for me is: The Java runtime doesn't have a native way to easily support jar file names that change all the time. Yes, various development environments and embedding applications have invented ways to add a level of abstraction on top of jar file names, but there's no standard way of doing so, and the existing solutions are sometimes not ideal. It just seems simpler to me to avoid this whole issue by leaving our jar file names the way they are. I know, some people feel strongly that they like to see what version they have just by looking at the file name, but I don't happen to be one of those people. I agree that the UIMA_JARPATH idea is separate from the file names and have no objection to implementing that. Change startup of framework to support versioned Jars and simplified classpath -- Key: UIMA-857 URL: https://issues.apache.org/jira/browse/UIMA-857 Project: UIMA Issue Type: Improvement Components: Build, Packaging and Test Reporter: Marshall Schor Priority: Minor Our approach to the framework classpath is to (a) strip version info from our Jar names, and (b) have a setUimaClassPath script that adds lots of these (unversioned) jars to the classpath. Other systems use a different approach - usually putting all the jars that should be in the classpath into a directory, and then having a small wrapper jar (with an unversioned name) that adds all the jars it finds in this dir to the classpath. (See for instance, ActiveMQ startup, or the way things like Tomcat work).Change UIMA to use this approach. (Not for 2.2.2, but for following release, perhaps). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-857) Change startup of framework to support versioned Jars and simplified classpath
[ https://issues.apache.org/jira/browse/UIMA-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674351#action_12674351 ] Adam Lally commented on UIMA-857: - Personally, I still strongly dislike version numbers in jar file names, and it doesn't have anything to do with the setUimaClasspath script, which I don't really use. It has more to do with Eclipse - if I have lots of projects depending on uima jars, then every time I got a new version I'd have to go through them all and update their classpaths. It's not specifically I think we are not in the same situation as Tomcat, because Tomcat is a container in which you embed things, whereas UIMA gets embedded in other things. Therefore, by changing our jar file names we are requiring those embedders to keep up with us. I would not want to have to use a special jar loader in my application just to use UIMA. Change startup of framework to support versioned Jars and simplified classpath -- Key: UIMA-857 URL: https://issues.apache.org/jira/browse/UIMA-857 Project: UIMA Issue Type: Improvement Components: Build, Packaging and Test Reporter: Marshall Schor Priority: Minor Our approach to the framework classpath is to (a) strip version info from our Jar names, and (b) have a setUimaClassPath script that adds lots of these (unversioned) jars to the classpath. Other systems use a different approach - usually putting all the jars that should be in the classpath into a directory, and then having a small wrapper jar (with an unversioned name) that adds all the jars it finds in this dir to the classpath. (See for instance, ActiveMQ startup, or the way things like Tomcat work).Change UIMA to use this approach. (Not for 2.2.2, but for following release, perhaps). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (UIMA-1257) Type System Merging Should Produce Consistent Ordering of Types
[ https://issues.apache.org/jira/browse/UIMA-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally reopened UIMA-1257: -- Sorting the type definitions causes a change in the default type priorities. This in turn may break applications that are relying on the default type priorities. Even though this practice is not recommended, we should fix this to maintain compatibility. What's needed is to have the default type priorities based on the unsorted type definitions, but the assignment of type codes to types based on sorted definitions. Type System Merging Should Produce Consistent Ordering of Types --- Key: UIMA-1257 URL: https://issues.apache.org/jira/browse/UIMA-1257 Project: UIMA Issue Type: Improvement Components: Core Java Framework Affects Versions: 2.2.2 Reporter: Adam Lally Assignee: Adam Lally Priority: Minor Fix For: 2.3 Currently when type systems are merged across annotators, the ordering of the types produced by the merge method is not defined, and varies according to the ordering in which the individual type system descriptors are passed to the merge method. The ordering depends on the order in which individual AEs are initialized, which is also not defined, and may even vary according to JVM version. One reason to improve this is that UIMA-AS has a feature to allow binary serialization, but it requires that type systems be identical on both sides of the connection, and it is difficult to ensure this if ordering cannot be relied on. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1257) Type System Merging Should Produce Consistent Ordering of Types
Type System Merging Should Produce Consistent Ordering of Types --- Key: UIMA-1257 URL: https://issues.apache.org/jira/browse/UIMA-1257 Project: UIMA Issue Type: Improvement Components: Core Java Framework Affects Versions: 2.2.2 Reporter: Adam Lally Assignee: Adam Lally Priority: Minor Fix For: 2.3 Currently when type systems are merged across annotators, the ordering of the types produced by the merge method is not defined, and varies according to the ordering in which the individual type system descriptors are passed to the merge method. The ordering depends on the order in which individual AEs are initialized, which is also not defined, and may even vary according to JVM version. One reason to improve this is that UIMA-AS has a feature to allow binary serialization, but it requires that type systems be identical on both sides of the connection, and it is difficult to ensure this if ordering cannot be relied on. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (UIMA-1257) Type System Merging Should Produce Consistent Ordering of Types
[ https://issues.apache.org/jira/browse/UIMA-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on UIMA-1257 started by Adam Lally. Type System Merging Should Produce Consistent Ordering of Types --- Key: UIMA-1257 URL: https://issues.apache.org/jira/browse/UIMA-1257 Project: UIMA Issue Type: Improvement Components: Core Java Framework Affects Versions: 2.2.2 Reporter: Adam Lally Assignee: Adam Lally Priority: Minor Fix For: 2.3 Currently when type systems are merged across annotators, the ordering of the types produced by the merge method is not defined, and varies according to the ordering in which the individual type system descriptors are passed to the merge method. The ordering depends on the order in which individual AEs are initialized, which is also not defined, and may even vary according to JVM version. One reason to improve this is that UIMA-AS has a feature to allow binary serialization, but it requires that type systems be identical on both sides of the connection, and it is difficult to ensure this if ordering cannot be relied on. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1257) Type System Merging Should Produce Consistent Ordering of Types
[ https://issues.apache.org/jira/browse/UIMA-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-1257. Resolution: Fixed Fixed by sorting types alphabetically inside CasCreationUtils.mergeTypeSystems Type System Merging Should Produce Consistent Ordering of Types --- Key: UIMA-1257 URL: https://issues.apache.org/jira/browse/UIMA-1257 Project: UIMA Issue Type: Improvement Components: Core Java Framework Affects Versions: 2.2.2 Reporter: Adam Lally Assignee: Adam Lally Priority: Minor Fix For: 2.3 Currently when type systems are merged across annotators, the ordering of the types produced by the merge method is not defined, and varies according to the ordering in which the individual type system descriptors are passed to the merge method. The ordering depends on the order in which individual AEs are initialized, which is also not defined, and may even vary according to JVM version. One reason to improve this is that UIMA-AS has a feature to allow binary serialization, but it requires that type systems be identical on both sides of the connection, and it is difficult to ensure this if ordering cannot be relied on. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1258) Optimize performance of CasCopier when input and output TypeSystems are the same
Optimize performance of CasCopier when input and output TypeSystems are the same Key: UIMA-1258 URL: https://issues.apache.org/jira/browse/UIMA-1258 Project: UIMA Issue Type: Improvement Components: Core Java Framework Affects Versions: 2.2.2 Reporter: Adam Lally Assignee: Adam Lally Priority: Minor The CasCopier can spend a lot of time looking up type and feature handles, which is wasted when the TypeSystems of the input and output CASes are identical. This should be optimized so that type and feature handles from the source CAS can be used in the target CAS whenever they share a TypeSystem object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1258) Optimize performance of CasCopier when input and output TypeSystems are the same
[ https://issues.apache.org/jira/browse/UIMA-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-1258. Resolution: Fixed Fix Version/s: 2.3 Optimize performance of CasCopier when input and output TypeSystems are the same Key: UIMA-1258 URL: https://issues.apache.org/jira/browse/UIMA-1258 Project: UIMA Issue Type: Improvement Components: Core Java Framework Affects Versions: 2.2.2 Reporter: Adam Lally Assignee: Adam Lally Priority: Minor Fix For: 2.3 The CasCopier can spend a lot of time looking up type and feature handles, which is wasted when the TypeSystems of the input and output CASes are identical. This should be optimized so that type and feature handles from the source CAS can be used in the target CAS whenever they share a TypeSystem object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1256) UIMA-AS XMI serialization loses items appended to an FSList
UIMA-AS XMI serialization loses items appended to an FSList --- Key: UIMA-1256 URL: https://issues.apache.org/jira/browse/UIMA-1256 Project: UIMA Issue Type: Bug Components: Async Scaleout Affects Versions: 2.2.2 Reporter: Adam Lally I have an FSList that contains 2 FeatureStructures. I send it to a remote annotator that creates approximately 40 new FeatureStructures and appends them to the end of the FSList. It also adds these new FSs to the indexes. When I use xmi serialization, the CAS comes back without the new FSs having been added to the FSList, although I do see them in the indexes. When I use binary serialization, all works fine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1252) UIMA-Can't run
UIMA-Can't run --- Key: UIMA-1252 URL: https://issues.apache.org/jira/browse/UIMA-1252 Project: UIMA Issue Type: Bug Reporter: Adam Lally Priority: Minor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Deleted: (UIMA-1252) UIMA-Can't run
[ https://issues.apache.org/jira/browse/UIMA-1252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally deleted UIMA-1252: - UIMA-Can't run --- Key: UIMA-1252 URL: https://issues.apache.org/jira/browse/UIMA-1252 Project: UIMA Issue Type: Bug Reporter: Adam Lally Priority: Minor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1253) UIMA-AS Can't run Aggregate containing a CAS Consumer delegate
UIMA-AS Can't run Aggregate containing a CAS Consumer delegate -- Key: UIMA-1253 URL: https://issues.apache.org/jira/browse/UIMA-1253 Project: UIMA Issue Type: Bug Components: Async Scaleout Affects Versions: 2.2.2 Reporter: Adam Lally Priority: Minor I have an aggregate that contains a CAS Consumer as a delegate. When I deploy this as an async aggregate in UIMA-AS, it complains: java.lang.ClassCastException: org.apache.uima.collection.impl.CasConsumerDescription_impl at org.apache.uima.aae.controller.PrimitiveAnalysisEngineController_impl.assignServiceMetadata(PrimitiveAnalysisEngineController_impl.java:165) at org.apache.uima.aae.controller.PrimitiveAnalysisEngineController_impl.initializeAnalysisEngine(PrimitiveAnalysisEngineController_impl.java:143) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1247) MBean Registration not thread-safe
[ https://issues.apache.org/jira/browse/UIMA-1247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-1247. This fix works for me. Thanks! MBean Registration not thread-safe -- Key: UIMA-1247 URL: https://issues.apache.org/jira/browse/UIMA-1247 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.2.2 Reporter: Adam Lally Assignee: Adam Lally Priority: Minor Fix For: 2.3 If you create multiple instances of the same Analysis Engine simultaneously in different threads, it often results in WARNING messages being written to the log file about failed JMX MBean registration. These don't cause the AE to fail, but the messages are disconcerting, especially since they contain the entire stack trace. When logging is going to the console these messages can be mistaken for serious errors. At the very least the warning should not contain the stack trace so it doesn't look as threatening. Better would be to fix the MBean registration so it does not encounter these problems. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1248) ResourceManager initialization is not thread-safe
ResourceManager initialization is not thread-safe - Key: UIMA-1248 URL: https://issues.apache.org/jira/browse/UIMA-1248 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.2.2 Reporter: Adam Lally Assignee: Adam Lally Priority: Minor If multiple threads concurrently call UIMAFramework.produceAnalysisEngine and pass the same instance of ResourceManager as an argument, you can get intermittent exceptions in the ResourceManager such as: java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Native Method) at java.util.ArrayList.ensureCapacity(ArrayList.java:170) at java.util.ArrayList.add(ArrayList.java:351) at org.apache.uima.resource.impl.CasManager_impl.addMetaData(CasManager_impl.java:82) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.initialize(AnalysisEngineImplBase.java:115) at org.apache.uima.analysis_engine.impl.AggregateAnalysisEngine_impl.initialize(AggregateAnalysisEngine_impl.java:126) The workaround is to synchronize the calls to UIMAFramework.produceAnalysisEngine. However, this is suboptimal if annotator initialization is expensive and you want it to be run in parallel on multiple cores. We should consider adding synchronization to the ResourceManager (and the classes it delegates to such as CasManager) to allow this to work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1223) Annotators should be initialized in the same thread that their process method will later be called on
[ https://issues.apache.org/jira/browse/UIMA-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12655240#action_12655240 ] Adam Lally commented on UIMA-1223: -- There is a problem in this patch due to UIMA-1248, which causes concurrent initialization of AE instances sharing a ResourceManager to fail intermittently. We should work around this by synchronizing the call to UIMAFramework.produceAnalysisEngine so that only one instance can be initialized at a time, until UIMA-1248 gets fixed. Annotators should be initialized in the same thread that their process method will later be called on - Key: UIMA-1223 URL: https://issues.apache.org/jira/browse/UIMA-1223 Project: UIMA Issue Type: Bug Components: Async Scaleout Affects Versions: 2.2.2 Reporter: Adam Lally Assignee: Jerry Cwiklik Attachments: uimaj-as-activemq-UIMA-1223-patch.txt, uimaj-as-core-UIMA-1223-patch.txt It is more convenient if an annotator is initialized on the same thread that it is later called on. Some components may use thread-local data and they won't work in UIMA-AS currently. Another advantage of doing the initialization in the processing thread is that you could initialize multiple instances of the annotator in parallel instead of sequentially, which may be faster for a multi-core machine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1247) MBean Registration not thread-safe
[ https://issues.apache.org/jira/browse/UIMA-1247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12654892#action_12654892 ] Adam Lally commented on UIMA-1247: -- This is what gets logged: WARNING: JMX failiure: Failed to register MBean. java.lang.reflect.InvocationTargetException 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:585) at org.apache.uima.internal.util.JmxMBeanAgent.registerMBean(JmxMBeanAgent.java:70) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.initialize(AnalysisEngineImplBase.java:134) Caused By: javax.management.InstanceAlreadyExistsException at com.sun.jmx.mbeanserver.RepositorySupport.addMBean(RepositorySupport.java:452) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.internal_addObject(DefaultMBeanServerInterceptor.java:1410) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:936) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:337) at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:497) MBean Registration not thread-safe -- Key: UIMA-1247 URL: https://issues.apache.org/jira/browse/UIMA-1247 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.2.2 Reporter: Adam Lally Assignee: Adam Lally Priority: Minor If you create multiple instances of the same Analysis Engine simultaneously in different threads, it often results in WARNING messages being written to the log file about failed JMX MBean registration. These don't cause the AE to fail, but the messages are disconcerting, especially since they contain the entire stack trace. When logging is going to the console these messages can be mistaken for serious errors. At the very least the warning should not contain the stack trace so it doesn't look as threatening. Better would be to fix the MBean registration so it does not encounter these problems. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1245) Processing order of parent CAS different on UIMA and UIMA AS
[ https://issues.apache.org/jira/browse/UIMA-1245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12654598#action_12654598 ] Adam Lally commented on UIMA-1245: -- Actually I think your proposal to block the parent upon return to the AGGR ~outer~ is already implied by the original proposal. That's because AGGR ~inner~ is a CAS Multiplier, and therefore its parent CAS should be blocked from further processing until its children have finished processing in AGGR ~outer~. It's a good point though that this wouldn't be exactly identical to the single-threaded case. The relative order of 2 components being executed would be the same as the synchronous case whenever those 2 components were sibilngs (contained in the same aggregate, at the same level of nesting), but not when they were at different levels of nesting. I think that's still good enough, though. Processing order of parent CAS different on UIMA and UIMA AS Key: UIMA-1245 URL: https://issues.apache.org/jira/browse/UIMA-1245 Project: UIMA Issue Type: Bug Components: Async Scaleout Reporter: Eddie Epstein Arron Kaplan raised the question of when parent CASes are processed relative to their children. See http://markmail.org/message/5cop7iv2nshouhgs As of now, the processing order for a multi-threaded UIMA AS aggregate is different than that for a single-threaded UIMA aggregate. A discussion with Burn, Adam, Jerry, Marshall and myself concluded that the default processing order for UIMA AS should be changed to be the same as in UIMA, in order to have the same application behavior for both. This will be done by suspending flow of a parent CAS after it is returned from a CasMultiplier delegate until all its children CASes have finished processing. However, there also needs to be a UIMA AS deployment option for CasMultiplier delegates that allows the parent CAS to resume processing immediately after being returned from the CM. This option is needed to enable parallel processing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1240) Deployment Descriptor Editor resets CAS Pool size for aggregates when you change number of instances of a delegate
Deployment Descriptor Editor resets CAS Pool size for aggregates when you change number of instances of a delegate -- Key: UIMA-1240 URL: https://issues.apache.org/jira/browse/UIMA-1240 Project: UIMA Issue Type: Bug Components: Async Scaleout Affects Versions: 2.3AS Reporter: Adam Lally Assignee: Tong Fin I have an async aggregate with multiple delegates. When I set the number of instances of one of the delegates (it happened to be a CAS Multiplier, but I'm not sure that matters), the DDE automatically reset the CAS Pool size of the entire aggregate to the same value! It took me quite a while to figure out that this was the reason my application started running more slowly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1107) Annotator context not set when annotator loaded from PEAR
[ https://issues.apache.org/jira/browse/UIMA-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12649742#action_12649742 ] Adam Lally commented on UIMA-1107: -- Does your new class need to be a subclass of ResourceManager_impl, or is it possible to instead create a PearWrapperResourceManager_impl that implements the ResourceManager interface and delegates all of the methods except for the classpath/datapath to the parent ResourceManager instance? Then it should still work if someone substitutes a different ResourceManager implementation for the parent resource manager. Annotator context not set when annotator loaded from PEAR - Key: UIMA-1107 URL: https://issues.apache.org/jira/browse/UIMA-1107 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.2.2 Reporter: Aaron Kaplan Assignee: Marshall Schor Fix For: 2.3 I have an aggregate annotator consisting of an annotator A1 that creates a new sofa, and an annotator A2 that annotates the new sofa. A2 is not sofa-aware, so in the aggregate descriptor I have defined a sofa mapping. In the delegateAnalysisEngine element of the aggregate descriptor, if I point to A2's component descriptor (A2/desc/A2.xml), the sofa mapping works: A2 processes the new sofa created by A1. If I point instead to A2's pear installation descriptor (A2/A2_pear.xml), the sofa mapping seems not to be applied: A2 processes the initial sofa instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1230) When parsing an aggregate descriptor, should parse a shared type system file only once
When parsing an aggregate descriptor, should parse a shared type system file only once -- Key: UIMA-1230 URL: https://issues.apache.org/jira/browse/UIMA-1230 Project: UIMA Issue Type: Improvement Components: Core Java Framework Affects Versions: 2.2.2 Reporter: Adam Lally Assignee: Adam Lally Priority: Minor Fix For: 2.3 Frequently an aggregate will contain several primitives that all import a single shared type system descriptor. Currently, the shared type system descriptor will be separately parsed for each of the primitives, and each primitive descriptor will contain a separate copy of the TypeSystemDescription object. When there are a large number of primitives and a large number of types in the shared type system, this parsing takes a long time and the resulting TypeSystemDescription objects consume a lot of memory. Instead, we could keep a cache of imports that have already been parsed, and we can reuse the same TypeSystemDescription object within each of the primitive descriptors rather than having a separate copy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1119) The XmiCasDeserializer throws NoSuchElementException if an XCAS is corrupted, but doesn't report the offending element.
[ https://issues.apache.org/jira/browse/UIMA-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12646557#action_12646557 ] Adam Lally commented on UIMA-1119: -- I don't see anything wrong with the term XMI CAS - seems like a perfect description. What is the objection to it? I agree with Burn's idea that the error messages don't need to specify which format is being used. The XmiCasDeserializer throws NoSuchElementException if an XCAS is corrupted, but doesn't report the offending element. --- Key: UIMA-1119 URL: https://issues.apache.org/jira/browse/UIMA-1119 Project: UIMA Issue Type: Improvement Components: Core Java Framework Affects Versions: 2.2.2 Reporter: Burn Lewis Assignee: Marshall Schor Priority: Minor Attachments: UIMA-1119-3.patch Obviously it's dangerous to edit XCASes but it is often the quickest way to produce a variety of test cases for an annotator. By changing a few lines we can report the invalid id. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1223) Annotators should be initialized in the same thread that their process method will later be called on
Annotators should be initialized in the same thread that their process method will later be called on - Key: UIMA-1223 URL: https://issues.apache.org/jira/browse/UIMA-1223 Project: UIMA Issue Type: Bug Components: Async Scaleout Affects Versions: 2.2.2 Reporter: Adam Lally Assignee: Jerry Cwiklik It is more convenient if an annotator is initialized on the same thread that it is later called on. Some components may use thread-local data and they won't work in UIMA-AS currently. Another advantage of doing the initialization in the processing thread is that you could initialize multiple instances of the annotator in parallel instead of sequentially, which may be faster for a multi-core machine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1199) If a parallel flow involves colocated delegates the application hangs
[ https://issues.apache.org/jira/browse/UIMA-1199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12638917#action_12638917 ] Adam Lally commented on UIMA-1199: -- Synchronous UIMA runs them in sequence, and I think it's best to be consistent. A Flow Controller should be able to issue a ParallelStep to indicate that 2 things may logically be run in parallel, not that they *must* be run in parallel. If a parallel flow involves colocated delegates the application hangs - Key: UIMA-1199 URL: https://issues.apache.org/jira/browse/UIMA-1199 Project: UIMA Issue Type: Bug Components: Async Scaleout Affects Versions: 2.2.2 Reporter: Burn Lewis Priority: Minor Attachments: UIMA-1199-test.patch, uimaj-as-core-UIMA-1199-patch-01.txt, uimaj-as-core-UIMA-1199-patch-02.txt Parallel flows can only run in parallel when the delegates are remote, but we should handle any colocated ones by running them sequentially in arbitrary order as synchronous UIMA does. The spec says that the framework is not obliged to run them in parallel. The alternative of rejecting the flow is undesirable as it can only be detected at run time since the flow controller may be user code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1177) Consider making the default setting for Auto Generate JCAS Java source files be off.
Consider making the default setting for Auto Generate JCAS Java source files be off. -- Key: UIMA-1177 URL: https://issues.apache.org/jira/browse/UIMA-1177 Project: UIMA Issue Type: Improvement Components: Eclipse plugins Reporter: Adam Lally Priority: Minor Fix For: 2.3 I think the default should be to not generate the JCAS source files when you save an Analysis Engine Descriptor. (I can see generating when you save a Type System Descriptor, maybe.) Our AE descriptors change far more frequently than our type system does, and it is disruptive to have all the type system classes regenerated all the time. My guess would be that most other people are also in this situation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1176) JCasGen shouldn't generate types for imported type systems (or at least it should be an option)
[ https://issues.apache.org/jira/browse/UIMA-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12631628#action_12631628 ] Adam Lally commented on UIMA-1176: -- Well, how about this: If my main type system descriptor imports another type system descriptor that is not in the same Eclipse project, then JCasGen should not generated classes for those imported types. When the type system descriptors are in different projects, I think it is very likely that they represent separate modules of the type system that are maintained on their own. I want to keep the JCas classes for each module in the same project (or jar) as the type system descriptor for that module. If I import this module into another type system, I don't want JCasGen making additional copies of my JCas classes into every place where I use that module. JCasGen shouldn't generate types for imported type systems (or at least it should be an option) --- Key: UIMA-1176 URL: https://issues.apache.org/jira/browse/UIMA-1176 Project: UIMA Issue Type: Improvement Components: Eclipse plugins, Tools Affects Versions: 2.3 Reporter: Adam Lally Our project reuses a common type system that we got from a different source. The common type system descriptor is imported into our main type system descriptor. The common type system has its own JCas types, in a jar file. When we generate JCas types for our main type system descriptor, it currently generates all of the classes for all of the imported type systems as well. We don't want this behavior, so we have to manually go through and delete those classes. I think JCasGen should only generate types for the type system descriptor that you run it on, not on imported type system descriptors. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1163) set svn:eol-style to native for source files in UIMA project
[ https://issues.apache.org/jira/browse/UIMA-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12628185#action_12628185 ] Adam Lally commented on UIMA-1163: -- As I recall, the maven build scripts explicitly set the file permissions on the scripts in the core uima build. set svn:eol-style to native for source files in UIMA project Key: UIMA-1163 URL: https://issues.apache.org/jira/browse/UIMA-1163 Project: UIMA Issue Type: Improvement Components: Core Java Framework Affects Versions: 2.2.2 Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor set the svn:eol-style to native for java source files in the UIMA project. (Other sandbox projects may also want to do similar things, and the uimaCPP project, and the site project). Don't set this for scripts - the ones that are intended to run on windows probably can have either line ending style, but I think the ones that run on the various linuxes need the unix style. This is so that extracts for builds done on a windows machine can properly build a linux distribution. Don't set this for test data - some UTF-16 or UTF-8 test data may have things intentionally present that might look like line endings, but are not, and should not be disturbed by checkout. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1129) XMI serialization support for delta CAS
[ https://issues.apache.org/jira/browse/UIMA-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625762#action_12625762 ] Adam Lally commented on UIMA-1129: -- -1. We can't have arbitrary clients turn on Delta CAS mode for everybody else. This must be a global setting. What we want is that when one client turns on delta CAS it does not affect others, but I think that means it must NOT be a global setting. It looks to me like reset() is clearing the mark, so in the case where a client uses the mark and then releases the CAS back to a pool for other clients to use, other clients will not be affected. So I am not sure I see the problem you are objecting to. bq. It's also faster. Could you please clarify. Are you saying checking a boolean is faster than checking if an object reference is null ? I think so, though I admit it's only conjecture. My intuition is that these ought to be the same speed - aren't both just checking a memory location to see if equals some constant value? Without some proof that a boolean check is faster, I'm inclined to say the current implementation is fine. XMI serialization support for delta CAS - Key: UIMA-1129 URL: https://issues.apache.org/jira/browse/UIMA-1129 Project: UIMA Issue Type: New Feature Components: Core Java Framework Reporter: Bhavani Iyer Assignee: Bhavani Iyer Attachments: UIMA-1129.patch Extend XMI serialization to enable serializing only the changes to the CAS. The requirement for delta CAS support in order to to reduce serialization overhead associated with remote services is described in the wiki page found here: http://cwiki.apache.org/UIMA/reducing-overhead-for-remote-service-calls.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1130) Deployment Descriptor should allow setting the number of concurrent listeners for a reply queue
[ https://issues.apache.org/jira/browse/UIMA-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12620271#action_12620271 ] Adam Lally commented on UIMA-1130: -- I think Eddie is probably right that increasing the number of listeners should eliminate my need to set a prefetch 0. A thread that's being used to execute prefetch isn't doing anything that an additional listener thread wouldn't also do, as far as I understand it. So I'm +1 to proceed with the plan as Eddie outlined it. Deployment Descriptor should allow setting the number of concurrent listeners for a reply queue --- Key: UIMA-1130 URL: https://issues.apache.org/jira/browse/UIMA-1130 Project: UIMA Issue Type: Improvement Components: Async Scaleout Affects Versions: 2.2.2 Reporter: Adam Lally The Spring XML allows setting a concurrentConsumers property for a reply queue (either an aggregate's collocated reply queue or a remote reply queue): property name=concurrentConsumers value=1/ The deployment descriptor should allow setting this property. In some deployments where remote delegates are scaled out many times, the bottleneck can become the aggregate deserializing CASes from the reply queue. If the aggregate is running on a multicore machine it helps to increase the number of threads that can process the reply queue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1130) Deployment Descriptor should allow setting the number of concurrent listeners for a reply queue
[ https://issues.apache.org/jira/browse/UIMA-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12618867#action_12618867 ] Adam Lally commented on UIMA-1130: -- If you require the reply queues to be remote, please also allow me to set a prefetch value for them. I usually use a prefetch of 0 on my aggregate AS services, for better load balancing, but in some tests I've run, I found that local reply queues are faster, presumably because when a thread is ready to deserialize a CAS, it doesn't have to sit idle while retrieving the xmi from the broker. I'd like to be able to set a higher prefetch value (at least 1) for the reply queue. Speaking of which, prefetch needs to be settable in the DDE. Deployment Descriptor should allow setting the number of concurrent listeners for a reply queue --- Key: UIMA-1130 URL: https://issues.apache.org/jira/browse/UIMA-1130 Project: UIMA Issue Type: Improvement Components: Async Scaleout Affects Versions: 2.2.2 Reporter: Adam Lally The Spring XML allows setting a concurrentConsumers property for a reply queue (either an aggregate's collocated reply queue or a remote reply queue): property name=concurrentConsumers value=1/ The deployment descriptor should allow setting this property. In some deployments where remote delegates are scaled out many times, the bottleneck can become the aggregate deserializing CASes from the reply queue. If the aggregate is running on a multicore machine it helps to increase the number of threads that can process the reply queue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1130) Deployment Descriptor should allow setting the number of concurrent listeners for a reply queue
Deployment Descriptor should allow setting the number of concurrent listeners for a reply queue --- Key: UIMA-1130 URL: https://issues.apache.org/jira/browse/UIMA-1130 Project: UIMA Issue Type: Improvement Components: Async Scaleout Affects Versions: 2.2.2 Reporter: Adam Lally The Spring XML allows setting a concurrentConsumers property for a reply queue (either an aggregate's collocated reply queue or a remote reply queue): property name=concurrentConsumers value=1/ The deployment descriptor should allow setting this property. In some deployments where remote delegates are scaled out many times, the bottleneck can become the aggregate deserializing CASes from the reply queue. If the aggregate is running on a multicore machine it helps to increase the number of threads that can process the reply queue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1111) Calling jcas.getType for a type that is not defined in the descriptor causes a lot of object allocation
Calling jcas.getType for a type that is not defined in the descriptor causes a
lot of object allocation
---
Key: UIMA-
URL: https://issues.apache.org/jira/browse/UIMA-
Project: UIMA
Issue Type: Bug
Components: Core Java Framework
Affects Versions: 2.2.2
Reporter: Adam Lally
This is related to UIMA-738. if you attempt to call jcas.getType() for a type
that's not defined in the type system, the JCas responds by going through the
type system and re-creating all of the _Type objects for all known types. For
large type systems, this causes some unnecessary work and creates lots of
temporary objects that need to be collected.
The situation used to be worse. Under UIMA-738 we fixed problems that caused
the JCas to become unstable after this operation. Now at least it doesn't
break anything, but there is this performance issue.
To check this, you can run the existing method in JCasTests:
public void testUndefinedType() throws Exception {
//create jcas with no type system
JCas jcas = CasCreationUtils.createCas(new TypeSystemDescription_impl(),
null, null).getJCas();
jcas.setDocumentText(This is a test.);
try {
//this should throw an exception
jcas.getType(Sentence.type);
fail();
} catch(CASRuntimeException e) {
}
//check that this does not leave JCAS in an inconsistent state
//(a check for bug UIMA-738)
Iterator iter = jcas.getAnnotationIndex().iterator();
assertTrue(iter.hasNext());
Annotation annot = (Annotation)iter.next();
assertEquals(This is a test., annot.getCoveredText());
}
The call to jcas.getType(Sentence.type) will cause all known _Type objects to
be instantiated (in this case, the builtins). This can be seen from stepping
into this method in the debugger, or from putting a breakpoint in the TOP_Type
constructor.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1080) [Patch] Wr ong usage of URL in XmiWriterCasConsumer
[ https://issues.apache.org/jira/browse/UIMA-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12608048#action_12608048 ] Adam Lally commented on UIMA-1080: -- This doesn't seem to handle spaces in the file path. For example if you run the document analyzer with this input dir: C:\Program Files\apache-uima\examples\data Then the output files are produced with the generic names doc0, doc1, etc., indicating that the filename wasn't extracted from the URI. As I recall, the URI class is much less lenient than the URL class when it comes to spaces. This might be considered a problem with the FileSystemCollectionReader, which populates the SourceDocumenInformation.uri field. Perhaps it should not be putting spaces in there. However, I am somewhat nervous about changing this to URL-encode the uri, since I think it is likely there's some user code out there that is relying on the current behavior. Also, whatever change is applied to XmiWriterCasConsumer probably should also be applied to XCasWriterCasConsumer. And there are also example versions of these classes in the uimaj-examples project. [Patch] Wrong usage of URL in XmiWriterCasConsumer -- Key: UIMA-1080 URL: https://issues.apache.org/jira/browse/UIMA-1080 Project: UIMA Issue Type: Improvement Components: InternalTools Affects Versions: 2.2.2 Reporter: Richard Eckart Priority: Minor Attachments: UIMA-1080.patch The XmiWriterCasConsumer wraps the value of SourceDocumentInformation.getUri() in an URL to extract the path. This only works if the value returned by getUri() is actually an URL starting with http, ftp or some other known protocol. It does not work if a framework user puts some self-defined URIs in there, such as annolab://default/myfile. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-911) CasMultiplier's hasNext() called twice without an intervening next()
[ https://issues.apache.org/jira/browse/UIMA-911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580361#action_12580361 ] Adam Lally commented on UIMA-911: - Users sometimes need to implement the Java iterator interface, in which case they need to make sure that their hasNext method doesn't advance the iterator - so I don't see that this is that different. I guess a difference in UIMA's case is that there's another level of indirection (the CasIterator) between the calling code and the CasMultiplier, so we could afford to have different contracts at the two layers. CasIterator's hasNext could be called any number of times, but the CasMultiplier's would be guaranteed to only get called once. I think that's what your fix is doing. So since end users never interact with the CasMultiplier interface directly, it's not a huge loss if it's contract doesn't follow the standard iterator paradigm. I guess I still have a preference for keeping the contract with the CasMultiplier analogous to the normal Iterator contract, since I think most people think that an interface with hasNext/next operates in this way. And who knows, maybe someone else has written some code that directly calls a CasMultiplier component outside of the UIMA framework, and they'd be tripped up by this. Unlikely, but possible. Does anyone else want to voice an opinion? CasMultiplier's hasNext() called twice without an intervening next() Key: UIMA-911 URL: https://issues.apache.org/jira/browse/UIMA-911 Project: UIMA Issue Type: Bug Components: Core Java Framework Reporter: Burn Lewis Priority: Minor Attachments: UIMA-911-fix.patch, UIMA-911.patch In org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl the hasNext method calls the AnalysisComponent's hasNext but then its next method calls the AnalysisComponent's hasNext again before calling next. Makes it difficult to split the processing between hasNext next. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-904) InvalidXMLException when running managed Deployment example for CPE
[ https://issues.apache.org/jira/browse/UIMA-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579534#action_12579534 ] Adam Lally commented on UIMA-904: - The CPE GUI never really supported the managed and non-managed deployment options. This isn't a problem with parsing the main CPE descriptor, which works fine. It's a problem in the CPE GUI code, which loops over all the CAS Processors and tries to populate the tabs in the GUI. (CpmFrame.java line 1783). What's the right thing to do here? Should it put up an empty tab in the GUI? Probably, the code in CpmFrame could be updated to check if deployment was set to local, and bypass the usual call to parseResourceSpecifier. InvalidXMLException when running managed Deployment example for CPE --- Key: UIMA-904 URL: https://issues.apache.org/jira/browse/UIMA-904 Project: UIMA Issue Type: Bug Components: Collection Processing Affects Versions: 2.2.1 Reporter: Michael Baessler Assignee: Adam Lally Fix For: 2.2.2 Error loading CPE Descriptor C:\Programme\apache-uima\examples\descriptors\collection_processing_engine\MeetingFinderCPE_Managed_Windows.xml org.apache.uima.util.InvalidXMLException: Invalid descriptor at file:/C:/Programme/apache-uima/examples/deploy/vinci/Deploy_MeetingDetectorTAE.xml. at org.apache.uima.util.impl.XMLParser_impl.parse(XMLParser_impl.java:193) at org.apache.uima.util.impl.XMLParser_impl.parseResourceSpecifier(XMLParser_impl.java:365) at org.apache.uima.util.impl.XMLParser_impl.parseResourceSpecifier(XMLParser_impl.java:346) at org.apache.uima.tools.cpm.CpmPanel.openCpeDescriptor(CpmPanel.java:1783) at org.apache.uima.tools.cpm.CpmPanel.actionPerformed(CpmPanel.java:847) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1849) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2169) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) at javax.swing.AbstractButton.doClick(AbstractButton.java:302) at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1051) at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1092) at java.awt.Component.processMouseEvent(Component.java:5517) at javax.swing.JComponent.processMouseEvent(JComponent.java:3135) at java.awt.Component.processEvent(Component.java:5282) at java.awt.Container.processEvent(Container.java:1966) at java.awt.Component.dispatchEventImpl(Component.java:3984) at java.awt.Container.dispatchEventImpl(Container.java:2024) at java.awt.Component.dispatchEvent(Component.java:3819) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3892) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822) at java.awt.Container.dispatchEventImpl(Container.java:2010) at java.awt.Window.dispatchEventImpl(Window.java:1791) at java.awt.Component.dispatchEvent(Component.java:3819) at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) Caused by: org.apache.uima.util.InvalidXMLException: The XML parser encounteredan unknown element type: deployment. at org.apache.uima.util.impl.XMLParser_impl.buildObject(XMLParser_impl.java:276) at org.apache.uima.util.impl.SaxDeserializer_impl.getObject(SaxDeserializer_impl.java:114) at org.apache.uima.util.impl.XMLParser_impl.parse(XMLParser_impl.java:184) ... 30 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (UIMA-904) InvalidXMLException when running managed Deployment example for CPE
[ https://issues.apache.org/jira/browse/UIMA-904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally reassigned UIMA-904: --- Assignee: Marshall Schor (was: Adam Lally) InvalidXMLException when running managed Deployment example for CPE --- Key: UIMA-904 URL: https://issues.apache.org/jira/browse/UIMA-904 Project: UIMA Issue Type: Bug Components: Collection Processing Affects Versions: 2.2.1 Reporter: Michael Baessler Assignee: Marshall Schor Fix For: 2.2.2 Error loading CPE Descriptor C:\Programme\apache-uima\examples\descriptors\collection_processing_engine\MeetingFinderCPE_Managed_Windows.xml org.apache.uima.util.InvalidXMLException: Invalid descriptor at file:/C:/Programme/apache-uima/examples/deploy/vinci/Deploy_MeetingDetectorTAE.xml. at org.apache.uima.util.impl.XMLParser_impl.parse(XMLParser_impl.java:193) at org.apache.uima.util.impl.XMLParser_impl.parseResourceSpecifier(XMLParser_impl.java:365) at org.apache.uima.util.impl.XMLParser_impl.parseResourceSpecifier(XMLParser_impl.java:346) at org.apache.uima.tools.cpm.CpmPanel.openCpeDescriptor(CpmPanel.java:1783) at org.apache.uima.tools.cpm.CpmPanel.actionPerformed(CpmPanel.java:847) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1849) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2169) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) at javax.swing.AbstractButton.doClick(AbstractButton.java:302) at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1051) at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1092) at java.awt.Component.processMouseEvent(Component.java:5517) at javax.swing.JComponent.processMouseEvent(JComponent.java:3135) at java.awt.Component.processEvent(Component.java:5282) at java.awt.Container.processEvent(Container.java:1966) at java.awt.Component.dispatchEventImpl(Component.java:3984) at java.awt.Container.dispatchEventImpl(Container.java:2024) at java.awt.Component.dispatchEvent(Component.java:3819) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3892) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822) at java.awt.Container.dispatchEventImpl(Container.java:2010) at java.awt.Window.dispatchEventImpl(Window.java:1791) at java.awt.Component.dispatchEvent(Component.java:3819) at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) Caused by: org.apache.uima.util.InvalidXMLException: The XML parser encounteredan unknown element type: deployment. at org.apache.uima.util.impl.XMLParser_impl.buildObject(XMLParser_impl.java:276) at org.apache.uima.util.impl.SaxDeserializer_impl.getObject(SaxDeserializer_impl.java:114) at org.apache.uima.util.impl.XMLParser_impl.parse(XMLParser_impl.java:184) ... 30 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (UIMA-894) CDE import by name broken on Linux
[ https://issues.apache.org/jira/browse/UIMA-894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally reopened UIMA-894: - I'm still having trouble with this. The import by name selector now shows up, but when I pick something and try to import, nothing happens. I found the following in the error log (amusing that it tells me to look in the error log for more information. :) org.apache.uima.taeconfigurator.InternalErrorCDE: invalid state - Please see Eclipse Error Log for more information. at org.apache.uima.taeconfigurator.editors.ui.AbstractSection.readImport(AbstractSection.java:1502) at org.apache.uima.taeconfigurator.editors.ui.AggregateSection.addDelegate(AggregateSection.java:561) at org.apache.uima.taeconfigurator.editors.ui.AggregateSection.produceKeyAddDelegate(AggregateSection.java:284) at org.apache.uima.taeconfigurator.editors.ui.AggregateSection.handleAdd(AggregateSection.java:268) at org.apache.uima.taeconfigurator.editors.ui.AggregateSection.handleEvent(AggregateSection.java:218) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1101) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3319) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2971) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2389) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2353) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2219) at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:466) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:461) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:169) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176) 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:585) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:508) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:447) at org.eclipse.equinox.launcher.Main.run(Main.java:1173) at org.eclipse.equinox.launcher.Main.main(Main.java:1148) CDE import by name broken on Linux -- Key: UIMA-894 URL: https://issues.apache.org/jira/browse/UIMA-894 Project: UIMA Issue Type: Bug Components: Eclipse plugins Reporter: Marshall Schor Assignee: Marshall Schor Fix For: 2.2.2 Import by name on Linux shows no candidates. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-826) Type System Merging does not work consistently when a type is declared twice with different supertypes
[ https://issues.apache.org/jira/browse/UIMA-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-826. --- verified fixed in 2.2.2 build 03 Type System Merging does not work consistently when a type is declared twice with different supertypes -- Key: UIMA-826 URL: https://issues.apache.org/jira/browse/UIMA-826 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.2.1 Reporter: Adam Lally Assignee: Adam Lally Fix For: 2.2.2 When type system merging is done, if the same type is declared twice with different supertypes, then the result depends on the order in which the types are declared. For example, given the type system descriptors: TS1.xml: typeSystemDescription xmlns=http://uima.apache.org/resourceSpecifier; types typeDescription nameSub/name descriptionExample type./description supertypeNameuima.tcas.Annotation/supertypeName /typeDescription /types /typeSystemDescription TS2.xml: typeSystemDescription xmlns=http://uima.apache.org/resourceSpecifier; types typeDescription nameSub/name descriptionExample type./description supertypeNameSuper/supertypeName /typeDescription typeDescription nameSuper/name descriptionExample type./description supertypeNameuima.tcas.Annotation/supertypeName /typeDescription /types /typeSystemDescription If you merge them in the order TS1.xml, TS2.xml it will fail with the error message: The Type Sub is declared twice, with incompatible supertypes Super and uima.tcas.Annotation. But if you merge them in the order TS2.xml, TS1.xml it will succeed! The intended behavior is that the merge should succeed and the resulting supertype should be Super (the lower of the two declared supertypes in the type hierarchy). It is only supposed to fail if the different declared supertypes are not in the same inheritance chain (neither inherits from the other). But that code is broken in the case where the two subtype declarations are processed before the supertype declarations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-219) Clean up XCASSerializer code to remove what's left of Sofa mapping support
[ https://issues.apache.org/jira/browse/UIMA-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-219. --- ok Clean up XCASSerializer code to remove what's left of Sofa mapping support -- Key: UIMA-219 URL: https://issues.apache.org/jira/browse/UIMA-219 Project: UIMA Issue Type: Task Components: Core Java Framework Reporter: Adam Lally Assignee: Eddie Epstein Priority: Trivial Clean up XCASSerializer code to remove Sofa mappings. This doesn't work correctly, and is never used anyway -- the service adapters have been changed to check for the use of sofa mapping and throw an exception. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-911) CasMultiplier's hasNext() called twice without an intervening next()
[ https://issues.apache.org/jira/browse/UIMA-911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579625#action_12579625 ] Adam Lally commented on UIMA-911: - I don't think this is a bug. This is meant to work the same as Java Iterators. If you call an iterator's hasNext() method twice, it gives you the same value and does not advance the iterator. CasMultiplier's hasNext() called twice without an intervening next() Key: UIMA-911 URL: https://issues.apache.org/jira/browse/UIMA-911 Project: UIMA Issue Type: Bug Components: Core Java Framework Reporter: Burn Lewis Priority: Minor Attachments: UIMA-911.patch In org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl the hasNext method calls the AnalysisComponent's hasNext but then its next method calls the AnalysisComponent's hasNext again before calling next. Makes it difficult to split the processing between hasNext next. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-879) Eclipse plugin jar files do not have the right names
Eclipse plugin jar files do not have the right names Key: UIMA-879 URL: https://issues.apache.org/jira/browse/UIMA-879 Project: UIMA Issue Type: Bug Components: Build, Packaging and Test Reporter: Adam Lally Assignee: Marshall Schor Priority: Critical Fix For: 2.2.2 In uimaj-2.2.2/01, the eclipse plugin jar files have names like uimaj-ep-runtime-2.2.2.incubating.jar instead of org.apache.uima.runtime_2.2.2.incubating -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (UIMA-826) Type System Merging does not work consistently when a type is declared twice with different supertypes
[ https://issues.apache.org/jira/browse/UIMA-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally reopened UIMA-826: - does not work right if the user's type name starts with uima. (discouraged, but unfortunately some users do this and it used to work, so it isn't good to break it). Type System Merging does not work consistently when a type is declared twice with different supertypes -- Key: UIMA-826 URL: https://issues.apache.org/jira/browse/UIMA-826 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.2.1 Reporter: Adam Lally Assignee: Adam Lally Fix For: 2.2.2 When type system merging is done, if the same type is declared twice with different supertypes, then the result depends on the order in which the types are declared. For example, given the type system descriptors: TS1.xml: typeSystemDescription xmlns=http://uima.apache.org/resourceSpecifier; types typeDescription nameSub/name descriptionExample type./description supertypeNameuima.tcas.Annotation/supertypeName /typeDescription /types /typeSystemDescription TS2.xml: typeSystemDescription xmlns=http://uima.apache.org/resourceSpecifier; types typeDescription nameSub/name descriptionExample type./description supertypeNameSuper/supertypeName /typeDescription typeDescription nameSuper/name descriptionExample type./description supertypeNameuima.tcas.Annotation/supertypeName /typeDescription /types /typeSystemDescription If you merge them in the order TS1.xml, TS2.xml it will fail with the error message: The Type Sub is declared twice, with incompatible supertypes Super and uima.tcas.Annotation. But if you merge them in the order TS2.xml, TS1.xml it will succeed! The intended behavior is that the merge should succeed and the resulting supertype should be Super (the lower of the two declared supertypes in the type hierarchy). It is only supposed to fail if the different declared supertypes are not in the same inheritance chain (neither inherits from the other). But that code is broken in the case where the two subtype declarations are processed before the supertype declarations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-826) Type System Merging does not work consistently when a type is declared twice with different supertypes
[ https://issues.apache.org/jira/browse/UIMA-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577530#action_12577530 ] Adam Lally commented on UIMA-826: - Fixed the problem with type names starting with uima., but there is now another issue. If I create a type system descriptor that imports the two descriptors above, and try to call CasCreationUtils.createCas(tsDesc, null, null) passing that descriptor, it fails with a message telling me that I can't redefine the supertype of a builtin type. I think the problem is that mergeTypeSystems is not called in the case where you have a single type system descriptor. But if that descriptor imports things with differing definitions, then a merge is really needed. I think a lot of these cases slipped by before, but the new check for redefined types exposed them. I think CasCreationUtils.createCas(TypeSystemDescription, TypePriorities, FsIndexDescription[]) needs to call mergeTypeSystems. Type System Merging does not work consistently when a type is declared twice with different supertypes -- Key: UIMA-826 URL: https://issues.apache.org/jira/browse/UIMA-826 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.2.1 Reporter: Adam Lally Assignee: Adam Lally Fix For: 2.2.2 When type system merging is done, if the same type is declared twice with different supertypes, then the result depends on the order in which the types are declared. For example, given the type system descriptors: TS1.xml: typeSystemDescription xmlns=http://uima.apache.org/resourceSpecifier; types typeDescription nameSub/name descriptionExample type./description supertypeNameuima.tcas.Annotation/supertypeName /typeDescription /types /typeSystemDescription TS2.xml: typeSystemDescription xmlns=http://uima.apache.org/resourceSpecifier; types typeDescription nameSub/name descriptionExample type./description supertypeNameSuper/supertypeName /typeDescription typeDescription nameSuper/name descriptionExample type./description supertypeNameuima.tcas.Annotation/supertypeName /typeDescription /types /typeSystemDescription If you merge them in the order TS1.xml, TS2.xml it will fail with the error message: The Type Sub is declared twice, with incompatible supertypes Super and uima.tcas.Annotation. But if you merge them in the order TS2.xml, TS1.xml it will succeed! The intended behavior is that the merge should succeed and the resulting supertype should be Super (the lower of the two declared supertypes in the type hierarchy). It is only supposed to fail if the different declared supertypes are not in the same inheritance chain (neither inherits from the other). But that code is broken in the case where the two subtype declarations are processed before the supertype declarations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (UIMA-826) Type System Merging does not work consistently when a type is declared twice with different supertypes
[ https://issues.apache.org/jira/browse/UIMA-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally resolved UIMA-826. - Resolution: Fixed fixed, will verify in the next build Type System Merging does not work consistently when a type is declared twice with different supertypes -- Key: UIMA-826 URL: https://issues.apache.org/jira/browse/UIMA-826 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.2.1 Reporter: Adam Lally Assignee: Adam Lally Fix For: 2.2.2 When type system merging is done, if the same type is declared twice with different supertypes, then the result depends on the order in which the types are declared. For example, given the type system descriptors: TS1.xml: typeSystemDescription xmlns=http://uima.apache.org/resourceSpecifier; types typeDescription nameSub/name descriptionExample type./description supertypeNameuima.tcas.Annotation/supertypeName /typeDescription /types /typeSystemDescription TS2.xml: typeSystemDescription xmlns=http://uima.apache.org/resourceSpecifier; types typeDescription nameSub/name descriptionExample type./description supertypeNameSuper/supertypeName /typeDescription typeDescription nameSuper/name descriptionExample type./description supertypeNameuima.tcas.Annotation/supertypeName /typeDescription /types /typeSystemDescription If you merge them in the order TS1.xml, TS2.xml it will fail with the error message: The Type Sub is declared twice, with incompatible supertypes Super and uima.tcas.Annotation. But if you merge them in the order TS2.xml, TS1.xml it will succeed! The intended behavior is that the merge should succeed and the resulting supertype should be Super (the lower of the two declared supertypes in the type hierarchy). It is only supposed to fail if the different declared supertypes are not in the same inheritance chain (neither inherits from the other). But that code is broken in the case where the two subtype declarations are processed before the supertype declarations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-826) Type System Merging does not work consistently when a type is declared twice with different supertypes
[ https://issues.apache.org/jira/browse/UIMA-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-826. --- Resolution: Fixed Fixed, and test case included. Type System Merging does not work consistently when a type is declared twice with different supertypes -- Key: UIMA-826 URL: https://issues.apache.org/jira/browse/UIMA-826 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.2.1 Reporter: Adam Lally Assignee: Adam Lally Fix For: 2.2.2 When type system merging is done, if the same type is declared twice with different supertypes, then the result depends on the order in which the types are declared. For example, given the type system descriptors: TS1.xml: typeSystemDescription xmlns=http://uima.apache.org/resourceSpecifier; types typeDescription nameSub/name descriptionExample type./description supertypeNameuima.tcas.Annotation/supertypeName /typeDescription /types /typeSystemDescription TS2.xml: typeSystemDescription xmlns=http://uima.apache.org/resourceSpecifier; types typeDescription nameSub/name descriptionExample type./description supertypeNameSuper/supertypeName /typeDescription typeDescription nameSuper/name descriptionExample type./description supertypeNameuima.tcas.Annotation/supertypeName /typeDescription /types /typeSystemDescription If you merge them in the order TS1.xml, TS2.xml it will fail with the error message: The Type Sub is declared twice, with incompatible supertypes Super and uima.tcas.Annotation. But if you merge them in the order TS2.xml, TS1.xml it will succeed! The intended behavior is that the merge should succeed and the resulting supertype should be Super (the lower of the two declared supertypes in the type hierarchy). It is only supposed to fail if the different declared supertypes are not in the same inheritance chain (neither inherits from the other). But that code is broken in the case where the two subtype declarations are processed before the supertype declarations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-826) Type System Merging does not work consistently when a type is declared twice with different supertypes
Type System Merging does not work consistently when a type is declared twice with different supertypes -- Key: UIMA-826 URL: https://issues.apache.org/jira/browse/UIMA-826 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.2.1 Reporter: Adam Lally Assignee: Adam Lally Fix For: 2.2.2 When type system merging is done, if the same type is declared twice with different supertypes, then the result depends on the order in which the types are declared. For example, given the type system descriptors: TS1.xml: typeSystemDescription xmlns=http://uima.apache.org/resourceSpecifier; types typeDescription nameSub/name descriptionExample type./description supertypeNameuima.tcas.Annotation/supertypeName /typeDescription /types /typeSystemDescription TS2.xml: typeSystemDescription xmlns=http://uima.apache.org/resourceSpecifier; types typeDescription nameSub/name descriptionExample type./description supertypeNameSuper/supertypeName /typeDescription typeDescription nameSuper/name descriptionExample type./description supertypeNameuima.tcas.Annotation/supertypeName /typeDescription /types /typeSystemDescription If you merge them in the order TS1.xml, TS2.xml it will fail with the error message: The Type Sub is declared twice, with incompatible supertypes Super and uima.tcas.Annotation. But if you merge them in the order TS2.xml, TS1.xml it will succeed! The intended behavior is that the merge should succeed and the resulting supertype should be Super (the lower of the two declared supertypes in the type hierarchy). It is only supposed to fail if the different declared supertypes are not in the same inheritance chain (neither inherits from the other). But that code is broken in the case where the two subtype declarations are processed before the supertype declarations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-821) Vinci Services have getMetaData timeout problems when there are a large number of clients
Vinci Services have getMetaData timeout problems when there are a large number of clients - Key: UIMA-821 URL: https://issues.apache.org/jira/browse/UIMA-821 Project: UIMA Issue Type: Bug Components: Transport Adapters - SOAP, Vinci Affects Versions: 2.2.1 Reporter: Adam Lally Assignee: Adam Lally Fix For: 2.2.2 When I have a large number of clients I am experiencing timeouts in the getMetadata call. There's currently no way to configure this timeout - in issue UIMA-33, we made the client descriptor's timeout element apply only to the process call, so getMetadata defaults to a 1 minute timeout. With a small number of clients this is OK, but the Vinci service has a default thread pool of size 20 (also not configurable through the UIMA descriptor), so if you have more clients than this then this pool may get filled up with process requests forcing a getMetadata call to wait much longer. Probably both of these settings should be configurable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-821) Vinci Services have getMetaData timeout problems when there are a large number of clients
[ https://issues.apache.org/jira/browse/UIMA-821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-821. --- Resolution: Fixed Added ability to configure getMetaData timeout in the service client descriptor and the thread pool min/max sizes in the deployment descriptor. Documentation included. Vinci Services have getMetaData timeout problems when there are a large number of clients - Key: UIMA-821 URL: https://issues.apache.org/jira/browse/UIMA-821 Project: UIMA Issue Type: Bug Components: Transport Adapters - SOAP, Vinci Affects Versions: 2.2.1 Reporter: Adam Lally Assignee: Adam Lally Fix For: 2.2.2 When I have a large number of clients I am experiencing timeouts in the getMetadata call. There's currently no way to configure this timeout - in issue UIMA-33, we made the client descriptor's timeout element apply only to the process call, so getMetadata defaults to a 1 minute timeout. With a small number of clients this is OK, but the Vinci service has a default thread pool of size 20 (also not configurable through the UIMA descriptor), so if you have more clients than this then this pool may get filled up with process requests forcing a getMetadata call to wait much longer. Probably both of these settings should be configurable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-780) CDE hangs when processing AEs with very high initialization time (adding the AE to the aggregate or saving the descriptor)
[ https://issues.apache.org/jira/browse/UIMA-780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-780. --- I verified with Jennifer that this is fixed. CDE hangs when processing AEs with very high initialization time (adding the AE to the aggregate or saving the descriptor) -- Key: UIMA-780 URL: https://issues.apache.org/jira/browse/UIMA-780 Project: UIMA Issue Type: Bug Components: Eclipse plugins Affects Versions: 2.2 Environment: Debian Linux Reporter: Jennifer Chu-Carroll Assignee: Adam Lally Priority: Minor Fix For: 2.2.2 The CDE repeatedly hung when trying to add an AE with high initialization time into the aggregate. When I finally successfully added it through editing the source xml, it hung again while trying to save the descriptor. It appears that the CDE is trying to initialize the annotator (CPU usage 200+%, using 5.7G of memory). I verified this by having the annotator in question load a toy dictionary and the problem disappeared. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (UIMA-780) CDE hangs when processing AEs with very high initialization time (adding the AE to the aggregate or saving the descriptor)
[ https://issues.apache.org/jira/browse/UIMA-780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally reassigned UIMA-780: --- Assignee: Adam Lally CDE hangs when processing AEs with very high initialization time (adding the AE to the aggregate or saving the descriptor) -- Key: UIMA-780 URL: https://issues.apache.org/jira/browse/UIMA-780 Project: UIMA Issue Type: Bug Components: Eclipse plugins Affects Versions: 2.2 Environment: Debian Linux Reporter: Jennifer Chu-Carroll Assignee: Adam Lally Priority: Minor The CDE repeatedly hung when trying to add an AE with high initialization time into the aggregate. When I finally successfully added it through editing the source xml, it hung again while trying to save the descriptor. It appears that the CDE is trying to initialize the annotator (CPU usage 200+%, using 5.7G of memory). I verified this by having the annotator in question load a toy dictionary and the problem disappeared. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (UIMA-780) CDE hangs when processing AEs with very high initialization time (adding the AE to the aggregate or saving the descriptor)
[ https://issues.apache.org/jira/browse/UIMA-780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally resolved UIMA-780. - Resolution: Fixed Fix Version/s: 2.2.2 Fixed. Still need to verify in the original environment where this was reported. CDE hangs when processing AEs with very high initialization time (adding the AE to the aggregate or saving the descriptor) -- Key: UIMA-780 URL: https://issues.apache.org/jira/browse/UIMA-780 Project: UIMA Issue Type: Bug Components: Eclipse plugins Affects Versions: 2.2 Environment: Debian Linux Reporter: Jennifer Chu-Carroll Assignee: Adam Lally Priority: Minor Fix For: 2.2.2 The CDE repeatedly hung when trying to add an AE with high initialization time into the aggregate. When I finally successfully added it through editing the source xml, it hung again while trying to save the descriptor. It appears that the CDE is trying to initialize the annotator (CPU usage 200+%, using 5.7G of memory). I verified this by having the annotator in question load a toy dictionary and the problem disappeared. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-792) CDE's Add Component Engine Selection dialog does not remember the setting for Add selected AEs to end of flow
CDE's Add Component Engine Selection dialog does not remember the setting for Add selected AEs to end of flow - Key: UIMA-792 URL: https://issues.apache.org/jira/browse/UIMA-792 Project: UIMA Issue Type: Improvement Components: Eclipse plugins Affects Versions: 2.2.1 Reporter: Adam Lally Priority: Trivial When using a custom flow controller, I never want AEs that I add to my aggregate to be added to the aggregate's fixedFlow. To do that I currently have to remember to uncheck the box on the Component Engine Selection dialog every time I add a component to my aggregate. It does not remember my setting from last time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-738) Calling jcas.getType for a type that is not defined in the descriptor leaves the JCAS in an inconsitent state
Calling jcas.getType for a type that is not defined in the descriptor leaves
the JCAS in an inconsitent state
-
Key: UIMA-738
URL: https://issues.apache.org/jira/browse/UIMA-738
Project: UIMA
Issue Type: Bug
Components: Core Java Framework
Affects Versions: 2.2.1
Reporter: Adam Lally
Assignee: Adam Lally
Fix For: 2.3
The following code illustrates the problem:
public void testUndefinedType() throws Exception {
//create jcas with no type system
JCas jcas = CasCreationUtils.createCas(new TypeSystemDescription_impl(),
null, null).getJCas();
jcas.setDocumentText(This is a test.);
try {
//this should throw an exception
jcas.getType(Sentence.type);
fail();
} catch(CASRuntimeException e) {
}
//check that this does not leave JCAS in an inconsistent state
Iterator iter = jcas.getAnnotationIndex().iterator();
assertTrue(iter.hasNext());
Annotation annot = (Annotation)iter.next();
}
Running this gives a ClassCastException trying to cast the result of
iter.next() to an Annotation
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (UIMA-738) Calling jcas.getType for a type that is not defined in the descriptor leaves the JCAS in an inconsitent state
[
https://issues.apache.org/jira/browse/UIMA-738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Lally resolved UIMA-738.
-
Resolution: Fixed
Assignee: Marshall Schor (was: Adam Lally)
Fixed. Marshall, please review.
Calling jcas.getType for a type that is not defined in the descriptor leaves
the JCAS in an inconsitent state
-
Key: UIMA-738
URL: https://issues.apache.org/jira/browse/UIMA-738
Project: UIMA
Issue Type: Bug
Components: Core Java Framework
Affects Versions: 2.2.1
Reporter: Adam Lally
Assignee: Marshall Schor
Fix For: 2.3
The following code illustrates the problem:
public void testUndefinedType() throws Exception {
//create jcas with no type system
JCas jcas = CasCreationUtils.createCas(new TypeSystemDescription_impl(),
null, null).getJCas();
jcas.setDocumentText(This is a test.);
try {
//this should throw an exception
jcas.getType(Sentence.type);
fail();
} catch(CASRuntimeException e) {
}
//check that this does not leave JCAS in an inconsistent state
Iterator iter = jcas.getAnnotationIndex().iterator();
assertTrue(iter.hasNext());
Annotation annot = (Annotation)iter.next();
}
Running this gives a ClassCastException trying to cast the result of
iter.next() to an Annotation
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-729) CasCopier doesn't work with Annotations produced with LowLevelCAS API, which don't have their sofa feature set
CasCopier doesn't work with Annotations produced with LowLevelCAS API, which don't have their sofa feature set -- Key: UIMA-729 URL: https://issues.apache.org/jira/browse/UIMA-729 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.2.1 Reporter: Adam Lally Assignee: Adam Lally Fix For: 2.3 The CasCopier expects that every Annotation's sofa feature is set. Unfortunately this is not the case for annotations produced using the LowLevelCAS API, which results in exceptions trying to copy those annotations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-729) CasCopier doesn't work with Annotations produced with LowLevelCAS API, which don't have their sofa feature set
[ https://issues.apache.org/jira/browse/UIMA-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-729. --- Resolution: Fixed CasCopier doesn't work with Annotations produced with LowLevelCAS API, which don't have their sofa feature set -- Key: UIMA-729 URL: https://issues.apache.org/jira/browse/UIMA-729 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.2.1 Reporter: Adam Lally Assignee: Adam Lally Fix For: 2.3 The CasCopier expects that every Annotation's sofa feature is set. Unfortunately this is not the case for annotations produced using the LowLevelCAS API, which results in exceptions trying to copy those annotations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-522) XMI Serialization fails for parameterized arrays
[ https://issues.apache.org/jira/browse/UIMA-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-522. --- fixed XMI Serialization fails for parameterized arrays Key: UIMA-522 URL: https://issues.apache.org/jira/browse/UIMA-522 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.1 Reporter: Adam Lally Assignee: Adam Lally Fix For: 2.2 When a parameterized array (an array with an elementType) is serialized to XMI, the elements of the array are not correctly added to the queue of FSs to be serialized. That means that if these FSs are not otherwise indexed or referenceable, they will be omitted from the output. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-534) The equals() method in MetaDataObject_impl doesn't compare elements in a Map properly.
[
https://issues.apache.org/jira/browse/UIMA-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Lally closed UIMA-534.
---
sanity check complete. Marshall passes. :)
The equals() method in MetaDataObject_impl doesn't compare elements in a Map
properly.
--
Key: UIMA-534
URL: https://issues.apache.org/jira/browse/UIMA-534
Project: UIMA
Issue Type: Bug
Components: Core Java Framework
Affects Versions: 2.1, 2.2
Reporter: Danai Wiriyayanyongsuk
Assignee: Adam Lally
Priority: Minor
Fix For: 2.2.1
In the class org.apache.uima.resource.metadata.impl.MetaDataObject_impl, the
equals() method returns immediately with the comparison result of the first
Map elements, leaving the rest of the Map's element uncompared.
Here is the code snippet:
while (it.hasNext()) {
Map.Entry entry = (Map.Entry) it.next();
Object subval1 = ((Map) val1).get(entry.getKey());
Object subval2 = ((Map) val2).get(entry.getKey());
if (subval1 == null) {
if (subval2 != null)
return false;
} else if (subval1 instanceof Object[]) {
if (!(subval2 instanceof Object[]))
return false;
if (!Arrays.equals((Object[]) subval1, (Object[]) subval2))
return false;
line:443 } else
line:444 return subval1.equals(subval2);
}
The problem with the code is that the statement line 444 will return the
result immediately, causing the while loop to be quit without comparing the
rest of elements in the Map.
To fix this, one could replace line 443 and 444 with the following:
} else if (!(subval1.equals(subval2)) {
return false;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-638) CVD should allow viewing FSArrays longer than 20 elements
CVD should allow viewing FSArrays longer than 20 elements - Key: UIMA-638 URL: https://issues.apache.org/jira/browse/UIMA-638 Project: UIMA Issue Type: Improvement Components: Tools Affects Versions: 2.2 Reporter: Adam Lally In the CVD's FS display (lower left panel), if you expand an FSArray it will only show you the first 20 elements. There should be a way to see all of the elements, perhaps with the same powers-of-10 display that the index view provides. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (UIMA-583) update documentation for adding PEARs to aggregate AEs
[ https://issues.apache.org/jira/browse/UIMA-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally resolved UIMA-583. - Resolution: Fixed Assignee: Michael Baessler I updated the JavaDocs for UimaContext.getSession() to say that session support is not implemented in any of the service wrappers that ship with UIMA. I think that's sufficient documentation for this. update documentation for adding PEARs to aggregate AEs -- Key: UIMA-583 URL: https://issues.apache.org/jira/browse/UIMA-583 Project: UIMA Issue Type: Bug Components: Documentation Affects Versions: 2.2 Reporter: Michael Baessler Assignee: Michael Baessler Fix For: 2.2.1 update the documentation or fix the impl: that if a PEAR file (pear descriptor) is added to an aggregate AE the configuration parameters of the PEAR file cannot be overridden by the aggregate AE. update the documentation or fix the impl: the mechanism for sharing resources among annotators doesn't work with PEARs, because it depends on the shared Resource Manager, and the current PEAR-inside-an-aggregate creates a new, unique resource manager for the PEAR. update the documentation or fix the impl: the (undocumented) Session manager support doesn't work with the current implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (UIMA-598) Memory leak from CAS pool
[ https://issues.apache.org/jira/browse/UIMA-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally reassigned UIMA-598: --- Assignee: Adam Lally Memory leak from CAS pool - Key: UIMA-598 URL: https://issues.apache.org/jira/browse/UIMA-598 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.2 Reporter: Eddie Epstein Assignee: Adam Lally Fix For: 2.3 CasManager_impl never unregisters with the JMX MBean server, which prevents the CAS pool from being GC. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (UIMA-598) Memory leak from CAS pool
[ https://issues.apache.org/jira/browse/UIMA-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally resolved UIMA-598. - Resolution: Fixed Assignee: Eddie Epstein (was: Adam Lally) I believe I've fixed this leak. Eddie, can you verify? Memory leak from CAS pool - Key: UIMA-598 URL: https://issues.apache.org/jira/browse/UIMA-598 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.2 Reporter: Eddie Epstein Assignee: Eddie Epstein Fix For: 2.3 CasManager_impl never unregisters with the JMX MBean server, which prevents the CAS pool from being GC. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-629) Default file names produced by XmiCasWriter don't have .xmi extension and can't be read by XmiCollectionReader
Default file names produced by XmiCasWriter don't have .xmi extension and can't be read by XmiCollectionReader -- Key: UIMA-629 URL: https://issues.apache.org/jira/browse/UIMA-629 Project: UIMA Issue Type: Bug Components: Examples, Tools Affects Versions: 2.2 Reporter: Adam Lally Priority: Minor If the original source file name is not present in the CAS, the XmiCasWriter names the output file doc0,doc1, etc,, with no .xmi extension. The XmiCollectionReader will only read files with .xmi extensions. This is quite annoying if you're trying to break up a pipeline into two parts, writing and reading XMI files in the middle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-607) Running PEAR class path switching code broken in multi-threading case (CPM)
[ https://issues.apache.org/jira/browse/UIMA-607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538794 ] Adam Lally commented on UIMA-607: - For multiple instances of the same AE, which share a classpath and datapath, I don't see an issue. We share ResourceManager instances among annotators all the time, so I don't see why there would be a problem here. It's not obvious to me, however, how you would actually accomplish this sharing, since the ResourceManager instances is created inside the PearAnalysisEngineWrapper, which is unaware of whether there might be other instances. Running PEAR class path switching code broken in multi-threading case (CPM) --- Key: UIMA-607 URL: https://issues.apache.org/jira/browse/UIMA-607 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.2 Reporter: Marshall Schor Assignee: Marshall Schor The new facility in 2.2 to run a Pear, switching class paths, has threading issues when run from a CPM in multiple threads. Needs a code review and fixes for case where CAS Pools are sharing one type system with all the CASes in the pool. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (UIMA-586) Bug when merging CASes using XmiDeserialization
[ https://issues.apache.org/jira/browse/UIMA-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally resolved UIMA-586. - Resolution: Fixed Bug when merging CASes using XmiDeserialization --- Key: UIMA-586 URL: https://issues.apache.org/jira/browse/UIMA-586 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.2 Reporter: Burn Lewis Assignee: Adam Lally Attachments: UIMA-586.patch After merging have duplicate Xmi Ids in map which causes FSs to be lost on later serializations. Have modified the Xmi Deserialization test case to expose this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-578) XmiCasDeserializer merge functionality doesn't support Sofas properly
XmiCasDeserializer merge functionality doesn't support Sofas properly --- Key: UIMA-578 URL: https://issues.apache.org/jira/browse/UIMA-578 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.2 Reporter: Adam Lally Assignee: Adam Lally Priority: Minor Fix For: 2.3 Eddie found a bug in the XmiCasDeserializerTest unit test that masked this actual bug in the deserializer. When merging multiple XMI documents into a single CAS, Sofas aren't properly deserialized. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-578) XmiCasDeserializer merge functionality doesn't support Sofas properly
[ https://issues.apache.org/jira/browse/UIMA-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-578. --- Resolution: Fixed XmiCasDeserializer merge functionality doesn't support Sofas properly --- Key: UIMA-578 URL: https://issues.apache.org/jira/browse/UIMA-578 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.2 Reporter: Adam Lally Assignee: Adam Lally Priority: Minor Fix For: 2.3 Eddie found a bug in the XmiCasDeserializerTest unit test that masked this actual bug in the deserializer. When merging multiple XMI documents into a single CAS, Sofas aren't properly deserialized. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-549) Extra jar listed in runtime plugin manifest
Extra jar listed in runtime plugin manifest --- Key: UIMA-549 URL: https://issues.apache.org/jira/browse/UIMA-549 Project: UIMA Issue Type: Bug Components: Eclipse plugins Affects Versions: 2.2 Reporter: Adam Lally Assignee: Adam Lally Priority: Minor Fix For: 2.3 Part of UIMA-400 that was not fixed: lib/uima-jcas-builtin-types.jar is listed in manifest, but not present in plugin. It is still present in UIMA 2.2 release, though it does not cause any problems. The only possible problem that could arise is importing UIMA runtime plugin as an Eclipse project, then Eclipse may complain about missing jar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-547) XmiCasDeserializer fails to deserialize arrays if JCAS has been initialized
XmiCasDeserializer fails to deserialize arrays if JCAS has been initialized --- Key: UIMA-547 URL: https://issues.apache.org/jira/browse/UIMA-547 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.2 Reporter: Adam Lally Assignee: Adam Lally Fix For: 2.3 If the JCAS has been initialized, subsequently attempting to deserialize an XMI CAS containing an array will fail with an error message such as: java.lang.ClassCastException: org.apache.uima.jcas.cas.StringArray cannot be cast to org.apache.uima.cas.impl.FeatureStructureImplC The XmiCasDeserializer is incorrectly trying to typecast to FeatureStructureImplC, which is the implementation class used only in non-JCAS scenarios. It is surprising we did not see this before. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-547) XmiCasDeserializer fails to deserialize arrays if JCAS has been initialized
[ https://issues.apache.org/jira/browse/UIMA-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522568 ] Adam Lally commented on UIMA-547: - Also looks like it could affect XCAS deserialization for certain array types (boolean,short,long,double). XmiCasDeserializer fails to deserialize arrays if JCAS has been initialized --- Key: UIMA-547 URL: https://issues.apache.org/jira/browse/UIMA-547 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.2 Reporter: Adam Lally Assignee: Adam Lally Fix For: 2.3 If the JCAS has been initialized, subsequently attempting to deserialize an XMI CAS containing an array will fail with an error message such as: java.lang.ClassCastException: org.apache.uima.jcas.cas.StringArray cannot be cast to org.apache.uima.cas.impl.FeatureStructureImplC The XmiCasDeserializer is incorrectly trying to typecast to FeatureStructureImplC, which is the implementation class used only in non-JCAS scenarios. It is surprising we did not see this before. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-547) XmiCasDeserializer fails to deserialize arrays if JCAS has been initialized
[ https://issues.apache.org/jira/browse/UIMA-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-547. --- Resolution: Fixed XmiCasDeserializer fails to deserialize arrays if JCAS has been initialized --- Key: UIMA-547 URL: https://issues.apache.org/jira/browse/UIMA-547 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.2 Reporter: Adam Lally Assignee: Adam Lally Fix For: 2.3 If the JCAS has been initialized, subsequently attempting to deserialize an XMI CAS containing an array will fail with an error message such as: java.lang.ClassCastException: org.apache.uima.jcas.cas.StringArray cannot be cast to org.apache.uima.cas.impl.FeatureStructureImplC The XmiCasDeserializer is incorrectly trying to typecast to FeatureStructureImplC, which is the implementation class used only in non-JCAS scenarios. It is surprising we did not see this before. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (UIMA-521) Add LICENSE, DISCLAIMER, and NOTICES files to source jars produced by Maven
[ https://issues.apache.org/jira/browse/UIMA-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally reopened UIMA-521: - Assignee: Adam Lally (was: Marshall Schor) this fix broke mvn eclipse:eclipse Add LICENSE, DISCLAIMER, and NOTICES files to source jars produced by Maven --- Key: UIMA-521 URL: https://issues.apache.org/jira/browse/UIMA-521 Project: UIMA Issue Type: Task Components: Build, Packaging and Test Reporter: Adam Lally Assignee: Adam Lally Fix For: 2.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (UIMA-521) Add LICENSE, DISCLAIMER, and NOTICES files to source jars produced by Maven
[ https://issues.apache.org/jira/browse/UIMA-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally resolved UIMA-521. - Resolution: Fixed Assignee: Michael Baessler (was: Adam Lally) This should be fixed now. I had to go back to using ant to get this to work. The Maven eclipse plugin doesn't support resource directories that are external to the component (it tries to add them as source folders in Eclipse, which does not work). Assigning to Michael to check if this fixes his Eclipse workspace. (I'm not sure but you might need to either do a fresh extract or else manually delete those extra files that mvn eclipse:eclipse created, since they will cause problems if you don't get rid of them.) Add LICENSE, DISCLAIMER, and NOTICES files to source jars produced by Maven --- Key: UIMA-521 URL: https://issues.apache.org/jira/browse/UIMA-521 Project: UIMA Issue Type: Task Components: Build, Packaging and Test Reporter: Adam Lally Assignee: Michael Baessler Fix For: 2.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (UIMA-522) XMI Serialization fails for parameterized arrays
[ https://issues.apache.org/jira/browse/UIMA-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally reopened UIMA-522: - There is still a problem when multipleReferencesAllows=true XMI Serialization fails for parameterized arrays Key: UIMA-522 URL: https://issues.apache.org/jira/browse/UIMA-522 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.1 Reporter: Adam Lally Assignee: Adam Lally Fix For: 2.2 When a parameterized array (an array with an elementType) is serialized to XMI, the elements of the array are not correctly added to the queue of FSs to be serialized. That means that if these FSs are not otherwise indexed or referenceable, they will be omitted from the output. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (UIMA-522) XMI Serialization fails for parameterized arrays
[ https://issues.apache.org/jira/browse/UIMA-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally resolved UIMA-522. - Resolution: Fixed turns out there was not an actual problem. The unit test was in error. XMI Serialization fails for parameterized arrays Key: UIMA-522 URL: https://issues.apache.org/jira/browse/UIMA-522 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.1 Reporter: Adam Lally Assignee: Adam Lally Fix For: 2.2 When a parameterized array (an array with an elementType) is serialized to XMI, the elements of the array are not correctly added to the queue of FSs to be serialized. That means that if these FSs are not otherwise indexed or referenceable, they will be omitted from the output. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (UIMA-522) XMI Serialization fails for parameterized arrays
[ https://issues.apache.org/jira/browse/UIMA-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally resolved UIMA-522. - Resolution: Fixed Fixed. I will close once I re-test on the next release candidate. XMI Serialization fails for parameterized arrays Key: UIMA-522 URL: https://issues.apache.org/jira/browse/UIMA-522 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.1 Reporter: Adam Lally Assignee: Adam Lally Fix For: 2.2 When a parameterized array (an array with an elementType) is serialized to XMI, the elements of the array are not correctly added to the queue of FSs to be serialized. That means that if these FSs are not otherwise indexed or referenceable, they will be omitted from the output. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-524) Prepare for distribution of UIMA artifacts in Maven repository
Prepare for distribution of UIMA artifacts in Maven repository -- Key: UIMA-524 URL: https://issues.apache.org/jira/browse/UIMA-524 Project: UIMA Issue Type: Task Components: Build, Packaging and Test Reporter: Adam Lally Assignee: Adam Lally Fix For: 2.2 Add required license and scm sections to POM files. Update extractAndBuild script to build the Maven bundles necessary for upload (including source jars) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-524) Prepare for distribution of UIMA artifacts in Maven repository
[ https://issues.apache.org/jira/browse/UIMA-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-524. --- Resolution: Fixed fixed Prepare for distribution of UIMA artifacts in Maven repository -- Key: UIMA-524 URL: https://issues.apache.org/jira/browse/UIMA-524 Project: UIMA Issue Type: Task Components: Build, Packaging and Test Reporter: Adam Lally Assignee: Adam Lally Fix For: 2.2 Add required license and scm sections to POM files. Update extractAndBuild script to build the Maven bundles necessary for upload (including source jars) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-521) Add LICENSE, DISCLAIMER, and NOTICES files to source jars produced by Maven
Add LICENSE, DISCLAIMER, and NOTICES files to source jars produced by Maven --- Key: UIMA-521 URL: https://issues.apache.org/jira/browse/UIMA-521 Project: UIMA Issue Type: Task Components: Build, Packaging and Test Reporter: Adam Lally Assignee: Adam Lally Fix For: 2.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-522) XMI Serialization fails for parameterized arrays
XMI Serialization fails for parameterized arrays Key: UIMA-522 URL: https://issues.apache.org/jira/browse/UIMA-522 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.1 Reporter: Adam Lally Assignee: Adam Lally Fix For: 2.2 When a parameterized array (an array with an elementType) is serialized to XMI, the elements of the array are not correctly added to the queue of FSs to be serialized. That means that if these FSs are not otherwise indexed or referenceable, they will be omitted from the output. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (UIMA-476) FSArray causes error in SOAP service
[ https://issues.apache.org/jira/browse/UIMA-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally reopened UIMA-476: - Assignee: Adam Lally (was: Thilo Goetz) The multipleReferencesAllowed flag on each Feature is being lost during complete Serialization. FSArray causes error in SOAP service Key: UIMA-476 URL: https://issues.apache.org/jira/browse/UIMA-476 Project: UIMA Issue Type: Bug Components: Transport Adapters - SOAP, Vinci Affects Versions: 2.1 Environment: UIMA 2.1 and previous versions Reporter: Yoshinobu KANO Assignee: Adam Lally Fix For: 2.2 When we run a SOAP service with any type system which uses FSArray, AnalysisEngineProcessException occurs, though the same component can be run as a local service. It occurs in the type system checking, independently of the component implementations. The error says: Caused by: org.apache.uima.UIMARuntimeException: The JCas cannot be initialized. The following errors occurred: The JCAS range type uima.cas.FSArray for feature OurFeatureName of type OurTypeName does not match the CAS range OurFeatureTypeName[] for the feature. # replaced our specific feature/type names. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (UIMA-499) Add source jars to binary distribution
[ https://issues.apache.org/jira/browse/UIMA-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally reopened UIMA-499: - Add source jars to binary distribution -- Key: UIMA-499 URL: https://issues.apache.org/jira/browse/UIMA-499 Project: UIMA Issue Type: Improvement Components: Build, Packaging and Test Reporter: Thilo Goetz Assignee: Adam Lally Priority: Minor Fix For: 2.2 Adding source jars to our distribution will make programming against our APIs a lot more convenient. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-514) remove souce jars from binary distribution
[ https://issues.apache.org/jira/browse/UIMA-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-514. --- looks right to me remove souce jars from binary distribution -- Key: UIMA-514 URL: https://issues.apache.org/jira/browse/UIMA-514 Project: UIMA Issue Type: Bug Components: Build, Packaging and Test Reporter: Michael Baessler Assignee: Adam Lally Fix For: 2.2 We discussed the topic: Don't some companies have issues with their people downloading source code in the binary release? Does this create a barrier for UIMA to be used? and we decided to remove the source jars from the binary distribution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-499) Make it easier for users to view UIMA JavaDocs from Eclipse
[ https://issues.apache.org/jira/browse/UIMA-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally updated UIMA-499: Fix Version/s: (was: 2.2) Summary: Make it easier for users to view UIMA JavaDocs from Eclipse (was: Add source jars to binary distribution) We decided against including source in our binary distribution. But it's still a valid concern to make it easier for Eclipse users to view the UIMA API JavaDocs. One idea is to make a New UIMA Project Wizard that could automatically set up a new project where the classpath contains all the UIMA jar files and the javadocs are attached. Make it easier for users to view UIMA JavaDocs from Eclipse --- Key: UIMA-499 URL: https://issues.apache.org/jira/browse/UIMA-499 Project: UIMA Issue Type: Improvement Components: Build, Packaging and Test Reporter: Thilo Goetz Assignee: Adam Lally Priority: Minor Adding source jars to our distribution will make programming against our APIs a lot more convenient. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-442) FileUtilsTest fail on Linux
[ https://issues.apache.org/jira/browse/UIMA-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-442. --- FileUtilsTest fail on Linux --- Key: UIMA-442 URL: https://issues.apache.org/jira/browse/UIMA-442 Project: UIMA Issue Type: Bug Components: Build, Packaging and Test Affects Versions: 2.1 Environment: Ubuntu Linux 7.04- SUN Java 6 (1.6.0-b105), Eclipse 3.3RC3, Maven 2.0.6 Reporter: Roberto Franchini Assignee: Adam Lally Fix For: 2.2 The FileUtilsTest fails on linux while using windows path: base = new File(c:/foo/bar/baz/dir/); target = new File(c:/foo/d1/d2/d3/blah.xml); assertEquals(../../../d1/d2/d3/blah.xml, FileUtils.findRelativePath(target, base)); Eclipse JUnit trace: junit.framework.ComparisonFailure: expected:./../d1/d2/d3/... but was:...c:\foo\d1\d2\d3\... at junit.framework.Assert.assertEquals(Assert.java:81) at junit.framework.Assert.assertEquals(Assert.java:87) at org.apache.uima.util.FileUtilsTest.testFindRelativePath(FileUtilsTest.java:41) [snip] Maven fails too: ... Running org.apache.uima.util.FileUtilsTest Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec FAILURE! ... Results : Failed tests: testFindRelativePath(org.apache.uima.util.FileUtilsTest) Tests run: 363, Failures: 1, Errors: 0, Skipped: 0 ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-496) PEAR API does not delete the PEAR ID subdirectory before the new content is installed
[ https://issues.apache.org/jira/browse/UIMA-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-496. --- PEAR API does not delete the PEAR ID subdirectory before the new content is installed - Key: UIMA-496 URL: https://issues.apache.org/jira/browse/UIMA-496 Project: UIMA Issue Type: Bug Components: Core Java Framework Reporter: Michael Baessler Assignee: Adam Lally Fix For: 2.2 When installing a PEAR file, currently the InstallationController API overrides all available data in the target installation directory. The directory content isn't removed before. So it can happen that old class files or descriptor files that are never valid are still in the installation directory since they will not be removed when the new stuff is installed. Existing files with the same name will be overridden. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-398) test case intermittently fails running Java 6 - with a hang: uimaj-core, org.apache.uima.analysis_engine.impl.MultiprocessingAnalysisEngine_implTest
[
https://issues.apache.org/jira/browse/UIMA-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Lally closed UIMA-398.
---
test case intermittently fails running Java 6 - with a hang: uimaj-core,
org.apache.uima.analysis_engine.impl.MultiprocessingAnalysisEngine_implTest
Key: UIMA-398
URL: https://issues.apache.org/jira/browse/UIMA-398
Project: UIMA
Issue Type: Bug
Components: Core Java Framework
Affects Versions: 2.1
Environment: Sun Java 6_01
Reporter: Marshall Schor
Attachments: screenshot-1.jpg
The failure is intermittent. It fails the first time running (for me) from a
reboot, but runs after that. The failure occurs in the test where it does a
threads[i].join(); and happens when i = 0. I found this out by changing the
join() to join(1), and then inserting:
if (threads[i].isAlive()) {
System.err.println(timeout waiting for thread to complete + i);
fail(timeout waiting for thread to complete + i);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-339) Support MBean Name Prefix in the additional parameters map passed to produceAE
[ https://issues.apache.org/jira/browse/UIMA-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-339. --- Support MBean Name Prefix in the additional parameters map passed to produceAE -- Key: UIMA-339 URL: https://issues.apache.org/jira/browse/UIMA-339 Project: UIMA Issue Type: Improvement Components: Core Java Framework Reporter: Adam Lally Assignee: Adam Lally Fix For: 2.2 This is desired for embedding a UIMA AE in an application that uses JMX. The application should be able to specify a name that will be prefixed to all of the MBean names that the AE generates. That way the application can control how the UIMA MBeans are organized relative to the application's own MBeans. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-325) Enhance XMI Serializer to support merging multiple XMI documents into a single CAS
[ https://issues.apache.org/jira/browse/UIMA-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-325. --- Enhance XMI Serializer to support merging multiple XMI documents into a single CAS -- Key: UIMA-325 URL: https://issues.apache.org/jira/browse/UIMA-325 Project: UIMA Issue Type: New Feature Components: Core Java Framework Reporter: Adam Lally Assignee: Adam Lally Fix For: 2.2 The new feature would support the following scenario: 1) A CAS is serialized to XMI. 2) Copies of the XMI documents are sent to multiple remote services 3) Each remote service appends to the CAS (does not delete or modify existing stuff) and responds with a new serialized XMI CAS) 4) The multiple XMI responses are all merged back into a single CAS instance This would permit multiple remote services that don't depend on each other to run in parallel, assuming they only append to the CAS (which is common). Of course there's other work on the runtime needed to actually do the parallel invocations, but XMI serializer support is a prerequisite. The basic XMI deserializer changes aren't too complicated. First, when the CAS is originally serialized in step 1, we make available to the caller the maximum xmi:id value in that CAS (this is mostly already done, we just need to add a public accessor for this value). Next, we allow passing this value to the deserializer as an optional argument that essentially says deserialize only XMI elements whose xmi:id is greater than the specified value. Discussion here: http://www.mail-archive.com/uima-dev@incubator.apache.org/msg02338.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
