[jira] Updated: (SOLR-1106) Pluggable CoreAdminHandler (Action ) architecture that allows for custom handler access to CoreContainer / request-response
[
https://issues.apache.org/jira/browse/SOLR-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-1106:
-
Attachment: SOLR-1106.patch
The adminhandler attribute must be persisted back to solr.xml
> 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
> Components: search
> Environment: Java 5, Tomcat 6
>Reporter: Kay Kay
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.4
>
> Attachments: SOLR-1106.patch, SOLR-1106.patch, 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 -
>
>
>
>handlerType="com.mydomain.myclass" />
>
>
> 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.
[jira] Updated: (SOLR-1106) Pluggable CoreAdminHandler (Action ) architecture that allows for custom handler access to CoreContainer / request-response
[
https://issues.apache.org/jira/browse/SOLR-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-1106:
Attachment: SOLR-1106.patch
Thanks Kay, this looks good.
I've made the following changes over your last patch
# Re-formatted code to Lucene/Solr coding style. I know this is frowned upon
for changes to existing code but CoreAdminHandler was the only place using a
non-standard style of brace positioning and variable names.
# Made the CoreContainer instance protected
# Removed the CoreContainer parameter to all the action methods since it is an
instance variable
# Removed the final keyword from variable/parameter definitions. That is just
noise in this context, isn't it?
I think this is ready to commit. I'll wait for a day for any feedback that
others may have.
> 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
> Components: search
> Environment: Java 5, Tomcat 6
>Reporter: Kay Kay
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.4
>
> Attachments: SOLR-1106.patch, 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 -
>
>
>
>handlerType="com.mydomain.myclass" />
>
>
> 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.
[jira] Updated: (SOLR-1106) Pluggable CoreAdminHandler (Action ) architecture that allows for custom handler access to CoreContainer / request-response
[
https://issues.apache.org/jira/browse/SOLR-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-1106:
Component/s: search
Fix Version/s: 1.4
Assignee: Shalin Shekhar Mangar
> 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
> Components: search
> Environment: Java 5, Tomcat 6
>Reporter: Kay Kay
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.4
>
> 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 -
>
>
>
>handlerType="com.mydomain.myclass" />
>
>
> 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.
[jira] Updated: (SOLR-1106) Pluggable CoreAdminHandler (Action ) architecture that allows for custom handler access to CoreContainer / request-response
[
https://issues.apache.org/jira/browse/SOLR-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kay Kay updated SOLR-1106:
--
Attachment: SOLR-1106.patch
> 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 -
>
>
>
>handlerType="com.mydomain.myclass" />
>
>
> 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.
[jira] Updated: (SOLR-1106) Pluggable CoreAdminHandler (Action ) architecture that allows for custom handler access to CoreContainer / request-response
[
https://issues.apache.org/jira/browse/SOLR-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kay Kay updated SOLR-1106:
--
Attachment: SOLR-1106.patch
CoreAdminHandler ( default ) instantiated without using reflection
> 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 -
>
>
>
>handlerType="com.mydomain.myclass" />
>
>
> 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.
[jira] Updated: (SOLR-1106) Pluggable CoreAdminHandler (Action ) architecture that allows for custom handler access to CoreContainer / request-response
[
https://issues.apache.org/jira/browse/SOLR-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kay Kay updated SOLR-1106:
--
Attachment: SOLR-1106.patch
Revised Patch with less drastic changes:
* New method added to SolrResourceLoader# newAdminHandlerInstance(final
CoreContainer coreContainer) to inject CoreContainer aware systems (ignoring
SolrCoreAware since at a container level in a multi-core system - SolrCoreAware
might not make sense)
* CoreAdminHandler#handleCustomAction(final CoreContainer cores, final
SolrQueryRequest req, final SolrQueryResponse rsp)
added to handle custom actions ( By default - it throws an exception
explaining that action is not valid ).
* CoreContainer :
solr/cores/@adminHandler added as an optional xml config parameter (
defaults to org.apache.solr.handler.admin.CoreAdminHandler ) as before.
> 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
>
> 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 -
>
>
>
>handlerType="com.mydomain.myclass" />
>
>
> 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.
[jira] Updated: (SOLR-1106) Pluggable CoreAdminHandler (Action ) architecture that allows for custom handler access to CoreContainer / request-response
[
https://issues.apache.org/jira/browse/SOLR-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kay Kay updated SOLR-1106:
--
Attachment: SOLR-1106.patch
Changes to CoreContainer ( inferring solr admin action handlers / loading them
).
Changes to CoreAdminHandler ( registering handlers )
New class - CoreAdminActionRequestHandler added ( that needs to be implemented
by the plugins )
Existing admin actions implemented as CoreAdminActionRequestHandlers.
> 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
>
> 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 -
>
>
>
>handlerType="com.mydomain.myclass" />
>
>
> 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.
[jira] Updated: (SOLR-1106) Pluggable CoreAdminHandler (Action ) architecture that allows for custom handler access to CoreContainer / request-response
[
https://issues.apache.org/jira/browse/SOLR-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kay Kay updated SOLR-1106:
--
Summary: Pluggable CoreAdminHandler (Action ) architecture that allows for
custom handler access to CoreContainer / request-response (was: Pluggable
CoreAdminHandler architecture that allows for custom handler access to
CoreContainer / request-response )
> 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
> 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 -
>
>
>
>handlerType="com.mydomain.myclass" />
>
>
> 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.
