Hi, On Mon, Mar 30, 2009 at 10:08, Benjamin Brown <[email protected]> wrote: > Implementing a class that extends the NodeIterator to use these stats > (scores) is the easy part, however I have no idea how to get jcr to use this > implementation. Looking at the jcr 1.4 source I can see that the > QueryResultImpl uses either of two hardcoded types of NodeIterator in the > private method getNodeIterator(), wherein it creates new instances at that > point. There seems to be no obvious option for the user to specify the type > of iterator and although the class is not final, I cannot override > getNodeIterator() as it is private.
these classes are not intended for extensibility. there is no guarantee that they will be stable over releases. in fact, there was a recent change (JCR-2010) in jackrabbit-core trunk that rearranged quite a lot of code in this area. If you need a custom node iterator you probably have write your own QueryResult where you can create your node iterator. > Can someone give me pointers on how to provide a custom node iterator? jackrabbit does not allow this. see above. > Also, can someone please tell me why there are two ScoreNodeIterator > interfaces and the difference between the > jcr2spi package and the core.query.lucene package? jcr2spi is a separate module that implements a JCR repository on top of the jackrabbit SPI interfaces, whereas the core.query.lucene package contains classes that implement a jackrabbit-core QueryHandler on top of apache lucene. > I think I should be using the jcr2spi interface somewhere and not trying to > fudge the existing jcr queryresultimpl > into using my implementation however Googling and looking at the jcr site and > wiki have (not yet) yielded results. there's probably some overlapping code that could be factored out into the spi-commons module. Multiple modules then could use it to implement a QueryResult. Patches welcome ;) regards marcel
