[
https://issues.apache.org/jira/browse/SOLR-14404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147013#comment-17147013
]
Uwe Schindler commented on SOLR-14404:
--------------------------------------
Reflection is not the issue. The issue is that it uses getDeclaredMethods()
which returns all methods in the class.
IMHO, also for Performance reasons the whole thing should use MethodHandles
with a public lookup to ensure only public methods are found. This also moves
the linking phase of the API to the annotation lookups and the calls to the API
methods are then directly linked. All errors caused by security issues are
catched early, when the {{AnnotatedApi#Cmd}} are instantiated. I would
implement it like that:
- Lookup all methods like your do currently, but also check that only public
methods are found
- Convert them to MethodHandle using a public Lookup ({{Lookup.publicLookup()}}
with {{unreflectMethod}} on instantiation of the {{Cmd}} object
- At runtime only call {{invoke()}} (ideally {{invokeExact()}} with correctly
casted types, but that might not be possible with dynamic stuff). This then
gets inlined by Hotspot and will be faster, especially when APIs are invoked
all the time.
> CoreContainer level custom requesthandlers
> ------------------------------------------
>
> Key: SOLR-14404
> URL: https://issues.apache.org/jira/browse/SOLR-14404
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Priority: Major
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> caveats:
> * The class should be annotated with {{org.apache.solr.api.EndPoint}}.
> Which means only V2 APIs are supported
> * The path should have prefix {{/api/plugin}}
> add a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "full.ClassName"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> add a plugin from a package
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "pkgName:full.ClassName" ,
> "version: "1.0"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> remove a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "remove": "myplugin"
> }' http://localhost:8983/api/cluster/plugins
> {code}
> The configuration will be stored in the {{clusterprops.json}}
> as
> {code:java}
> {
> "plugins" : {
> "myplugin" : {"class": "full.ClassName" }
> }
> }
> {code}
> example plugin
> {code:java}
> public class MyPlugin {
> private final CoreContainer coreContainer;
> public MyPlugin(CoreContainer coreContainer) {
> this.coreContainer = coreContainer;
> }
> @EndPoint(path = "/myplugin/path1",
> method = METHOD.GET,
> permission = READ)
> public void call(SolrQueryRequest req, SolrQueryResponse rsp){
> rsp.add("myplugin.version", "2.0");
> }
> }
> {code}
> This plugin will be accessible on all nodes at {{/api/myplugin/path1}}. It's
> possible to add more methods at different paths. Ensure that all paths start
> with {{myplugin}} because that is the name in which the plugin is registered
> with. So {{/myplugin/path2}} , {{/myplugin/my/deeply/nested/path}} are all
> valid paths.
> It's possible that the user chooses to register the plugin with a different
> name. In that case , use a template variable as follows in paths
> {{$plugin-name/path1}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
