[ 
https://issues.apache.org/jira/browse/SOLR-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700424#action_12700424
 ] 

Noble Paul commented on SOLR-1106:
----------------------------------

to hoss' comment on the list http://markmail.org/message/s7mcbtaskngr74bd

The commands such as create/load/unload etc can only be done by the 
CoreAdminHandler. So it is not really possible to achieve this as a 
RequestHandler. Take our usecase where we start with a blank slate ( zero 
cores) and we keep adding cores . In this case there is no core in the first  
place to attach a RequestHandler 

bq.we might end up adding one more method to be overridden. Let me know what 
you feel about this. 

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

> 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
>
>   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.

Reply via email to