You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Gerald Turner (JIRA)" <ji...@apache.org> on 2011/05/04 00:29:03 UTC
[jira] [Created] (DIRSHARED-124) SearchCursorImpl breaks
java.lang.Iterable
SearchCursorImpl breaks java.lang.Iterable
------------------------------------------
Key: DIRSHARED-124
URL: https://issues.apache.org/jira/browse/DIRSHARED-124
Project: Directory Shared
Issue Type: Bug
Affects Versions: 1.0.0-M3
Reporter: Gerald Turner
Priority: Minor
Code like:
SearchCursor search = connection.search(...);
for (Response response : search) { ... }
Does not work (no elements iterated), even though SearchCursor is advertised as being Iterable<Response>.
The problem begins with the CursorIterator constructor:
public CursorIterator( Cursor<E> cursor )
{
this.cursor = cursor;
this.available = cursor.available();
}
The available field will be set to false for SearchCursorImpl, just as the javadoc in Cursor implies "Determines whether or not a call to get() will succeed." - since next() must be called first.
Initially I thought about patching the CursorIterator to call next() instead of available(), however next throws an exception and it is impractical to handle an exception in the iterator constructor.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRSHARED-124) SearchCursorImpl breaks
java.lang.Iterable
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSHARED-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038581#comment-13038581 ]
Emmanuel Lecharny commented on DIRSHARED-124:
---------------------------------------------
Added another fix to deal with empty cursors : http://svn.apache.org/viewvc?rev=1127075&view=rev
> SearchCursorImpl breaks java.lang.Iterable
> ------------------------------------------
>
> Key: DIRSHARED-124
> URL: https://issues.apache.org/jira/browse/DIRSHARED-124
> Project: Directory Shared
> Issue Type: Bug
> Affects Versions: 1.0.0-M3
> Reporter: Gerald Turner
> Priority: Minor
> Fix For: 1.0.0-M4
>
>
> Code like:
> SearchCursor search = connection.search(...);
> for (Response response : search) { ... }
> Does not work (no elements iterated), even though SearchCursor is advertised as being Iterable<Response>.
> The problem begins with the CursorIterator constructor:
> public CursorIterator( Cursor<E> cursor )
> {
> this.cursor = cursor;
> this.available = cursor.available();
> }
> The available field will be set to false for SearchCursorImpl, just as the javadoc in Cursor implies "Determines whether or not a call to get() will succeed." - since next() must be called first.
> Initially I thought about patching the CursorIterator to call next() instead of available(), however next throws an exception and it is impractical to handle an exception in the iterator constructor.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DIRSHARED-124) SearchCursorImpl breaks
java.lang.Iterable
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSHARED-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny resolved DIRSHARED-124.
-----------------------------------------
Resolution: Fixed
A really good catch !
Fixed (hopefully) with http://svn.apache.org/viewvc?rev=1126479&view=rev
> SearchCursorImpl breaks java.lang.Iterable
> ------------------------------------------
>
> Key: DIRSHARED-124
> URL: https://issues.apache.org/jira/browse/DIRSHARED-124
> Project: Directory Shared
> Issue Type: Bug
> Affects Versions: 1.0.0-M3
> Reporter: Gerald Turner
> Priority: Minor
> Fix For: 1.0.0-M4
>
>
> Code like:
> SearchCursor search = connection.search(...);
> for (Response response : search) { ... }
> Does not work (no elements iterated), even though SearchCursor is advertised as being Iterable<Response>.
> The problem begins with the CursorIterator constructor:
> public CursorIterator( Cursor<E> cursor )
> {
> this.cursor = cursor;
> this.available = cursor.available();
> }
> The available field will be set to false for SearchCursorImpl, just as the javadoc in Cursor implies "Determines whether or not a call to get() will succeed." - since next() must be called first.
> Initially I thought about patching the CursorIterator to call next() instead of available(), however next throws an exception and it is impractical to handle an exception in the iterator constructor.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DIRSHARED-124) SearchCursorImpl breaks
java.lang.Iterable
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSHARED-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny updated DIRSHARED-124:
----------------------------------------
Fix Version/s: 1.0.0-M4
Let's fic this one for 1.0.0-M4
> SearchCursorImpl breaks java.lang.Iterable
> ------------------------------------------
>
> Key: DIRSHARED-124
> URL: https://issues.apache.org/jira/browse/DIRSHARED-124
> Project: Directory Shared
> Issue Type: Bug
> Affects Versions: 1.0.0-M3
> Reporter: Gerald Turner
> Priority: Minor
> Fix For: 1.0.0-M4
>
>
> Code like:
> SearchCursor search = connection.search(...);
> for (Response response : search) { ... }
> Does not work (no elements iterated), even though SearchCursor is advertised as being Iterable<Response>.
> The problem begins with the CursorIterator constructor:
> public CursorIterator( Cursor<E> cursor )
> {
> this.cursor = cursor;
> this.available = cursor.available();
> }
> The available field will be set to false for SearchCursorImpl, just as the javadoc in Cursor implies "Determines whether or not a call to get() will succeed." - since next() must be called first.
> Initially I thought about patching the CursorIterator to call next() instead of available(), however next throws an exception and it is impractical to handle an exception in the iterator constructor.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRSHARED-124) SearchCursorImpl breaks
java.lang.Iterable
Posted by "Kiran Ayyagari (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSHARED-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13028615#comment-13028615 ]
Kiran Ayyagari commented on DIRSHARED-124:
------------------------------------------
The issue is in the CursorIterator.next() method, which is calling get() before calling next() on the underlying cursor.
However i think this can be fixed by changing the CursorIterator.hasNext() to call underlying cursor's next() method and return it's value rather than maintaining a
available flag locally and making CursorIterator.next() to just return the value returned from underlying cursor's get().
> SearchCursorImpl breaks java.lang.Iterable
> ------------------------------------------
>
> Key: DIRSHARED-124
> URL: https://issues.apache.org/jira/browse/DIRSHARED-124
> Project: Directory Shared
> Issue Type: Bug
> Affects Versions: 1.0.0-M3
> Reporter: Gerald Turner
> Priority: Minor
>
> Code like:
> SearchCursor search = connection.search(...);
> for (Response response : search) { ... }
> Does not work (no elements iterated), even though SearchCursor is advertised as being Iterable<Response>.
> The problem begins with the CursorIterator constructor:
> public CursorIterator( Cursor<E> cursor )
> {
> this.cursor = cursor;
> this.available = cursor.available();
> }
> The available field will be set to false for SearchCursorImpl, just as the javadoc in Cursor implies "Determines whether or not a call to get() will succeed." - since next() must be called first.
> Initially I thought about patching the CursorIterator to call next() instead of available(), however next throws an exception and it is impractical to handle an exception in the iterator constructor.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira