[jira] [Commented] (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:comment-tabpanel&focusedCommentId=13539145#comment-13539145
]
Stefan Matheis (steffkes) commented on SOLR-4220:
-
ah .. hm, but perhaps the first idea is not always the best. at the start of
the UI, we're already fetching global core-state information from
{{/admin/cores}} so, if we include the information there .. we can avoid single
requests for the others pages *some lights show up here*
so maybe we'll have a need for some "reload data" buttons on the page, to offer
the possibility to refresh the data, but that should be okay.
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=13539144#comment-13539144
]
Stefan Matheis (steffkes) commented on SOLR-4220:
-
bq. but also be called from the CoreAdminHandler via the STATUS action so that
the UI could make a single call to get all the info about the list of cores and
non-core specific data.
i just gave it a quick thought, but ... the first thing that came to my mind
was .. if we have it all at one request, it must be maintained via a global
state in the UI :?
if we can (and from your description, it sounds like we do) i'd like to stay
with separate requests for those pages - but of course, more possibilites are
normally better than less :)
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=13537411#comment-13537411
]
Hoss Man commented on SOLR-4220:
What i had in mind at apachecon was to refactor all the "non-core specific"
logic that the UI currently used into helper methods which could continue to be
called from the existing RequestHandlers (so existing clinets can continue to
use them the same way, and they can continue to be used with custom response
writers and configured defaults/invariants) but also be called from the
CoreAdminHandler via the STATUS action so that the UI could make a single call
to get all the info about the list of cores and non-core specific data.
I hadn't really thought about hte logging stuff -- but everything else would
definitely make sense in hte context of asking CoreAdminHandler for status
STATUS.
bq. CoreAdminHandler should not be configured and routed under core - it should
be at the CoreContainer level.
I don't understand this comment ... CoreAdminHandler is already configured in
solr.xml and managed directly by the CoreContainer, it's not core specific.
This is just a question of accessing hte other "admin" type handlers that
return data that's got nothing to do with a single SolrCore (ie: system
properties, thread dumps, etc...)
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=13536331#comment-13536331
]
Mark Miller commented on SOLR-4220:
---
+1 - Im very interested in this as well. CoreAdminHandler should not be
configured and routed under core - it should be at the CoreContainer level.
This would be a huge improvement.
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
