One of the reasons I really don't like Iterators in SPI is because they make it hard to perform logging. I have a dynamic proxy that performs trace logging for SPI calls. So in my SPI's I use Apache ResettableIterator's wherever I can, which my trace logger knows about. For any other Iterator though, I can't log what's going on, without being sure I'm not impacting behavior.
David On Fri, 2008-02-22 at 11:25 -0800, Marcel Reutegger (JIRA) wrote: > [ > https://issues.apache.org/jira/browse/JCR-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571544#action_12571544 > ] > > Marcel Reutegger commented on JCR-1405: > --------------------------------------- > > Julian wrote: > > So what am I supposed to do when internally an error occurs? > > I think you should not even create a NodeInfo in that case. IMO a NodeInfo > should be self contained and shouldn't hold resources tied to the underlying > repository. > > That's actually also a reason why I don't like changing the return values to > an Iterator ;) > Whenever Iterators are returned it implies that an implementation is allowed > (or even encouraged) to lazily retrieve the items. This lazy approach however > has some issues. See also JSR 283 mailing list thread 'I whish there was > ....'. > > This new method is not intended to return large amounts of ChildInfos that > are lazily instanciated and should therefore use an array. > > > SPI: Introduce NodeInfo.getChildInfos() > > --------------------------------------- > > > > Key: JCR-1405 > > URL: https://issues.apache.org/jira/browse/JCR-1405 > > Project: Jackrabbit > > Issue Type: New Feature > > Components: jackrabbit-spi > > Reporter: angela > > Attachments: JCR-1405.patch > > > > > > Improvement suggested by Marcel: > > ChildInfo is basically a stripped down NodeInfo. With little effort it > > would even be possible to have NodeInfo extends ChildInfo. Not sure how > > useful that is, but since we don't have that inheritance in code and at the > > same time nearly a 100% overlap it makes me suspicious. > > Here's another idea: > > introduce a method ChildInfo[] NodeInfo.getChildInfos(). The method either > > returns: > > - all child infos, which also gives the correct number of child nodes. this > > may also mean that an empty array is returned to indicate there are no > > child nodes. > > - null, to indicate that there are *lots* of child nodes and the method > > RepositoryService.getChildInfos() with the iterator should be used. >
