Closed lukas-vlcek closed 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.
Right now the plugin part of the output looks like this (example for
analysis-icu
plugin):There are two issues with the
"name"
field.Robustness
The value of the
"name"
is obtained viagetCanonicalName()
method: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 samepackage-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.