Solr
  1. Solr
  2. SOLR-554

Hierarchical JDK log level selector for SOLR Admin

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.3
    • Component/s: web gui
    • Labels:
      None

      Description

      An admin web page to allow displaying and setting the log level of hierarchical loggers from the UI at runtime. The existing logging.jsp only sets and displays the root log level.

      1. SOLR-554-screenshot-3.jpg
        215 kB
        Sean Timm
      2. SOLR-554.patch
        11 kB
        Sean Timm
      3. SOLR-554.patch
        11 kB
        Sean Timm
      4. SOLR-554.patch
        11 kB
        Sean Timm
      5. LogLevelSelection.java
        9 kB
        Sean Timm

        Issue Links

          Activity

          Hide
          Sean Timm added a comment -

          Here is an implementation written in a servlet. To configure, add

          <servlet>
                  <servlet-name>Logging</servlet-name>
                  <servlet-class>org.apache.solr.servlet.LogLevelSelection</servlet-class>
          </servlet>
          
          <servlet-mapping>
                  <servlet-name>Logging</servlet-name>
                  <url-pattern>/admin/logging</url-pattern>
          </servlet-mapping>
          

          to the web.xml configuration.

          It doesn't have the same look and feel of the rest of the admin UI, but I did throw in a link to the Solr logo.

          This is adapted from a former co-workers implementation for an AOL internal framework using Log4j.

          Show
          Sean Timm added a comment - Here is an implementation written in a servlet. To configure, add <servlet> <servlet-name> Logging </servlet-name> <servlet-class> org.apache.solr.servlet.LogLevelSelection </servlet-class> </servlet> <servlet-mapping> <servlet-name> Logging </servlet-name> <url-pattern> /admin/logging </url-pattern> </servlet-mapping> to the web.xml configuration. It doesn't have the same look and feel of the rest of the admin UI, but I did throw in a link to the Solr logo. This is adapted from a former co-workers implementation for an AOL internal framework using Log4j.
          Hide
          Otis Gospodnetic added a comment -

          Didn't try this, so I don't know what this looks like from a L&F perspective, but you mention L&F not being like the rest of Admin – any chance of somebody giving this some L&F love? If that happens, we could probably get that in 1.3.

          Show
          Otis Gospodnetic added a comment - Didn't try this, so I don't know what this looks like from a L&F perspective, but you mention L&F not being like the rest of Admin – any chance of somebody giving this some L&F love? If that happens, we could probably get that in 1.3.
          Hide
          Sean Timm added a comment -

          L&F screenshot

          Show
          Sean Timm added a comment - L&F screenshot
          Hide
          Sean Timm added a comment -

          Patch format this time. Added using the solr-admin.css to help the L&F. Includes mods to web.xml and admin/index.jsp to load this servlet instead of the logging.jsp.

          Show
          Sean Timm added a comment - Patch format this time. Added using the solr-admin.css to help the L&F. Includes mods to web.xml and admin/index.jsp to load this servlet instead of the logging.jsp.
          Hide
          Sean Timm added a comment -

          Minor L&F improvement.

          Show
          Sean Timm added a comment - Minor L&F improvement.
          Hide
          Sean Timm added a comment -

          L&F screenshot

          Show
          Sean Timm added a comment - L&F screenshot
          Hide
          Sean Timm added a comment -

          It was pointed out to me that the logo was not positioned the same as the other admin pages. This should be better.

          Show
          Sean Timm added a comment - It was pointed out to me that the logo was not positioned the same as the other admin pages. This should be better.
          Hide
          Sean Timm added a comment -

          Better logo positioning.

          Show
          Sean Timm added a comment - Better logo positioning.
          Hide
          Otis Gospodnetic added a comment -

          This looks very good to me. I never used the admin log page's functionality. Does clicking "set" actually generate the correct log config file (and it overwrites the old one)?

          Show
          Otis Gospodnetic added a comment - This looks very good to me. I never used the admin log page's functionality. Does clicking "set" actually generate the correct log config file (and it overwrites the old one)?
          Hide
          Sean Timm added a comment -

          No, like the existing logging.jsp, it doesn't touch the configuration file. When the server is bounced, the log levels revert back to those in the config file.

          Show
          Sean Timm added a comment - No, like the existing logging.jsp, it doesn't touch the configuration file. When the server is bounced, the log levels revert back to those in the config file.
          Hide
          Hoss Man added a comment -

          While i'm personally a fan of JDK Logging, it does seem that in the "medium" future, Solr will be moving to to SLF4J, so I have to question the wisdom of enhancing/improving a JDK Logging specific page in the Solr Admin UI.

          I suppose even if/when we use SLF4J, JDK Logging will be the default, and people will have to physically remove the "adapter" jar from the solr.war to use something else (at which time they could also remove this servlet registration and delete the link) ... but still, i just wanted to point out it's something we should think about.

          If nothing else, perhaps we could make the admin/index.jsp only generate a link to /admin/logging if it can tell a servlet is registered to that path? ... or we could just worry about it later.

          Show
          Hoss Man added a comment - While i'm personally a fan of JDK Logging, it does seem that in the "medium" future, Solr will be moving to to SLF4J, so I have to question the wisdom of enhancing/improving a JDK Logging specific page in the Solr Admin UI. I suppose even if/when we use SLF4J, JDK Logging will be the default, and people will have to physically remove the "adapter" jar from the solr.war to use something else (at which time they could also remove this servlet registration and delete the link) ... but still, i just wanted to point out it's something we should think about. If nothing else, perhaps we could make the admin/index.jsp only generate a link to /admin/logging if it can tell a servlet is registered to that path? ... or we could just worry about it later.
          Hide
          Sean Timm added a comment -

          I'm not sure of the rationale, but SLF4J does not provide a way to change the logging levels, so the only way to do it is with the underlying logging system. I can provide a Log4j version as well if folks would find that useful.

          From the SLF4J FAQ: "SLF4J is only a facade, meaning that it does not provide a complete logging solution. Operations such as configuring appenders or setting logging levels cannot be performed with SLF4J. Thus, at some point in time, any non-trivial application will need to directly invoke the underlying logging system. In other words, complete independence from the API underlying logging system is not possible for a stand-alone application. Nevertheless, SLF4J reduces the impact of this dependence to near-painless levels."

          Show
          Sean Timm added a comment - I'm not sure of the rationale, but SLF4J does not provide a way to change the logging levels, so the only way to do it is with the underlying logging system. I can provide a Log4j version as well if folks would find that useful. From the SLF4J FAQ: "SLF4J is only a facade, meaning that it does not provide a complete logging solution. Operations such as configuring appenders or setting logging levels cannot be performed with SLF4J. Thus, at some point in time, any non-trivial application will need to directly invoke the underlying logging system. In other words, complete independence from the API underlying logging system is not possible for a stand-alone application. Nevertheless, SLF4J reduces the impact of this dependence to near-painless levels."
          Hide
          Otis Gospodnetic added a comment -

          My feeling is we should go ahead with this change for now (for 1.3) and it it becomes obsolete or needs changing later, for 1.4, we can deal with that then.

          I'm not assigning this to myself since I stayed out of the whole logging discussion, but I'm marking it for 1.3, so somebody will handle this one way or the other prior to 1.3.

          Show
          Otis Gospodnetic added a comment - My feeling is we should go ahead with this change for now (for 1.3) and it it becomes obsolete or needs changing later, for 1.4, we can deal with that then. I'm not assigning this to myself since I stayed out of the whole logging discussion, but I'm marking it for 1.3, so somebody will handle this one way or the other prior to 1.3.
          Hide
          David Smiley added a comment -

          This feature may be useful, but it doesn't strike me as something that belongs in any web application (Solr included). It strikes me as a feature that may or may not be there in your web server.

          Show
          David Smiley added a comment - This feature may be useful, but it doesn't strike me as something that belongs in any web application (Solr included). It strikes me as a feature that may or may not be there in your web server.
          Hide
          Shalin Shekhar Mangar added a comment -

          Sean – this looks great and it is certainly more useful than the current logging.jsp

          Is there a reason for not making this as a request handler? Currently, it displays all loggers available to it which also includes org.apache.catalina, ContainerBase and even javax.management.mbeanserver when running Solr under tomcat. It may be better to limit loggers to org.apache.solr by default. If this is made a request handler, we can configure the logger names it should support in solrconfig.xml and users can add packages of their custom solr plugins too. I'll see if I can find some time to make these changes.

          Thoughts?

          Show
          Shalin Shekhar Mangar added a comment - Sean – this looks great and it is certainly more useful than the current logging.jsp Is there a reason for not making this as a request handler? Currently, it displays all loggers available to it which also includes org.apache.catalina, ContainerBase and even javax.management.mbeanserver when running Solr under tomcat. It may be better to limit loggers to org.apache.solr by default. If this is made a request handler, we can configure the logger names it should support in solrconfig.xml and users can add packages of their custom solr plugins too. I'll see if I can find some time to make these changes. Thoughts?
          Hide
          Shalin Shekhar Mangar added a comment -

          On further thought, let's commit this for 1.3 and work on refactoring/enhancements if we can find time.

          Committed revision 682264.

          Thanks Sean!

          Show
          Shalin Shekhar Mangar added a comment - On further thought, let's commit this for 1.3 and work on refactoring/enhancements if we can find time. Committed revision 682264. Thanks Sean!
          Hide
          Sean Timm added a comment -

          There have been times that I've wanted to turn on logging for components outside of Solr. Since it is hierarchical and sorted alphabetically, I've never found it a problem to find the loggers that I am looking for. My preference would be to keep all of the available loggers in the table and keep the configuration to a minimum (right now the user does not need to configure anything).

          Show
          Sean Timm added a comment - There have been times that I've wanted to turn on logging for components outside of Solr. Since it is hierarchical and sorted alphabetically, I've never found it a problem to find the loggers that I am looking for. My preference would be to keep all of the available loggers in the table and keep the configuration to a minimum (right now the user does not need to configure anything).
          Hide
          Sean Timm added a comment -

          Found a bug. If a synthesized logger is set to OFF, the below exception is thrown.

          HTTP ERROR: 500
          
          INTERNAL_SERVER_ERROR
          
          RequestURI=/solr/admin/logging
          Caused by:
          
          java.lang.NullPointerException
          	at org.apache.solr.servlet.LogLevelSelection.doGet(LogLevelSelection.java:134)
          	at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
                  [...]
          

          The fix is to ensure that the Level returned from getEffectiveLevel is not null. If it is null, return Level.OFF.

            private Level getEffectiveLevel( Logger logger ) {
              Level level = logger.getLevel();
              for( Level l : LEVELS ) {
                if( level != null ) {
                  return level;
                }
                if( l == null ) { continue; }
                if( logger.isLoggable( l ) ) {
                  level = l;
                }
              }
              if( level == null ) {
                level = Level.OFF;
              }
              return level;
            }
          
          Show
          Sean Timm added a comment - Found a bug. If a synthesized logger is set to OFF, the below exception is thrown. HTTP ERROR: 500 INTERNAL_SERVER_ERROR RequestURI=/solr/admin/logging Caused by: java.lang.NullPointerException at org.apache.solr.servlet.LogLevelSelection.doGet(LogLevelSelection.java:134) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [...] The fix is to ensure that the Level returned from getEffectiveLevel is not null. If it is null, return Level.OFF. private Level getEffectiveLevel( Logger logger ) { Level level = logger.getLevel(); for ( Level l : LEVELS ) { if ( level != null ) { return level; } if ( l == null ) { continue ; } if ( logger.isLoggable( l ) ) { level = l; } } if ( level == null ) { level = Level.OFF; } return level; }
          Hide
          Shalin Shekhar Mangar added a comment -

          Committed revision 683672 with Sean's fix.

          Show
          Shalin Shekhar Mangar added a comment - Committed revision 683672 with Sean's fix.

            People

            • Assignee:
              Shalin Shekhar Mangar
              Reporter:
              Sean Timm
            • Votes:
              3 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development