[
https://issues.apache.org/jira/browse/OAK-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14237736#comment-14237736
]
Michael Marth commented on OAK-2177:
------------------------------------
[~chetanm],
the approach above looks feasible to me, however I wonder about
# you write "tricky due to dynamic nature of OSGi". Is your approach above
"less tricky" because the analyzers etc are supposed to be loaded at startup?
# if the above is correct then I assume the major downside of your approach is
that it needs a restart when a new analyzer needs to be added. Correct?
Anything other downsides?
# can stopwords be added/removed at runtime? Can analyzers be dynamically added
to new index definitions provided they were loaded at startup?
Thanks for clarifying!
More generally, I think we should not add a temporary mechanism now and
deprecate it soon (in Oak 1.2 time frame) in favour of an OSGi-based approach.
Meaning, if we decide with your approach now we should stick with it (or in
turn go for a potentially better approach right away).
> Configurable Analyzer in Lucene index
> -------------------------------------
>
> Key: OAK-2177
> URL: https://issues.apache.org/jira/browse/OAK-2177
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: oak-lucene
> Affects Versions: 1.1.0
> Reporter: Tommaso Teofili
> Assignee: Chetan Mehrotra
> Attachments: OAK-2177.patch
>
>
> Currently the _OakAnalyzer_ is used by default for each Lucene field,
> sometimes using a different analyzer is needed though.
> It should be possible to make that configurable to support things like:
> multiple languages, stopword filtering, synonyms expansion, stemming, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
