CAS object change notifications
Hi, it would be nice to have a facility to listen to changes made to a CAS object. In a SWT/RCP application its likely that multiple views display concurrently some aspects of the CAS object, if now one view makes a change to the CAS object all other views must be synchronized. An example: The editor adds a new annotation to the CAS, now the outline view must display the annotation too. What do you think about introducing change notification support ? Jörn
Re: CAS object change notifications
Jörn Kottmann wrote: Hi, it would be nice to have a facility to listen to changes made to a CAS object. In a SWT/RCP application its likely that multiple views display concurrently some aspects of the CAS object, if now one view makes a change to the CAS object all other views must be synchronized. An example: The editor adds a new annotation to the CAS, now the outline view must display the annotation too. What do you think about introducing change notification support ? Sounds interesting - especially if it could be done in such a way as to not impact performance if it wasn't being "used". -Marshall
[jira] Created: (UIMA-142) JCas version of getLocalFSData() returning wrong type
JCas version of getLocalFSData() returning wrong type - Key: UIMA-142 URL: http://issues.apache.org/jira/browse/UIMA-142 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.1 Reporter: Marshall Schor Assigned To: Marshall Schor Fix For: 2.1 The Sofa method getLocalFSData() returns a CAS Array of primitive CAS types like integers, bytes, etc. But the return value for this method in the JCas is FSArray - which is an array of Feature Structures. Change this to return TOP - which is the most specific common ancestor of the JCas cover classes for primitive arrays. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (UIMA-142) JCas version of getLocalFSData() returning wrong type
[ http://issues.apache.org/jira/browse/UIMA-142?page=comments#action_12460888 ] Marshall Schor commented on UIMA-142: - Changed to return FeatureStructure. This is a supertype of TOP. It allows better interoperability in mixed JCas / non-JCas environments (which is not a typical use case, but there's no advantage I see of returning TOP - the result has to be cast in any case.) > JCas version of getLocalFSData() returning wrong type > - > > Key: UIMA-142 > URL: http://issues.apache.org/jira/browse/UIMA-142 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.1 >Reporter: Marshall Schor > Assigned To: Marshall Schor > Fix For: 2.1 > > > The Sofa method getLocalFSData() returns a CAS Array of primitive CAS types > like integers, bytes, etc. But the return value for this method in the JCas > is FSArray - which is an array of Feature Structures. Change this to return > TOP - which is the most specific common ancestor of the JCas cover classes > for primitive arrays. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (UIMA-143) JCas and CAS interface and impl refactoring for more sharing
JCas and CAS interface and impl refactoring for more sharing Key: UIMA-143 URL: http://issues.apache.org/jira/browse/UIMA-143 Project: UIMA Issue Type: Improvement Components: Core Java Framework Affects Versions: 2.1 Reporter: Marshall Schor Assigned To: Marshall Schor Priority: Minor Now that there is a JCas interface, look into some refactoring to share the interface definitions where possible. This includes: Adding some methods to JCas to make it more like the CAS. Cases where different types are returned can't be shared; e.g. one returns a CAS the other a JCas. Shared items put into new class BaseCas. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (UIMA-144) Wrong impl in JCasImpl for getView(local-view-name)
Wrong impl in JCasImpl for getView(local-view-name) --- Key: UIMA-144 URL: http://issues.apache.org/jira/browse/UIMA-144 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.1 Reporter: Marshall Schor Assigned To: Marshall Schor This method is erronously creating a new JCas instance for every call, instead of operating "lazily" in creating only if the JCas didn't exist. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Refactoring / cleanup : getting rid of sofa2jcasMap
CASImpl has a hashmap sofa2jcasMap. I think it is superfluous. It is used in the method getJCas(SofaFS). But I think that method can be replaced with a new definition that doesn't use this map: getView(SofaFS).getJCas(); Is there a reason we want to have this other hash map? -Marshall
adding missing methods to CAS / JCas interfaces: getView(String local_sofa_name) and getView(SofaFS)
It appears these some of these methods which are public in the CAS impl were missing in the interface, and missing in the interface/impl in the JCas. I'm adding them - if this is wrong, let me know :-) -Marshall
[jira] Resolved: (UIMA-143) JCas and CAS interface and impl refactoring for more sharing
[ http://issues.apache.org/jira/browse/UIMA-143?page=all ] Marshall Schor resolved UIMA-143. - Resolution: Fixed Assignee: Adam Lally (was: Marshall Schor) Interfaces refactored. JCas Impl forward to CASImpl in many cases. Assigned to Adam to review - but Eddie / Thilo may also want to. (All tests run) > JCas and CAS interface and impl refactoring for more sharing > > > Key: UIMA-143 > URL: http://issues.apache.org/jira/browse/UIMA-143 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Affects Versions: 2.1 >Reporter: Marshall Schor > Assigned To: Adam Lally >Priority: Minor > > Now that there is a JCas interface, look into some refactoring to share the > interface definitions where possible. This includes: > Adding some methods to JCas to make it more like the CAS. > Cases where different types are returned can't be shared; e.g. one returns a > CAS the other a JCas. > Shared items put into new class BaseCas. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (UIMA-144) Wrong impl in JCasImpl for getView(local-view-name)
[ http://issues.apache.org/jira/browse/UIMA-144?page=all ] Marshall Schor closed UIMA-144. --- Fix Version/s: 2.1 Resolution: Fixed fixed as part of UIMA-143 > Wrong impl in JCasImpl for getView(local-view-name) > --- > > Key: UIMA-144 > URL: http://issues.apache.org/jira/browse/UIMA-144 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.1 >Reporter: Marshall Schor > Assigned To: Marshall Schor > Fix For: 2.1 > > > This method is erronously creating a new JCas instance for every call, > instead of operating "lazily" in creating only if the JCas didn't exist. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
