The problem is that this search implementation needs to follow the JCR specification and it does quite a bit of custom code to map JCR properties to Lucene, needs to be fast to not block save() calls too long etc. Some features (user management) might depend on the full JCR query support. So "switching it out with SOLR" is not easy and might lead to more problems than it solves.
In Oak [0] therefore the search is seen as a pluggable thing, where you might have the JCR query compatible search index but also others. Oak experts can probably say more about what is currently available or is planned (on [email protected]). There is an experimental oak solr integration [1]. What you can do with the existing Jackrabbit is to use an observation listener to update an external index such as Solr asynchronously. [0] http://wiki.apache.org/jackrabbit/Jackrabbit%203 [1] http://slideshare.net/teofili/oak-solr-integration HTH, Alex On 30.05.2013, at 11:24, sephiroth75 <[email protected]> wrote: > As far as I understood to substitute the integrated search engine Lucene, > I've to extends the class > org.apache.jackrabbit.core.query.lucene.SearchIndex or implementing > org.apache.jackrabbit.core.query.QueryHandler. How tight is the integration > of Lucene, may I replace it with an external instance for example of SOLR? > Is there any guideline to do it? > The idea is to implement a mechanism of marshalling and unmarshalling of the > parameters passed by method of QueryHandler. > > Thanks in advance for every information about it. > > MC > > > > -- > View this message in context: > http://jackrabbit.510166.n4.nabble.com/Externalizing-search-tp4658790.html > Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
