[
https://issues.apache.org/jira/browse/SOLR-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-1428:
---------------------------
Attachment: SOLR-1428.patch
I thought this would be really easy to bang in the airport last week, and this
patch is the initial stub of my attempt: it just adds the neccessary interface
declarations and stub methods in the two parent classes -- before resolving all
of the actual classes should be updated with real names, descriptions, etc...)
but even with this patch i encountered a few problems...
* SolrInfoMBeanTest failes with this patch -- the test assumes it can
instantiate all classes it finds that are assignable to SolrInfoMBean, but this
fails for most of the ValueSourceParsers which are anonymous inner classes.
this is a test failure, and could either be accounted for in the test, or we
could make those ValueSOurceParsers real classes (the latter being my opinion
as a good idea anyway)
* the JSPs need to be updated to account for hte new Categories of
SolrInfoMBeans (this is some brittle code anyway, definitely good to fix or rip
out)
* the new SolrInfoMBeans aren't getting registered in the infoRegistry.
The first two are straight forward -- the last one confuses the hell out of me
-- the code exists in SolrResourceLoader to automaticly register any object it
instantiates that implements SolrInfoMBeans, but for some reason it doesn't
seem to be working. it seems like a symptom of a bigger problem that needs to
be investigated
> make ValueSourceParser and QParserPlugin implement SolrInfoMBean so people
> can use registry.jsp to see which ones are loaded
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-1428
> URL: https://issues.apache.org/jira/browse/SOLR-1428
> Project: Solr
> Issue Type: Improvement
> Reporter: Hoss Man
> Attachments: SOLR-1428.patch
>
>
> there are a lot of default QParserPlugins and ValueSourceParsers loaded by
> default in solr -- but there is no clear way to see which ones are loaded.
> if we made the abstract base classes implement SolrInfoMBean (with sane
> defaults for all the methods, or at the very least have them return strings
> like "INFO NOT AVAILABLE") then people could use the infoRegistry to see
> what's available -- both by default, and when they load their own.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
