ijioio commented on PR #931:
URL: https://github.com/apache/solr/pull/931#issuecomment-1181375536
Hi @cpoerschke! Thanks for the comment!
> It's a bit subjective of course but the solr.xml needing to be changed,
that seems a bit of a burden, both operationally and in terms of code
complexity? I wonder if there might be some way to dynamically discover actions
e.g. if the action was a fully qualified class path and CoreAdminHandler had
access to SolrResourceLoader then could SolrResourceLoader.newInstance
instantiate the action on demand?
Yeah, that would be nice to not bother with `solr.xml`, but at the moment I
doesn't see nice workaround.
Pluggable nature usually implies classes should be defined somewhere
(`*.xml`, `manifest.mf`, etc). On system start plugin files are examined for
plugin extention points, and some global registry is populated with the
relevant entries (let's not take into account some plugin frameworks that can
do runtime loading/unloading , like OSGi). So we can say we applied exactly the
same idea above. Solr can be assumed as "pluggable" to some extent, as custom
things can be redefined in configuration (`solr.xml` or `solrconfig.xml`), but
Solr still is not fully qualified pluggable (no plugin extension points, no
separation/isolation of classloaders).
The other way to do discovery, is dynamic class descovery by scanning the
classpath. From one side it looks very powerfull, you can use annotations for
marking classes, etc. But at the same time it is quite heavy and implies
unnecassary class loading.
I am still examing different parts of Solr, so maybe I have missed
something, and there are already some examples of dynamic discovery of classes.
If you know of some examples, give me a note please.
> From a use point of view the action being a class path seems not very nice
though. We could make up some convention where the pluggable class always
starts with (say) CustomCoreAdminOp and where the action follows after that
(say) CustomCoreAdminOpFoo but I don't know if going from foo action to
CustomCoreAdminOpFoo class name would be enough to actually instantiate an
object. Plus there could be two classes with the same name in different name
spaces. Hmm.
It is possible to go the way you suggested, we can make an interface
implying the action name definition:
```
public interface CustomCoreAdminOp extends CoreAdminOp {
public String getName();
}
```
and even provide some way to override/alias the action name. But I am agree,
pushing the full qualified class name is looks too much.
Another idea is, first users need to execute some register action request,
i.e.
```
http://localhost:8983/solr/admin/cores?action=registeraction&class=com.ijioio.solr.action.FooAction&name=foo
```
But it implies always running this register action on all the shards, at
least for cases when your action is a part of collection related logic :( Feels
quite tricky and not transparent.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
