[
https://issues.apache.org/jira/browse/SOLR-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700809#action_12700809
]
Kay Kay commented on SOLR-1106:
-------------------------------
| As I see it , there will be very few users overriding the CoreAdminHandler .
We do it and we have a custom build of Solr for that. With this issue fixed I
may be able to plugin my custom CoreAdminHandler. having 7 -8 methods to be
overridden is a good idea. If there are new commands we may have new methods
I have to disagree with the suggestions of overriding 7 - 8 method as a good
idea here. Also - it seems ironical to me that you have a commit privilege to
solr and have a custom build too ( as opposed to a pluggable library to solr )
since given the right hooks available - it can prevent forking of the code and
useful to others in the community as well.
The point of my longer exercise of submitting a patch to get it committed is to
prevent forking , even though it is tempting in terms of time to do it
otherwise.
Having put the reasons- here is the revised patch with individual methods
being overridden as separate methods .
> Pluggable CoreAdminHandler (Action ) architecture that allows for custom
> handler access to CoreContainer / request-response
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-1106
> URL: https://issues.apache.org/jira/browse/SOLR-1106
> Project: Solr
> Issue Type: New Feature
> Environment: Java 5, Tomcat 6
> Reporter: Kay Kay
> Attachments: SOLR-1106.patch, SOLR-1106.patch, SOLR-1106.patch,
> SOLR-1106.patch
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Currently there are certain default actions implemented in CoreAdminHandler (
> CREATE , SWAP, RELOAD , ALIAS etc.) .
> For the purpose of in-house monitoring tools that needs to interact with
> multiple cores at a given solr instance - we need custom handlers that has
> access to CoreContainer and the req, resp of the same.
> So - the proposed way of injecting handlers is as follows.
> In solr.xml - we add a new schema -
> <solr >
> <cores adminPath="/cores/admin">
>
> <adminActionHandler action="newaction"
> handlerType="com.mydomain.myclass" />
> </cores>
> </solr>
> New abstract class - CoreAdminActionRequestHandler added - that
> com.mydomain.myclass would need to inherit from.
> Following action handlers registered by default -
> registerCustomAdminHandler("create", new
> AdminCreateActionRequestHandler());
> registerCustomAdminHandler("rename", new
> AdminRenameActionRequestHandler());
> registerCustomAdminHandler("alias", new AdminAliasActionRequestHandler());
> registerCustomAdminHandler("unload", new
> AdminUnloadActionRequestHandler());
> registerCustomAdminHandler("status", new
> AdminStatusActionRequestHandler());
> registerCustomAdminHandler("persist", new
> AdminPersistActionRequestHandler());
> registerCustomAdminHandler("reload", new
> AdminReloadActionRequestHandler());
> registerCustomAdminHandler("swap", new AdminSwapActionRequestHandler());
> Trying to register a handler with one that already exists would result in an
> error ( Hence - the above mentioned defaults would not be overridden).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
