Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-2616

Include jdk14 logging configuration file

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.0-BETA, 6.0
    • Component/s: None
    • Labels:
      None

      Description

      The /example/ Jetty Solr configuration should include a basic logging configuration file. Looking at this wiki page: http://wiki.apache.org/solr/LoggingInDefaultJettySetup I am creating this patch.

      1. SOLR-2616_jdk14logging_setup.patch
        2 kB
        David Smiley
      2. SOLR-2616.patch
        2 kB
        Mark Miller

        Activity

        Hide
        markrmiller@gmail.com Mark Miller added a comment -

        Seems like a good idea - any objections?

        Show
        markrmiller@gmail.com Mark Miller added a comment - Seems like a good idea - any objections?
        Hide
        cmale Chris Male added a comment -

        +1

        Show
        cmale Chris Male added a comment - +1
        Hide
        billnbell Bill Bell added a comment -

        +1 please!!

        Show
        billnbell Bill Bell added a comment - +1 please!!
        Hide
        simonw Simon Willnauer added a comment -

        +1

        Show
        simonw Simon Willnauer added a comment - +1
        Hide
        markrmiller@gmail.com Mark Miller added a comment -

        So while I'm pro putting the logging config file in for easy use, I'm not so sure about wiring it up out of the box. Perhaps I'm just over used to things going to the console while starting/deving with Solr - but it has become something I've gotten used to

        I was thinking we just put the file there, and modify any doc to alert that you can also start Solr with a -D command to use the example logging config file.

        I could see going either way though.

        Thoughts?

        Show
        markrmiller@gmail.com Mark Miller added a comment - So while I'm pro putting the logging config file in for easy use, I'm not so sure about wiring it up out of the box. Perhaps I'm just over used to things going to the console while starting/deving with Solr - but it has become something I've gotten used to I was thinking we just put the file there, and modify any doc to alert that you can also start Solr with a -D command to use the example logging config file. I could see going either way though. Thoughts?
        Hide
        rcmuir Robert Muir added a comment -

        what will wiring it up out of box do to tests (e.g. example tests)?

        Will running the tests now cause jetty to create files outside of the build/ folder?

        Show
        rcmuir Robert Muir added a comment - what will wiring it up out of box do to tests (e.g. example tests)? Will running the tests now cause jetty to create files outside of the build/ folder?
        Hide
        markrmiller@gmail.com Mark Miller added a comment -

        It will be an issue with tests as is I believe, but nothing we couldn't work around.

        Show
        markrmiller@gmail.com Mark Miller added a comment - It will be an issue with tests as is I believe, but nothing we couldn't work around.
        Hide
        dsmiley David Smiley added a comment -

        The logging configuration file I provided does not log to a file nor does it suppress logging to the console. There is some commented configuration to make it easier to log to a file. The net perceived effect of applying this patch should be no change.

        Show
        dsmiley David Smiley added a comment - The logging configuration file I provided does not log to a file nor does it suppress logging to the console. There is some commented configuration to make it easier to log to a file. The net perceived effect of applying this patch should be no change.
        Hide
        markrmiller@gmail.com Mark Miller added a comment -

        The logging configuration file I provided does not log to a file nor does it suppress logging to the console.

        The question in my mind is not what the patch does, but what should we do.

        If we want this as an example that is not hooked up, my preference would be to let the user know he should use -D to hook up the sample log file - not configure it in jetty.xml - we should still stay somewhat logging framework agnostic.

        In both cases I would prefer that the default log.properties file use the FileHandler rather than ConsoleHandler though. We should give something close to what you actually might want to use - which is not to setup logging to log to the console.

        First I'm gathering feedback from others though.

        My current leaning is to doc the wiki and what not to mention the sample log props and use of -D to put it in action, and to setup the default log props to log to the ./logs dir.

        Show
        markrmiller@gmail.com Mark Miller added a comment - The logging configuration file I provided does not log to a file nor does it suppress logging to the console. The question in my mind is not what the patch does, but what should we do. If we want this as an example that is not hooked up, my preference would be to let the user know he should use -D to hook up the sample log file - not configure it in jetty.xml - we should still stay somewhat logging framework agnostic. In both cases I would prefer that the default log.properties file use the FileHandler rather than ConsoleHandler though. We should give something close to what you actually might want to use - which is not to setup logging to log to the console. First I'm gathering feedback from others though. My current leaning is to doc the wiki and what not to mention the sample log props and use of -D to put it in action, and to setup the default log props to log to the ./logs dir.
        Hide
        dsmiley David Smiley added a comment -

        Ok.

        The main thing I wanted to accomplish in this patch, was to make it easy for me to enable debug logging for a particular logger and to actually see the results. Before this patch, the current state, I could use the logging admin page to enable debug logging for a known Solr logger but the debug output wouldn't go anywhere because the default threshold for the console logger is INFO. This patch includes a commented line to lower the console threshold.

        FYI I still hate JDK14 logging (aka JUL); but nonetheless it's the default as provided with Solr.

        Show
        dsmiley David Smiley added a comment - Ok. The main thing I wanted to accomplish in this patch, was to make it easy for me to enable debug logging for a particular logger and to actually see the results. Before this patch, the current state, I could use the logging admin page to enable debug logging for a known Solr logger but the debug output wouldn't go anywhere because the default threshold for the console logger is INFO. This patch includes a commented line to lower the console threshold. FYI I still hate JDK14 logging (aka JUL); but nonetheless it's the default as provided with Solr.
        Hide
        rcmuir Robert Muir added a comment -

        My current leaning is to doc the wiki and what not to mention the sample log props and use of -D to put it in action, and to setup the default log props to log to the ./logs dir.

        yeah as long as we dont somehow create test meddling, I'm happy! There is already some hacks in the build somehow related to this:

        in lucene/common-build.xml: <property name="tests.loggingfile" value="/dev/null"/>
        and in the JUnitResultFormatter to reboot logging for each test case: 
         try {
              LogManager.getLogManager().readConfiguration();
            } catch (Exception e) {}
        
        Show
        rcmuir Robert Muir added a comment - My current leaning is to doc the wiki and what not to mention the sample log props and use of -D to put it in action, and to setup the default log props to log to the ./logs dir. yeah as long as we dont somehow create test meddling, I'm happy! There is already some hacks in the build somehow related to this: in lucene/common-build.xml: <property name="tests.loggingfile" value="/dev/null"/> and in the JUnitResultFormatter to reboot logging for each test case: try { LogManager.getLogManager().readConfiguration(); } catch (Exception e) {}
        Hide
        yseeley@gmail.com Yonik Seeley added a comment -

        My current leaning is to doc the wiki and what not to mention the sample log props and use of -D to put it in action, and to setup the default log props to log to the ./logs dir.

        That's a good plan I think. It does seem important for newbies to get the instant console feedback of "address already in use" or other exceptions. I actually find it pretty useful myself (when I forget that I already have an instance running, or just for seeing requests come in by default, etc).

        We can also document it right in the example/README.txt!

        Show
        yseeley@gmail.com Yonik Seeley added a comment - My current leaning is to doc the wiki and what not to mention the sample log props and use of -D to put it in action, and to setup the default log props to log to the ./logs dir. That's a good plan I think. It does seem important for newbies to get the instant console feedback of "address already in use" or other exceptions. I actually find it pretty useful myself (when I forget that I already have an instance running, or just for seeing requests come in by default, etc). We can also document it right in the example/README.txt!
        Hide
        dsmiley David Smiley added a comment -

        It's been a while with no activity so I just want to agree with Mark's proposal:

        • Don't wire up the log file by default
        • Include a log file that logs to files.
        • Add to documentation.

        I think the provided config file should log to the console at INFO threshold, and log to files at DEBUG threshold (or "finer" or whatever JUL calls it) – these are defaults, I believe any way. There will be no changes to default categories and so nothing will actually log at these detailed levels until they are changed by the user. I also think there should be a prominent notice on the logging jsp page to tell users they are not going to see the more detailed log levels in Solr's default setup without making changes to the logging configuration.

        Show
        dsmiley David Smiley added a comment - It's been a while with no activity so I just want to agree with Mark's proposal: Don't wire up the log file by default Include a log file that logs to files. Add to documentation. I think the provided config file should log to the console at INFO threshold, and log to files at DEBUG threshold (or "finer" or whatever JUL calls it) – these are defaults, I believe any way. There will be no changes to default categories and so nothing will actually log at these detailed levels until they are changed by the user. I also think there should be a prominent notice on the logging jsp page to tell users they are not going to see the more detailed log levels in Solr's default setup without making changes to the logging configuration.
        Hide
        rcmuir Robert Muir added a comment -

        3.4 -> 3.5

        Show
        rcmuir Robert Muir added a comment - 3.4 -> 3.5
        Hide
        markrmiller@gmail.com Mark Miller added a comment -

        Sorry about the delay - I'm going to try to tackle this soon.

        Show
        markrmiller@gmail.com Mark Miller added a comment - Sorry about the delay - I'm going to try to tackle this soon.
        Hide
        markrmiller@gmail.com Mark Miller added a comment -

        Feel free to take this from me David. It has taken me to long to get to it.

        Show
        markrmiller@gmail.com Mark Miller added a comment - Feel free to take this from me David. It has taken me to long to get to it.
        Hide
        dsmiley David Smiley added a comment -

        Noted. I'll mentally ad this to my backlog

        Show
        dsmiley David Smiley added a comment - Noted. I'll mentally ad this to my backlog
        Hide
        markrmiller@gmail.com Mark Miller added a comment -

        I'll commit this one. Here is the patch - will commit soon.

        Show
        markrmiller@gmail.com Mark Miller added a comment - I'll commit this one. Here is the patch - will commit soon.
        Hide
        markrmiller@gmail.com Mark Miller added a comment -

        Committed - lets make further improvements in new issues.

        Show
        markrmiller@gmail.com Mark Miller added a comment - Committed - lets make further improvements in new issues.
        Hide
        hossman Hoss Man added a comment -

        hoss20120711-manual-post-40alpha-change

        Show
        hossman Hoss Man added a comment - hoss20120711-manual-post-40alpha-change

          People

          • Assignee:
            markrmiller@gmail.com Mark Miller
            Reporter:
            dsmiley David Smiley
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development