Solr
  1. Solr
  2. SOLR-2459

Implement LogLevelSelection as a RequestHandler

    Details

    • Type: Wish Wish
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.0-ALPHA
    • Component/s: web gui
    • Labels:
      None

      Description

      The current available Output of the LogLevelSelection Servlet is plain HTML, which made it unpossible, to integrate the Logging-Information in the new Admin-UI. Format-Agnostic Output (like every [?] other Servlet offers) would be really nice!

      Just as an Idea for a future structure, the new admin-ui is actually based on that json-structure

      1. SOLR-2459-LogLevel.patch
        15 kB
        Ryan McKinley
      2. SOLR-2459-LogLevel.patch
        15 kB
        Ryan McKinley
      3. sample-output.json
        5 kB
        Upayavira
      4. sample-output.xml
        6 kB
        Upayavira
      5. LogLevelHandler.patch
        16 kB
        Upayavira

        Issue Links

          Activity

          Hide
          Stefan Matheis (steffkes) added a comment -

          Ryan, i guess we can close this, do we?

          Show
          Stefan Matheis (steffkes) added a comment - Ryan, i guess we can close this, do we?
          Hide
          Erick Erickson added a comment -

          Ryan:

          Can we close this JIRA? Or are there additional issues pending?

          Show
          Erick Erickson added a comment - Ryan: Can we close this JIRA? Or are there additional issues pending?
          Hide
          Ryan McKinley added a comment -

          Added in revision: 1292617

          Lets keep the existing servlet in place until the admin UI works

          Show
          Ryan McKinley added a comment - Added in revision: 1292617 Lets keep the existing servlet in place until the admin UI works
          Hide
          Ryan McKinley added a comment -

          An updated/simplified generic version that uses the SolrTestCaseJ4

          The format is different, but seems to match the JS needs better.

          I will commit this soon so the UI stuff can continue in a different issue

          Show
          Ryan McKinley added a comment - An updated/simplified generic version that uses the SolrTestCaseJ4 The format is different, but seems to match the JS needs better. I will commit this soon so the UI stuff can continue in a different issue
          Hide
          Ryan McKinley added a comment -

          updating patch to trunk.

          I will now try to generalize it so that it could have a Log4J (or whatever) backend

          Show
          Ryan McKinley added a comment - updating patch to trunk. I will now try to generalize it so that it could have a Log4J (or whatever) backend
          Hide
          Upayavira added a comment -

          Stefan - with set=, you can do multiples, so set=foo:INFO&set=bar:FINEST&set=baz:FINE The patch as it stands supports that.

          unset=true comes about when the logging system reports a category, but no value ( or null). So the logging system knows about it, but doesn't have a setting. My understanding is that this is where 'effective level' kicks in, that's the one that'll be used.

          Show
          Upayavira added a comment - Stefan - with set=, you can do multiples, so set=foo:INFO&set=bar:FINEST&set=baz:FINE The patch as it stands supports that. unset=true comes about when the logging system reports a category, but no value ( or null). So the logging system knows about it, but doesn't have a setting. My understanding is that this is where 'effective level' kicks in, that's the one that'll be used.
          Hide
          Stefan Matheis (steffkes) added a comment -

          Stefan - I'm trying to make a decent public API that is consistent with the rest of Solr. Sorry if that makes it harder for you!!

          That's okay .. instead of using one command, i have to combine a few .. but everything is better then now ;>

          I've included an XML and a JSON sample output.

          Nice! Just thought about the following things:

          • Is unset really a valid Level? It's more a command to remove a active Logger, no?
          • unset=true (inside the <loggers>-tag) shows that this logger has no specific setting, right? if so, perhaps just drop this out and only have the effective.level info?
          Show
          Stefan Matheis (steffkes) added a comment - Stefan - I'm trying to make a decent public API that is consistent with the rest of Solr. Sorry if that makes it harder for you!! That's okay .. instead of using one command, i have to combine a few .. but everything is better then now ;> I've included an XML and a JSON sample output. Nice! Just thought about the following things: Is unset really a valid Level? It's more a command to remove a active Logger, no? unset=true (inside the <loggers>-tag) shows that this logger has no specific setting, right? if so, perhaps just drop this out and only have the effective.level info?
          Hide
          Upayavira added a comment -

          Here's a first pass at the handler. I'm sure the output format is wrong, but the (limited) tests pass (it changes a value, then puts it back).

          I've included an XML and a JSON sample output.

          Is this more or less what we're after?

          Show
          Upayavira added a comment - Here's a first pass at the handler. I'm sure the output format is wrong, but the (limited) tests pass (it changes a value, then puts it back). I've included an XML and a JSON sample output. Is this more or less what we're after?
          Hide
          Upayavira added a comment -

          Ryan - that could work, and it makes it clear that it is an 'action'.

          Stefan - I'm trying to make a decent public API that is consistent with the rest of Solr. Sorry if that makes it harder for you!!

          Show
          Upayavira added a comment - Ryan - that could work, and it makes it clear that it is an 'action'. Stefan - I'm trying to make a decent public API that is consistent with the rest of Solr. Sorry if that makes it harder for you!!
          Hide
          Ryan McKinley added a comment -

          what about somethign like:

          /admin/logging?set=category.org.apache.solr.core.JmxMonitoredMap:INFO
          

          and setting multiple items with:

          /admin/logging?set=category.org.apache.solr.core.JmxMonitoredMap:INFO&set=category.org.apache.solr.update.UpdateHandler:FINEST
          

          This could work better on the server side then having to iterate though all the parameters and checking if they are relevant.

          Show
          Ryan McKinley added a comment - what about somethign like: /admin/logging?set=category.org.apache.solr.core.JmxMonitoredMap:INFO and setting multiple items with: /admin/logging?set=category.org.apache.solr.core.JmxMonitoredMap:INFO&set=category.org.apache.solr.update.UpdateHandler:FINEST This could work better on the server side then having to iterate though all the parameters and checking if they are relevant.
          Hide
          Stefan Matheis (steffkes) added a comment -

          Perhaps it could be:
          logging.category=org.apache.org.solr.core.JmxMonitoredMap
          logging.level=INFO

          What would really mean, that we can just update one Logger (per Step) – changing five of them will result in: click, change; save, click, change, save; click, change, save .. and so on? We could "autosave" every change instantly, but that's something we don't have anywhere else yet - so i guess users were wondering about that behaviour?

          Or, as an alternative:
          logging.category.org.apache.solr.core.JmxMonitoredMap=INFO
          logging.category.org.apache.solr.update.UpdateHandler=FINEST

          I'd implement both approaches - the latter might allow Stefan more flexibility in building a UI on top of it.

          It's of course possible, but it would be easier to have something like that:

          logging[category.org.apache.solr.core.JmxMonitoredMap]=INFO
          logging[category.org.apache.solr.update.UpdateHandler]=FINEST

          There it's possible to setup an initial Hashmap and just put all the Loggers into it. Or is that really difficult to handle on the Server-Side?

          Show
          Stefan Matheis (steffkes) added a comment - Perhaps it could be: logging.category=org.apache.org.solr.core.JmxMonitoredMap logging.level=INFO What would really mean, that we can just update one Logger (per Step) – changing five of them will result in: click, change; save, click, change, save; click, change, save .. and so on? We could "autosave" every change instantly, but that's something we don't have anywhere else yet - so i guess users were wondering about that behaviour? Or, as an alternative: logging.category.org.apache.solr.core.JmxMonitoredMap=INFO logging.category.org.apache.solr.update.UpdateHandler=FINEST I'd implement both approaches - the latter might allow Stefan more flexibility in building a UI on top of it. It's of course possible, but it would be easier to have something like that: logging[category.org.apache.solr.core.JmxMonitoredMap]=INFO logging[category.org.apache.solr.update.UpdateHandler]=FINEST There it's possible to setup an initial Hashmap and just put all the Loggers into it. Or is that really difficult to handle on the Server-Side?
          Hide
          Ryan McKinley added a comment -

          great – my comment about supporting log4j is just to keep it in mind. Sometimes its easier to think about the abstraction earlier, but we can obviously tackle that in a follow on issue.

          Show
          Ryan McKinley added a comment - great – my comment about supporting log4j is just to keep it in mind. Sometimes its easier to think about the abstraction earlier, but we can obviously tackle that in a follow on issue.
          Hide
          Upayavira added a comment -

          Ryan,

          I'd implement both approaches - the latter might allow Stefan more flexibility in building a UI on top of it. (in fact, I have both coded, now looking at test cases).

          At present, this is intentionally a rewrite of the LogLevelSelection servlet, which only works with JDK logging. I'm just plagiarising the logging code from there.

          If we want to be more clever, and work with other frameworks, I'm up for it, but it is extending the scope somewhat!

          Show
          Upayavira added a comment - Ryan, I'd implement both approaches - the latter might allow Stefan more flexibility in building a UI on top of it. (in fact, I have both coded, now looking at test cases). At present, this is intentionally a rewrite of the LogLevelSelection servlet, which only works with JDK logging. I'm just plagiarising the logging code from there. If we want to be more clever, and work with other frameworks, I'm up for it, but it is extending the scope somewhat!
          Hide
          Ryan McKinley added a comment -

          I like:

          logging.category=org.apache.org.solr.core.JmxMonitoredMap

          logging.level=INFO

          As for actually updating the logging value.... what is the plan for supporting various logging providers like Log4j? The handler gets initialized with the logging framework and it takes care of translating the levels (FINEST == TRACE etc)?

          Show
          Ryan McKinley added a comment - I like: logging.category=org.apache.org.solr.core.JmxMonitoredMap logging.level=INFO As for actually updating the logging value.... what is the plan for supporting various logging providers like Log4j? The handler gets initialized with the logging framework and it takes care of translating the levels (FINEST == TRACE etc)?
          Hide
          Upayavira added a comment -

          As far as a Handler is concerned, it is just a list of key/value pairs, regardless of whether POSTed or in the URL of a GET. (at least, that is my current understanding).

          Perhaps it could be:

          logging.category=org.apache.org.solr.core.JmxMonitoredMap
          logging.level=INFO

          Or, as an alternative:

          logging.category.org.apache.solr.core.JmxMonitoredMap=INFO
          logging.category.org.apache.solr.update.UpdateHandler=FINEST

          Either would be acceptable.

          Show
          Upayavira added a comment - As far as a Handler is concerned, it is just a list of key/value pairs, regardless of whether POSTed or in the URL of a GET. (at least, that is my current understanding). Perhaps it could be: logging.category=org.apache.org.solr.core.JmxMonitoredMap logging.level=INFO Or, as an alternative: logging.category.org.apache.solr.core.JmxMonitoredMap=INFO logging.category.org.apache.solr.update.UpdateHandler=FINEST Either would be acceptable.
          Hide
          Stefan Matheis (steffkes) added a comment -

          Well, Solr doesn't distinguish between GET and POST in its handlers as far as I can see, so either would work.

          Ah okay .. good to know!

          If by POST you mean that you would post some XML or JSON to it, and it would use that, that could be done (don't know how hard it is to accept JSON, but could look into it).

          No, not really - just POSTing the Params and don't append them to the url; because some older browser has low restrictions to the length of an url – and while using POST the size/amount of data does not matter. i think there is no need to support xml/json here, the data is plain key/value .. it's enough :>

          Show
          Stefan Matheis (steffkes) added a comment - Well, Solr doesn't distinguish between GET and POST in its handlers as far as I can see, so either would work. Ah okay .. good to know! If by POST you mean that you would post some XML or JSON to it, and it would use that, that could be done (don't know how hard it is to accept JSON, but could look into it). No, not really - just POSTing the Params and don't append them to the url; because some older browser has low restrictions to the length of an url – and while using POST the size/amount of data does not matter. i think there is no need to support xml/json here, the data is plain key/value .. it's enough :>
          Hide
          Upayavira added a comment -

          Well, Solr doesn't distinguish between GET and POST in its handlers as far as I can see, so either would work.

          If by POST you mean that you would post some XML or JSON to it, and it would use that, that could be done (don't know how hard it is to accept JSON, but could look into it).

          Upayavira

          Show
          Upayavira added a comment - Well, Solr doesn't distinguish between GET and POST in its handlers as far as I can see, so either would work. If by POST you mean that you would post some XML or JSON to it, and it would use that, that could be done (don't know how hard it is to accept JSON, but could look into it). Upayavira
          Hide
          Stefan Matheis (steffkes) added a comment -

          Upayavira,

          thanks for having a look into this!

          Thoughts?

          Yes, just a simple one – GET for requesting Data and POST for changing them, please

          The biggest question is whether to allow multiple settings to be changed in one request. The current LogLevelSelection servlet allows you to change them all in one single hit. However, allowing this in a new Handler would, in my opinion, give rise to an ugly API.

          Don't know much about the handling of arrays in java .. in php it's pretty easy? For the Interface it would be okay to generate such an structure for an HTTP-Request:

          logging[org.apache.solr.core.JmxMonitoredMap]=INFO&logging[org.apache.solr.update.UpdateHandler]=FINEST

          Given that Information you could loop over it, and set every Logger at the specified Level. Of course we need to define how we could reset/delete a Loggers-Setting ..

          Stefan

          Show
          Stefan Matheis (steffkes) added a comment - Upayavira, thanks for having a look into this! Thoughts? Yes, just a simple one – GET for requesting Data and POST for changing them, please The biggest question is whether to allow multiple settings to be changed in one request. The current LogLevelSelection servlet allows you to change them all in one single hit. However, allowing this in a new Handler would, in my opinion, give rise to an ugly API. Don't know much about the handling of arrays in java .. in php it's pretty easy? For the Interface it would be okay to generate such an structure for an HTTP-Request: logging[org.apache.solr.core.JmxMonitoredMap]=INFO&logging[org.apache.solr.update.UpdateHandler]=FINEST Given that Information you could loop over it, and set every Logger at the specified Level. Of course we need to define how we could reset/delete a Loggers-Setting .. Stefan
          Hide
          Upayavira added a comment -

          So, slf4j is a facade, and it looks like Solr uses JDK logging behind that. I'm assuming this is correct.

          It seems that the best way to do this is to replace the LogLevelSelection servlet with a Handler.

          Coding a handler to display current settings is easy, and I've already done it. However, to code the update side, requires a decision on suitable request parameters.

          The biggest question is whether to allow multiple settings to be changed in one request. The current LogLevelSelection servlet allows you to change them all in one single hit. However, allowing this in a new Handler would, in my opinion, give rise to an ugly API. Therefore, I suggest that:

          http://localhost:8983/solr/admin/logging <- would display current settings
          http://localhost:8983/solr/admin/logging?category=core&level=FINE <- would change a single value

          This latter would probably output the same as the previous, but perhaps with an 'updated' attribute set to true on that category.

          Given the ajax nature of the new UI, I suspect this would be enough for it to work with.

          Thoughts?

          Show
          Upayavira added a comment - So, slf4j is a facade, and it looks like Solr uses JDK logging behind that. I'm assuming this is correct. It seems that the best way to do this is to replace the LogLevelSelection servlet with a Handler. Coding a handler to display current settings is easy, and I've already done it. However, to code the update side, requires a decision on suitable request parameters. The biggest question is whether to allow multiple settings to be changed in one request. The current LogLevelSelection servlet allows you to change them all in one single hit. However, allowing this in a new Handler would, in my opinion, give rise to an ugly API. Therefore, I suggest that: http://localhost:8983/solr/admin/logging <- would display current settings http://localhost:8983/solr/admin/logging?category=core&level=FINE <- would change a single value This latter would probably output the same as the previous, but perhaps with an 'updated' attribute set to true on that category. Given the ajax nature of the new UI, I suspect this would be enough for it to work with. Thoughts?

            People

            • Assignee:
              Ryan McKinley
              Reporter:
              Stefan Matheis (steffkes)
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development