lukas-vlcek / OpenSearch-list-built-in-analyzers

Experimental OpenSearch plugin to list all available Analyzers
Apache License 2.0
3 stars 0 forks source link

Plugin name/id construction should be more robust and unique #3

Closed lukas-vlcek closed 11 months ago

lukas-vlcek commented 1 year ago

Right now the plugin part of the output looks like this (example for analysis-icu plugin):

"plugins": [
  {
    "name" : "org.opensearch.plugin.analysis.icu.AnalysisICUPlugin",
    "analyzers" : [
      "icu_analyzer"
    ],
    "tokenizers" : [
      "icu_tokenizer"
    ],
    "tokenFilters" : [
      "icu_normalizer",
      "icu_folding",
      "icu_transform",
      "icu_collation"
    ],
    "charFilters" : [
      "icu_normalizer"
    ],
    "hunspellDictionaries" : [ ]
  }
]

There are two issues with the "name" field.

Robustness

The value of the "name" is obtained via getCanonicalName() method:

String pluginName = plugin.getClass().getCanonicalName();

The problem is that in some cases this value can be null. For example when the plugin is anonymous inner class. Although this is probably a rare case we shall try to propose more robust approach.

Uniqueness

Right now we store the plugins into a Map which uses the "name" filed as a key. This means that if there are two plugins exposing their class with the same package-name.class-name then they would conflict. We should think about better approach.

EDIT: To be more precise, such two plugins would not conflict per se. They can be printed ("toXContent") just fine on the output except it will be confusing for the end user. The goal should be to provide enough information in the "name" field so that user can distinguish between such plugins.

lukas-vlcek commented 11 months ago

There is another way how this issue can be solved. Instead of thinking about how to best construct name for a plugin we can pass this responsibility to a different class – and there is such a class: it is called org.opensearch.plugin.PluginInfo.

PluginInfo can provide both the name and classname for every plugin. The only issue here is that this class is not provided/accessible via PluginService. This is why I implemented a new filtering method in PluginService to make PluginInfo available for every filtered plugin. See https://github.com/opensearch-project/OpenSearch/pull/10296 for more details.