[
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
