On 1/20/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
The impl of JCas TOP has code in it to copy into the newly created
feature structure in the CAS, the CAS's current sofa ref:
if (casImpl.isAnnotationType(jcasType.casTypeCode)) {
casImpl.setSofaFeat(addr, casImpl.getSofaRef());
But
On 1/20/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
There's a general "rule" in Java that you should not store a ref to a
partially-initialized instance in another object, because it allows
another thread to potentially access a Java Object that is not yet fully
initialized.
The use of JCasReg
The impl of JCas TOP has code in it to copy into the newly created
feature structure in the CAS, the CAS's current sofa ref:
if (casImpl.isAnnotationType(jcasType.casTypeCode)) {
casImpl.setSofaFeat(addr, casImpl.getSofaRef());
But this seems to not be general enough. I think it should
There's a general "rule" in Java that you should not store a ref to a
partially-initialized instance in another object, because it allows
another thread to potentially access a Java Object that is not yet fully
initialized.
The use of JCasRegistry might be doing this. It stores into an
exter
[
https://issues.apache.org/jira/browse/UIMA-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Lally resolved UIMA-10.
Resolution: Fixed
Assignee: Marshall Schor (was: Adam Lally)
Refactoring complete. Assigning to Marsha
[ http://issues.apache.org/jira/browse/UIMA-10?page=all ]
Marshall Schor resolved UIMA-10.
Resolution: Fixed
Assignee: Adam Lally (was: Marshall Schor)
Thanks for pointing out the need to switch more things over to using JCas
instead of JCasImpl.
[ http://issues.apache.org/jira/browse/UIMA-10?page=all ]
Marshall Schor resolved UIMA-10.
Resolution: Fixed
Assignee: Adam Lally (was: Marshall Schor)
This is now done. JCasGen has been fixed also to generate the right cover
classes.
Should we
