These custom action handlers need not be residing in solr . Hence I needed a
hook ( listener ) that they can register themselves with and be loaded by
the SolrResourceLoader ( ./lib/*.jar ) . Also I believe the default
handlers are very useful , necessary and mandatory and hence ported them to
the listener for consistency purposes.
Also - if we have a protected method called invokeCommand() - how do we
inject that type as the admin handler ( as opposed to CoreAdminHandler) .
Right now - the type information seems hardcoded in CoreContainer though.
// ---------------- Multicore self related methods ---------------
/**
* Creates a CoreAdminHandler for this MultiCore.
* @return a CoreAdminHandler
*/
protected CoreAdminHandler createMultiCoreHandler() {
return new CoreAdminHandler() {
@Override
public CoreContainer getCoreContainer() {
return CoreContainer.this;
}
};
}
2009/4/13 Noble Paul നോബിള് नोब्ळ् <noble.p...@gmail.com>
> Hi Kay,
>
> The idea of one handler per command looks like an overkill. How about
> having a protected methods for all the known commands and have a
> separate method invokeCommand() which can choose to implement any
> extra commands if need be. This way the changes needed would be
> minimal.
>
> On Mon, Apr 13, 2009 at 8:53 PM, Kay Kay <kaykay.uni...@gmail.com> wrote:
> > For one of our projects - we need custom admin monitoring hooks that gets
> > access to multiple cores for a given solr web app (through the
> CoreContainer
> > interface).
> >
> > There are common admin handler commands with the actions - register /
> swap /
> > load etc. that seem to be available by default.
> >
> > I have submitted a patch to add custom admin handlers , against custom
> > actions ( that also refactors the existing action handlers that are
> > available by default as well ).
> >
> > This would be useful to extend the handlers that need access to multiple
> > cores. Just curious if this is something that could be looked into .
> > Thanks.
> >
>
>
>
> --
> --Noble Paul
>
