[jira] Closed: (UIMA-1352) java.lang.ClassCastException using find() with a SET index
[
https://issues.apache.org/jira/browse/UIMA-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thilo Goetz closed UIMA-1352.
-
Resolution: Fixed
Did not fix the issue with bag index find() that was discussed as a follow-up
to this issue. Should open separate issue.
java.lang.ClassCastException using find() with a SET index
--
Key: UIMA-1352
URL: https://issues.apache.org/jira/browse/UIMA-1352
Project: UIMA
Issue Type: Bug
Components: Core Java Framework
Affects Versions: 2.2.2
Environment: Linux openSUSE 10.2
Reporter: Pablo D.
Assignee: Thilo Goetz
Fix For: 2.3
Attachments: uima_test.zip
It is not possible to use the FSIndex.find() method when the indexing
strategy is a SET.
A java.lang.ClassCastException is thrown.
For example:
FSIndex idx = aJCas.getJFSIndexRepository().getIndex(idx_SET);
while (doSomething) {
MyFeatureStructure myFs = new MyFeatureStructure(aJCas);
myFs.setMyFeature(value);
myFs.addToIndexes();
// Try to recover from index
MyFeatureStructure otherFs = (MyFeatureStructure)idx.find(myFs); //
ClassCastException
...
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Closed: (UIMA-1352) java.lang.ClassCastException using find() with a SET index
Marshall Schor wrote: Thilo Goetz wrote: [...] I take that back. find() works anyway. The question with moveTo(fs) is simply what the behavior should be in case fs is not in the index. If it is in the index, the cursor will be positioned there, even for bag indexes. If it's not there, the cursor will currently be positioned at an arbitrary point. This is a left-over from the days when bag indexes were also sorted and simply a bug, to my mind. My intuition is that moveTo(fs) should make the iterator invalid if fs is not in the index. +1 for having the iterator invalid if the fs is not in the index. NB that the notion of equality here is FS identity. Not sure this is clear from the documentation. I'm not sure what FS identity means. I thought that (for Set indexes) the comparison for equality was index-dependent, and used whatever keys were declared in the index. Do you mean that the FS address in the heap must be the same (by FS identity), and does this test apply just for Bag indexes? Yes, and yes. I use equality for the equivalence relation induced by the ordering relation on the index, and identity when I mean same address. Even more confusingly, identity is what FeatureStructure.equals() tests for :-). Since bag indexes have no ordering relation, the only useful notion of equality is identity, in the sense above. -Marshall --Thilo
Re: [jira] Closed: (UIMA-1352) java.lang.ClassCastException using find() with a SET index
Thilo Goetz wrote: Thilo Goetz wrote: Marshall Schor wrote: Thilo Goetz wrote: Marshall Schor wrote: Thilo Goetz wrote: See the Jira issue for the cause of the problem. More comments below. Marshall Schor wrote: So, there may be 2 things to look at here - the actual error, described above, and the more philosophical question on the behavior of moveTo - this seems to require a sorting order if the item moved to is not present in the index. Perhaps this needs to be documented better. And I'm not sure I understand your point about moveTo(). It requires the index to be sorted to make any sense (and the BagIndex moveTo() is broken, but that's a different issue Will you be fixing this too? We enter the realm of philosophy again. What's the right behavior for moveTo() when the underlying index isn't sorted? In particular, what should happen when no proper element is found? The javadocs say: Note that any operation like find() or FSIterator.moveTo() will not produce useful results on bag indexes, since bag indexes do not honor comparators. Only use a bag index if you want very fast adding and will have to iterate over the whole index anyway. I like systems where user errors are reported :-). If find() and moveTo() don't work on bag indexes, I would prefer they throw an exception, perhaps like UnsupportedOperationException or our equivalent in UIMA. Fine with me. I take that back. find() works anyway. The question with moveTo(fs) is simply what the behavior should be in case fs is not in the index. If it is in the index, the cursor will be positioned there, even for bag indexes. If it's not there, the cursor will currently be positioned at an arbitrary point. This is a left-over from the days when bag indexes were also sorted and simply a bug, to my mind. My intuition is that moveTo(fs) should make the iterator invalid if fs is not in the index. +1 for having the iterator invalid if the fs is not in the index. NB that the notion of equality here is FS identity. Not sure this is clear from the documentation. I'm not sure what FS identity means. I thought that (for Set indexes) the comparison for equality was index-dependent, and used whatever keys were declared in the index. Do you mean that the FS address in the heap must be the same (by FS identity), and does this test apply just for Bag indexes? -Marshall --Thilo
Re: [jira] Closed: (UIMA-1352) java.lang.ClassCastException using find() with a SET index
See the Jira issue for the cause of the problem. More comments below. Marshall Schor wrote: So, there may be 2 things to look at here - the actual error, described above, and the more philosophical question on the behavior of moveTo - this seems to require a sorting order if the item moved to is not present in the index. Perhaps this needs to be documented better. And I'm not sure I understand your point about moveTo(). It requires the index to be sorted to make any sense (and the BagIndex moveTo() is broken, but that's a different issue). moveTo(fs) will position the iterator such that any element to the left is smaller than fs, and all elements at the moved-to position and to the right of it are greater than or equal to fs. It doesn't matter if the item moved to is in the index or not. Remember that equality here is defined with respect to the sort order of the index, it is not feature structure identity. All this is documented, but maybe not as clearly as it could be. what if no sorting order was defined for the set index? Every set index has a sort order. If that sort order is empty, it means that all FSs are equal for that index. That in turn means that this index will contain at most 1 FS at any time. It also means that moveTo() will always position the iterator at that one element, if it exists. Did that help at all? --Thilo
Re: [jira] Closed: (UIMA-1352) java.lang.ClassCastException using find() with a SET index
Thilo Goetz wrote: See the Jira issue for the cause of the problem. More comments below. Marshall Schor wrote: So, there may be 2 things to look at here - the actual error, described above, and the more philosophical question on the behavior of moveTo - this seems to require a sorting order if the item moved to is not present in the index. Perhaps this needs to be documented better. And I'm not sure I understand your point about moveTo(). It requires the index to be sorted to make any sense (and the BagIndex moveTo() is broken, but that's a different issue Will you be fixing this too? ). moveTo(fs) will position the iterator such that any element to the left is smaller than fs, and all elements at the moved-to position and to the right of it are greater than or equal to fs. It doesn't matter if the item moved to is in the index or not. Remember that equality here is defined with respect to the sort order of the index, it is not feature structure identity. Yes, this is something that is unexpected (to me), and I did forget this. All this is documented, but maybe not as clearly as it could be. what if no sorting order was defined for the set index? Every set index has a sort order. This is the part that seems confusing, because our docs say that set indexes do not enforce ordering, and the common definition for Sets does not have an ordering concept. Yet our docs say that the sort order for sets is used to determine equality among candidates in the set: from section 2.4.1.7: An index may define one or more /keys/. These keys determine the sort order of the feature structures within a sorted index, and determine equality for set indexes. Perhaps this should also say something about the use of the sort order in moveTo(fs) for sets? If that sort order is empty, it means that all FSs are equal for that index. That in turn means that this index will contain at most 1 FS at any time. It also means that moveTo() will always position the iterator at that one element, if it exists. Did that help at all? Yes, thanks for the clarifications. -Marshall --Thilo
Re: [jira] Closed: (UIMA-1352) java.lang.ClassCastException using find() with a SET index
Thilo Goetz wrote: Marshall Schor wrote: Thilo Goetz wrote: See the Jira issue for the cause of the problem. More comments below. Marshall Schor wrote: So, there may be 2 things to look at here - the actual error, described above, and the more philosophical question on the behavior of moveTo - this seems to require a sorting order if the item moved to is not present in the index. Perhaps this needs to be documented better. And I'm not sure I understand your point about moveTo(). It requires the index to be sorted to make any sense (and the BagIndex moveTo() is broken, but that's a different issue Will you be fixing this too? We enter the realm of philosophy again. What's the right behavior for moveTo() when the underlying index isn't sorted? In particular, what should happen when no proper element is found? The javadocs say: Note that any operation like find() or FSIterator.moveTo() will not produce useful results on bag indexes, since bag indexes do not honor comparators. Only use a bag index if you want very fast adding and will have to iterate over the whole index anyway. I like systems where user errors are reported :-). If find() and moveTo() don't work on bag indexes, I would prefer they throw an exception, perhaps like UnsupportedOperationException or our equivalent in UIMA. ). moveTo(fs) will position the iterator such that any element to the left is smaller than fs, and all elements at the moved-to position and to the right of it are greater than or equal to fs. It doesn't matter if the item moved to is in the index or not. Remember that equality here is defined with respect to the sort order of the index, it is not feature structure identity. Yes, this is something that is unexpected (to me), and I did forget this. All this is documented, but maybe not as clearly as it could be. what if no sorting order was defined for the set index? Every set index has a sort order. This is the part that seems confusing, because our docs say that set indexes do not enforce ordering, and the common definition for Sets does Where did you find that? The javadocs say that set indexes are not guaranteed to be sorted. That's different from saying there's no ordering relation on the members. How else would we determine equality? Just by testing the key values for equality, not for order. Maybe we should remove this text, because at this time, set indexes are sorted, and that's not likely to change (I was thinking of hash based sets when I wrote that; still, you'll need a notion of equality, no matter how you implement your sets, yet they don't need to be sorted). not have an ordering concept. Yet our docs say that the sort order for sets is used to determine equality among candidates in the set: from section 2.4.1.7: An index may define one or more /keys/. These keys determine the sort order of the feature structures within a sorted index, and determine equality for set indexes. That is incorrect. It should say 0 or more keys. Though if we should alert users to this fact if even UIMA developers have trouble with this is doubtful. I think some of our users could be better at remembering these details than I am :-) I think this should be fixed - it's just a typo IMHO. Perhaps this should also say something about the use of the sort order in moveTo(fs) for sets? In our current implementation, set indexes are sorted indexes without the duplicates (duplicates with respect to the ordering relation of that index, of course). If we commit to this and stop waffling about how set indexes may not be sorted, then we can just say that sorted and set indexes behave the same way. My preference is to keep the original definitions - leaving (perhaps unrealistically small) room for alternative implementations in the future. -Marshall If that sort order is empty, it means that all FSs are equal for that index. That in turn means that this index will contain at most 1 FS at any time. It also means that moveTo() will always position the iterator at that one element, if it exists. Did that help at all? Yes, thanks for the clarifications. -Marshall --Thilo
Re: [jira] Closed: (UIMA-1352) java.lang.ClassCastException using find() with a SET index
Marshall Schor wrote: Thilo Goetz wrote: Marshall Schor wrote: Thilo Goetz wrote: See the Jira issue for the cause of the problem. More comments below. Marshall Schor wrote: So, there may be 2 things to look at here - the actual error, described above, and the more philosophical question on the behavior of moveTo - this seems to require a sorting order if the item moved to is not present in the index. Perhaps this needs to be documented better. And I'm not sure I understand your point about moveTo(). It requires the index to be sorted to make any sense (and the BagIndex moveTo() is broken, but that's a different issue Will you be fixing this too? We enter the realm of philosophy again. What's the right behavior for moveTo() when the underlying index isn't sorted? In particular, what should happen when no proper element is found? The javadocs say: Note that any operation like find() or FSIterator.moveTo() will not produce useful results on bag indexes, since bag indexes do not honor comparators. Only use a bag index if you want very fast adding and will have to iterate over the whole index anyway. I like systems where user errors are reported :-). If find() and moveTo() don't work on bag indexes, I would prefer they throw an exception, perhaps like UnsupportedOperationException or our equivalent in UIMA. Fine with me. ). moveTo(fs) will position the iterator such that any element to the left is smaller than fs, and all elements at the moved-to position and to the right of it are greater than or equal to fs. It doesn't matter if the item moved to is in the index or not. Remember that equality here is defined with respect to the sort order of the index, it is not feature structure identity. Yes, this is something that is unexpected (to me), and I did forget this. All this is documented, but maybe not as clearly as it could be. what if no sorting order was defined for the set index? Every set index has a sort order. This is the part that seems confusing, because our docs say that set indexes do not enforce ordering, and the common definition for Sets does Where did you find that? The javadocs say that set indexes are not guaranteed to be sorted. That's different from saying there's no ordering relation on the members. How else would we determine equality? Just by testing the key values for equality, not for order. Equality here is a notion derived from the partial order defined on the index. You could define equality separately, but that would mean introducing a new notion into the index definitions. I don't think we want that, or at least I don't. Maybe we should remove this text, because at this time, set indexes are sorted, and that's not likely to change (I was thinking of hash based sets when I wrote that; still, you'll need a notion of equality, no matter how you implement your sets, yet they don't need to be sorted). not have an ordering concept. Yet our docs say that the sort order for sets is used to determine equality among candidates in the set: from section 2.4.1.7: An index may define one or more /keys/. These keys determine the sort order of the feature structures within a sorted index, and determine equality for set indexes. That is incorrect. It should say 0 or more keys. Though if we should alert users to this fact if even UIMA developers have trouble with this is doubtful. I think some of our users could be better at remembering these details than I am :-) I think this should be fixed - it's just a typo IMHO. Perhaps this should also say something about the use of the sort order in moveTo(fs) for sets? In our current implementation, set indexes are sorted indexes without the duplicates (duplicates with respect to the ordering relation of that index, of course). If we commit to this and stop waffling about how set indexes may not be sorted, then we can just say that sorted and set indexes behave the same way. My preference is to keep the original definitions - leaving (perhaps unrealistically small) room for alternative implementations in the future. Sure, but how do you propose we improve the documentation, then? -Marshall If that sort order is empty, it means that all FSs are equal for that index. That in turn means that this index will contain at most 1 FS at any time. It also means that moveTo() will always position the iterator at that one element, if it exists. Did that help at all? Yes, thanks for the clarifications. -Marshall --Thilo
Re: [jira] Closed: (UIMA-1352) java.lang.ClassCastException using find() with a SET index
Thilo Goetz wrote: Marshall Schor wrote: Thilo Goetz wrote: Marshall Schor wrote: Thilo Goetz wrote: See the Jira issue for the cause of the problem. More comments below. Marshall Schor wrote: So, there may be 2 things to look at here - the actual error, described above, and the more philosophical question on the behavior of moveTo - this seems to require a sorting order if the item moved to is not present in the index. Perhaps this needs to be documented better. And I'm not sure I understand your point about moveTo(). It requires the index to be sorted to make any sense (and the BagIndex moveTo() is broken, but that's a different issue Will you be fixing this too? We enter the realm of philosophy again. What's the right behavior for moveTo() when the underlying index isn't sorted? In particular, what should happen when no proper element is found? The javadocs say: Note that any operation like find() or FSIterator.moveTo() will not produce useful results on bag indexes, since bag indexes do not honor comparators. Only use a bag index if you want very fast adding and will have to iterate over the whole index anyway. I like systems where user errors are reported :-). If find() and moveTo() don't work on bag indexes, I would prefer they throw an exception, perhaps like UnsupportedOperationException or our equivalent in UIMA. Fine with me. I take that back. find() works anyway. The question with moveTo(fs) is simply what the behavior should be in case fs is not in the index. If it is in the index, the cursor will be positioned there, even for bag indexes. If it's not there, the cursor will currently be positioned at an arbitrary point. This is a left-over from the days when bag indexes were also sorted and simply a bug, to my mind. My intuition is that moveTo(fs) should make the iterator invalid if fs is not in the index. NB that the notion of equality here is FS identity. Not sure this is clear from the documentation. --Thilo
Re: [jira] Closed: (UIMA-1352) java.lang.ClassCastException using find() with a SET index
Thilo Goetz wrote: Marshall Schor wrote: Thilo Goetz wrote: Marshall Schor wrote: Thilo Goetz wrote: See the Jira issue for the cause of the problem. More comments below. Marshall Schor wrote: So, there may be 2 things to look at here - the actual error, described above, and the more philosophical question on the behavior of moveTo - this seems to require a sorting order if the item moved to is not present in the index. Perhaps this needs to be documented better. And I'm not sure I understand your point about moveTo(). It requires the index to be sorted to make any sense (and the BagIndex moveTo() is broken, but that's a different issue Will you be fixing this too? We enter the realm of philosophy again. What's the right behavior for moveTo() when the underlying index isn't sorted? In particular, what should happen when no proper element is found? The javadocs say: Note that any operation like find() or FSIterator.moveTo() will not produce useful results on bag indexes, since bag indexes do not honor comparators. Only use a bag index if you want very fast adding and will have to iterate over the whole index anyway. I like systems where user errors are reported :-). If find() and moveTo() don't work on bag indexes, I would prefer they throw an exception, perhaps like UnsupportedOperationException or our equivalent in UIMA. Fine with me. ). moveTo(fs) will position the iterator such that any element to the left is smaller than fs, and all elements at the moved-to position and to the right of it are greater than or equal to fs. It doesn't matter if the item moved to is in the index or not. Remember that equality here is defined with respect to the sort order of the index, it is not feature structure identity. Yes, this is something that is unexpected (to me), and I did forget this. All this is documented, but maybe not as clearly as it could be. what if no sorting order was defined for the set index? Every set index has a sort order. This is the part that seems confusing, because our docs say that set indexes do not enforce ordering, and the common definition for Sets does Where did you find that? The javadocs say that set indexes are not guaranteed to be sorted. That's different from saying there's no ordering relation on the members. How else would we determine equality? Just by testing the key values for equality, not for order. Equality here is a notion derived from the partial order defined on the index. You could define equality separately, but that would mean introducing a new notion into the index definitions. I don't think we want that, or at least I don't. I agree we don't want to introduce a new notion of equality for index definitions at this point. Maybe we should remove this text, because at this time, set indexes are sorted, and that's not likely to change (I was thinking of hash based sets when I wrote that; still, you'll need a notion of equality, no matter how you implement your sets, yet they don't need to be sorted). not have an ordering concept. Yet our docs say that the sort order for sets is used to determine equality among candidates in the set: from section 2.4.1.7: An index may define one or more /keys/. These keys determine the sort order of the feature structures within a sorted index, and determine equality for set indexes. That is incorrect. It should say 0 or more keys. Though if we should alert users to this fact if even UIMA developers have trouble with this is doubtful. I think some of our users could be better at remembering these details than I am :-) I think this should be fixed - it's just a typo IMHO. Perhaps this should also say something about the use of the sort order in moveTo(fs) for sets? In our current implementation, set indexes are sorted indexes without the duplicates (duplicates with respect to the ordering relation of that index, of course). If we commit to this and stop waffling about how set indexes may not be sorted, then we can just say that sorted and set indexes behave the same way. My preference is to keep the original definitions - leaving (perhaps unrealistically small) room for alternative implementations in the future. Sure, but how do you propose we improve the documentation, then? I'll take a crack at doing this -Marshall If that sort order is empty, it means that all FSs are equal for that index. That in turn means that this index will contain at most 1 FS at any time. It also means that moveTo() will always position the
Re: [jira] Closed: (UIMA-1352) java.lang.ClassCastException using find() with a SET index
Marshall Schor wrote:
I think this fix gives rise to another test case failure. I backed out
this fix, and the (I think new) test in IteratorTest - testIterator
fails on line 357.
With this fix restored, there is a failure on IteratorTest - testDelete,
line 662.
Thilo - I think you are the best person to investigate - can you take a
look, please?
Hm, I can't reproduce this. Works for me, fresh out of svn. I did run
all the test cases before I committed this change. Can you make sure
you're at the latest level, and if you are, give me platform details,
in particular exactly which jvm you're using. Thanks.
--Thilo
-Marshall
Thilo Goetz (JIRA) wrote:
[
https://issues.apache.org/jira/browse/UIMA-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thilo Goetz closed UIMA-1352.
-
Resolution: Fixed
Fix Version/s: 2.3
Fixed, and Pablo's test case added. Pablo, please verify if possible.
java.lang.ClassCastException using find() with a SET index
--
Key: UIMA-1352
URL: https://issues.apache.org/jira/browse/UIMA-1352
Project: UIMA
Issue Type: Bug
Components: Core Java Framework
Affects Versions: 2.2.2
Environment: Linux openSUSE 10.2
Reporter: Pablo D.
Assignee: Thilo Goetz
Fix For: 2.3
Attachments: uima_test.zip
It is not possible to use the FSIndex.find() method when the indexing
strategy is a SET.
A java.lang.ClassCastException is thrown.
For example:
FSIndex idx = aJCas.getJFSIndexRepository().getIndex(idx_SET);
while (doSomething) {
MyFeatureStructure myFs = new MyFeatureStructure(aJCas);
myFs.setMyFeature(value);
myFs.addToIndexes();
// Try to recover from index
MyFeatureStructure otherFs = (MyFeatureStructure)idx.find(myFs); //
ClassCastException
...
}
Re: [jira] Closed: (UIMA-1352) java.lang.ClassCastException using find() with a SET index
Some tracing of the failure case on my machine.
The test prepares 100 FS, with begin/end pairs starting at 0/4, 5/9,
etc. Let's call these token(0,4) token(5,9) etc.
It inserts them into the indexes.
It removes the 0-eth one (OK).
It does a set iterator moveTo(fsArray[i]), the one it removed. This
might be suspect, because for Set indexes, our docs say Set indexes do
not enforce ordering. So moveTo(x) where x is not in the index seems
to be to be undefined, without a sort order.
The comment in the code for the moveTo(arg) method says:
* Move the iterator to the first features structure that is equal to
codefs/code. If no
* such feature structure exists in the underlying collection, set the
iterator to the insertion
* point for codefs/code, i.e., to a point where the current
feature structure is greater
* than codefs/code, and the previous one is less than
codefs/code.
Now, it turns out that the definition of the set index includes the
begin and end features in the same way as the normal index does, so
perhaps the code is sorting based on this, anyway. The set index def
*does not* include TYPE PRIORITY as the 3rd element, however. ( I don't
think that matters here, since all the begin/end vlaues are different).
The moveTo positions the iterator so that the next get() gets the token(5,9)
When the loop finixhes, it re-inserts the token(0,4) it had removed.
This shows up in the fs index in the 0th position.
The error happens in the next loop.
The token(5,9) is removed from the set index, but when I look at the
index contents, instead of that one being removed, the token(80,84)
disappears from the set index!
When the request to move to token(5,9) is given, since that element is
still there, it moves to it. And then the test produces an assert error.
So, there may be 2 things to look at here - the actual error, described
above, and the more philosophical question on the behavior of moveTo -
this seems to require a sorting order if the item moved to is not
present in the index. Perhaps this needs to be documented better. And
what if no sorting order was defined for the set index?
-Marshall
Marshall Schor wrote:
I think this fix gives rise to another test case failure. I backed out
this fix, and the (I think new) test in IteratorTest - testIterator
fails on line 357.
With this fix restored, there is a failure on IteratorTest - testDelete,
line 662.
Thilo - I think you are the best person to investigate - can you take a
look, please?
-Marshall
Thilo Goetz (JIRA) wrote:
[
https://issues.apache.org/jira/browse/UIMA-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thilo Goetz closed UIMA-1352.
-
Resolution: Fixed
Fix Version/s: 2.3
Fixed, and Pablo's test case added. Pablo, please verify if possible.
java.lang.ClassCastException using find() with a SET index
--
Key: UIMA-1352
URL: https://issues.apache.org/jira/browse/UIMA-1352
Project: UIMA
Issue Type: Bug
Components: Core Java Framework
Affects Versions: 2.2.2
Environment: Linux openSUSE 10.2
Reporter: Pablo D.
Assignee: Thilo Goetz
Fix For: 2.3
Attachments: uima_test.zip
It is not possible to use the FSIndex.find() method when the indexing
strategy is a SET.
A java.lang.ClassCastException is thrown.
For example:
FSIndex idx = aJCas.getJFSIndexRepository().getIndex(idx_SET);
while (doSomething) {
MyFeatureStructure myFs = new MyFeatureStructure(aJCas);
myFs.setMyFeature(value);
myFs.addToIndexes();
// Try to recover from index
MyFeatureStructure otherFs = (MyFeatureStructure)idx.find(myFs); //
ClassCastException
...
}
Re: [jira] Closed: (UIMA-1352) java.lang.ClassCastException using find() with a SET index
Marshall Schor wrote: Just FYI - On my setup system, it fails both in mvn and Eclipse. I have no idea what's going on on my machine. I'm using the same source code directory in Eclipse and on the command line, and still getting different results. I fixed the issue now so maybe this doesn't need solving any more, but it does worry me. --Thilo
Re: [jira] Closed: (UIMA-1352) java.lang.ClassCastException using find() with a SET index
I think this fix gives rise to another test case failure. I backed out
this fix, and the (I think new) test in IteratorTest - testIterator
fails on line 357.
With this fix restored, there is a failure on IteratorTest - testDelete,
line 662.
Thilo - I think you are the best person to investigate - can you take a
look, please?
-Marshall
Thilo Goetz (JIRA) wrote:
[
https://issues.apache.org/jira/browse/UIMA-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thilo Goetz closed UIMA-1352.
-
Resolution: Fixed
Fix Version/s: 2.3
Fixed, and Pablo's test case added. Pablo, please verify if possible.
java.lang.ClassCastException using find() with a SET index
--
Key: UIMA-1352
URL: https://issues.apache.org/jira/browse/UIMA-1352
Project: UIMA
Issue Type: Bug
Components: Core Java Framework
Affects Versions: 2.2.2
Environment: Linux openSUSE 10.2
Reporter: Pablo D.
Assignee: Thilo Goetz
Fix For: 2.3
Attachments: uima_test.zip
It is not possible to use the FSIndex.find() method when the indexing
strategy is a SET.
A java.lang.ClassCastException is thrown.
For example:
FSIndex idx = aJCas.getJFSIndexRepository().getIndex(idx_SET);
while (doSomething) {
MyFeatureStructure myFs = new MyFeatureStructure(aJCas);
myFs.setMyFeature(value);
myFs.addToIndexes();
// Try to recover from index
MyFeatureStructure otherFs = (MyFeatureStructure)idx.find(myFs); //
ClassCastException
...
}
[jira] Closed: (UIMA-1352) java.lang.ClassCastException using find() with a SET index
[
https://issues.apache.org/jira/browse/UIMA-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thilo Goetz closed UIMA-1352.
-
Resolution: Fixed
Fix Version/s: 2.3
Fixed, and Pablo's test case added. Pablo, please verify if possible.
java.lang.ClassCastException using find() with a SET index
--
Key: UIMA-1352
URL: https://issues.apache.org/jira/browse/UIMA-1352
Project: UIMA
Issue Type: Bug
Components: Core Java Framework
Affects Versions: 2.2.2
Environment: Linux openSUSE 10.2
Reporter: Pablo D.
Assignee: Thilo Goetz
Fix For: 2.3
Attachments: uima_test.zip
It is not possible to use the FSIndex.find() method when the indexing
strategy is a SET.
A java.lang.ClassCastException is thrown.
For example:
FSIndex idx = aJCas.getJFSIndexRepository().getIndex(idx_SET);
while (doSomething) {
MyFeatureStructure myFs = new MyFeatureStructure(aJCas);
myFs.setMyFeature(value);
myFs.addToIndexes();
// Try to recover from index
MyFeatureStructure otherFs = (MyFeatureStructure)idx.find(myFs); //
ClassCastException
...
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
