jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-3555) Add a static utility to transform JCR Iterators into Iterables
Date Wed, 03 Apr 2013 07:27:15 GMT

    [ https://issues.apache.org/jira/browse/JCR-3555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13620693#comment-13620693
] 

Jukka Zitting commented on JCR-3555:
------------------------------------

Hmm, you're right. Now that I look at the code in JcrUtils again, I think the reason for that
approach is to avoid having to capture a RepositoryException and wrap it into a RuntimeException
in the iterator() method. I wonder if a hybrid solution where the first Iterator is acquired
immediately to be returned from the first iterator() call, and separate iterators would get
acquired (with potential RuntimeException wrapping) in the rare cases when someone calls iterator()
more than once. 

> Note, the advantage of using the same term for all Iterator types (whether it be "iterable"
or something else)
> is the fact that API users may find this more natural than having to look up the most
appropriate method
> name in a large list of utility methods...

The method naming in JcrUtils is based on the idea of turning an Iterator-returning x.getSomething(...)
method call to an Iterable-returning getSomething(x, ...) static call. The iterable() method
makes it iterable(x.getSomething(...)). I guess it's a matter of preference which one seems
better.

Given the use case, perhaps something like "for (Node child : in(parent.getNodes())) { ...
}" might be an alternative worth considering, especially since such a naming would discourage
someone from mistaking the return value as a properly stateless Iterable.

Also, we should consider putting such static utility methods in JcrUtils instead of a separate
Iterators class to have one central place for such utilities.

Anyway, to move forward on this while discussing the ultimate solution, I committed your patch
as-is in revision 1463843. Thanks!

                
> Add a static utility to transform JCR Iterators into Iterables
> --------------------------------------------------------------
>
>                 Key: JCR-3555
>                 URL: https://issues.apache.org/jira/browse/JCR-3555
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: jackrabbit-jcr-commons
>    Affects Versions: 2.6
>            Reporter: Lukas Eder
>            Priority: Minor
>         Attachments: Iterators.java.patch
>
>
> I have stumbled upon the utility classes in the org.apache.jackrabbit.commons.iterator
package. They're quite useful in principle, but not applied thoroughly. E.g. there are missing
wrapper types for at least these JCR Iterators:
> - AccessControlPolicyIterator
> - EventIterator
> - EventListenerIterator
> - NodeTypeIterator
> - VersionIterator
> Instead of adding more classes, it might be useful to create static methods for the job.
Using static methods from a single class (with static imports) is a bit more convenient than
looking up and creating the wrapper types using "new WrapperType(...)"
> An example:
> org.apache.jackrabbit.commons.iterator.Iterators.iterable
> // And then:
> for (Node n : iterable(parent.getNodes())) {
>   // Do stuff with n
> }
> Please find attached a .patch file containing an implementation suggestion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message