You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Stefan Matheis (steffkes) (JIRA)" <ji...@apache.org> on 2012/12/19 20:05:12 UTC
[jira] [Updated] (SOLR-4220) Move RequestHandler for global
Information out of core-scope
[ https://issues.apache.org/jira/browse/SOLR-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Matheis (steffkes) updated SOLR-4220:
--------------------------------------------
Description:
Okay, the title perhaps wins no price right now .. but i don't have an better idea, i'm sorry - if you do, don't hesitate to update it!
What it's all about: SOLR-3633 was created because at the moment it's not possible to use the Admin UI w/o at least one core. The reason for that is, that some (as you might think) "global" Information - which the UI shows on the top-level (which doesn't require you selecting a core) - must be fetched from a core-related url, because that's how the solr routing works right now.
Hoss and I talked about that at the ApacheCon and he mentioned that this should not be that biggest change although we need to update the tests and ensure that the thing is still working, of course.
I checked the UI for having a list of Functions and their related urls:
* *Dashboard*
** solr/$first_core/admin/system?wt=json
* *Logging*
** /solr/$first_core/admin/logging?wt=json&since=N
* *Logging* / *Level*
** /solr/$first_core/admin/logging?wt=json
* *Java Properties*
** /solr/$first_core/admin/properties?wt=json
* *Threads*
** /solr/$first_core/admin/threads?wt=json
For the sake of simplicity, i'd suggest that we're just moving the complete handler (regarding their url) on level up to something like {{/solr/admin/..}} like we have it already for the zookeeper thing?
Regarding the contained content, i think we could (or perhaps should?) stick with the given information/content - only the Dashboard is not using all of the provided values, but just for the fact that we have no usage for prettified RAM-Usage numbers ...
Let me know if the Issue contains all required informations, otherwise i'll try to update it according to your questions :)
was:
Okay, the title perhaps wins no price right now .. but i don't have an better idea, i'm sorry - if you do, don't hesitate to update it!
What it's all about: SOLR-3633 was created because at the moment it's not possible to use the Admin UI w/o at least one core. The reason for that is, that some (as you might think) "global" Information - which the UI shows on the top-level (which doesn't require you selecting a core) - must be fetched from a core-related url, because that's how the solr routing works right now.
Hoss and I talked about that at the ApacheCon and he mentioned that this should not be that biggest change although we need to update the tests and ensure that the thing is still working, of course.
I checked the UI for having a list of Functions and their related urls:
* *Dashboard*
** solr/$first_core/admin/system?wt=json
* *Logging*
** /solr/$first_core/admin/logging?wt=json&since=N
* *Logging* / *Level*
** /solr/$first_core/admin/logging?wt=json
* *Java Properties*
** /solr/$first_core/admin/properties?wt=json
* *Threads*
** /solr/$first_core/admin/threads?wt=json
For the sake of simplicity, i'd suggest that we're just moving the complete handler (regarding their url) on level up to something like {{/solr/admin/..}} like we have it already for the zookeeper thing?
Regarding the contained content, i think we could (or perhaps should?) stick with the given information/content - only the Dashboard is not using all of the provided values, but just for the fact that we have no usage for prettified RAM-Usage numbers ...
Let me know if the Issue contains all required informations, otherwise i'll try to update it according to your questions :)
> Move RequestHandler for global Information out of core-scope
> ------------------------------------------------------------
>
> Key: SOLR-4220
> URL: https://issues.apache.org/jira/browse/SOLR-4220
> Project: Solr
> Issue Type: Improvement
> Components: web gui
> Reporter: Stefan Matheis (steffkes)
> Assignee: Hoss Man
>
> Okay, the title perhaps wins no price right now .. but i don't have an better idea, i'm sorry - if you do, don't hesitate to update it!
> What it's all about: SOLR-3633 was created because at the moment it's not possible to use the Admin UI w/o at least one core. The reason for that is, that some (as you might think) "global" Information - which the UI shows on the top-level (which doesn't require you selecting a core) - must be fetched from a core-related url, because that's how the solr routing works right now.
> Hoss and I talked about that at the ApacheCon and he mentioned that this should not be that biggest change although we need to update the tests and ensure that the thing is still working, of course.
> I checked the UI for having a list of Functions and their related urls:
> * *Dashboard*
> ** solr/$first_core/admin/system?wt=json
> * *Logging*
> ** /solr/$first_core/admin/logging?wt=json&since=N
> * *Logging* / *Level*
> ** /solr/$first_core/admin/logging?wt=json
> * *Java Properties*
> ** /solr/$first_core/admin/properties?wt=json
> * *Threads*
> ** /solr/$first_core/admin/threads?wt=json
> For the sake of simplicity, i'd suggest that we're just moving the complete handler (regarding their url) on level up to something like {{/solr/admin/..}} like we have it already for the zookeeper thing?
> Regarding the contained content, i think we could (or perhaps should?) stick with the given information/content - only the Dashboard is not using all of the provided values, but just for the fact that we have no usage for prettified RAM-Usage numbers ...
> Let me know if the Issue contains all required informations, otherwise i'll try to update it according to your questions :)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org