Details
-
Improvement
-
Status: Resolved
-
Minor
-
Resolution: Won't Fix
-
None
-
None
-
None
-
New
Description
CustomAnalyzer.Builder has methods which take implementation classes as follows.
- withTokenizer(Class<? extends TokenizerFactory> factory, String... params)
- withTokenizer(Class<? extends TokenizerFactory> factory, Map<String,String> params)
- addTokenFilter(Class<? extends TokenFilterFactory> factory, String... params)
- addTokenFilter(Class<? extends TokenFilterFactory> factory, Map<String,String> params)
- addCharFilter(Class<? extends CharFilterFactory> factory, String... params)
- addCharFilter(Class<? extends CharFilterFactory> factory, Map<String,String> params)
Since the builder also has methods which take service names, it seems like that above methods are unnecessary and a little bit misleading. Giving symbolic names is preferable to implementation factory classes, but for now, users can write code depending on implementation classes.
What do you think about deprecating those methods (adding @Deprecated annotations) and deleting them in the future releases? Those are called by only test cases so deleting them should have no impact on current lucene/solr codebase.
If this proposal gains your consent, I will create a patch. (Let me know if I missed some point. I'll close it.)
Attachments
Issue Links
- is blocked by
-
LUCENE-8873 Improve analyzer factoryies' Javadoc.
- Open
-
LUCENE-8778 Define analyzer SPI names as static final fields and document the names in Javadocs
- Reopened
- is caused by
-
LUCENE-6958 Improve CustomAnalyzer to also allow to specify factory directly (for compile-time safety)
- Closed
- is related to
-
SOLR-13593 Allow to look-up analyzer components by their SPI names in field type configuration
- Closed
-
LUCENE-8894 Add APIs to tokenizer/charfilter/tokenfilter factories to get their SPI names from concrete classes
- Closed
-
LUCENE-8957 Update examples in CustomAnalyzer Javadocs
- Reopened