Using plugin.getLogger() for debug messages

Discussion in 'Plugin Development' started by desht, May 15, 2012.

Thread Status:
Not open for further replies.
  1. Offline

    desht

    So, we have a plugin.getLogger() method which gets us a plugin-specific logger with our plugin name nicely prepended. All well and good. Some other pertinent facts here:
    • The plugin logger has as its parent logger a common Bukkit logger used by all plugins (plugin.getServer().getLogger()) - see https://github.com/Bukkit/Bukkit/blob/master/src/main/java/org/bukkit/plugin/PluginLogger.java
    • The plugin logger has a log level of ALL, by default
    • The plugin logger has no handlers
    • All messages logged with plugin.getLogger().log() are propagated to the parent logger...
    • The parent logger (common to all plugins) has org.bukkit.craftbukkit.util.TerminalConsoleHandler and java.util.logging.FileHandler handlers (which write to the server console and server.log respectively)
    • The parent logger has a log level of INFO, by default
    So. The plugin logger works nicely if want to log messages at level INFO or higher (WARN/SEVERE), but what if I want to use it for FINE/FINER/FINEST? It propagates the messages to the parent handler, whose level is INFO, so they get dropped.

    Now I can always do plugin.getLogger().getParent().setLevel(), but that changes the log level in the common parent logger, i.e. affecting the logging of every plugin which uses plugin.getLogger(). Not good. I could also add my own handlers to my plugin logger, but that feels like a nasty hack (although I might have to go that way).

    Example code to use your own handlers:
    PHP:
    // this works well, but feels... hackish
     
    Logger logger plugin.getLogger();
    // copy the common logger's two handlers
    for (Handler h logger.getParent().getHandlers()) {
      
    logger.addHandler(h);
    }
    // ensure that the common logger's handlers don't get used too
    logger.setUseParentHandlers(false);
    Any other suggestions?
     
    Joiner likes this.
  2. Offline

    LucasEmanuel

    Whats wrong with using info for debugging?
     
  3. Offline

    desht

    You're seriously asking that?
     
  4. Offline

    LucasEmanuel

    Wow take it easy. It was a simple question. Im sorry if my lesser intelligence offended you oh superior developer. Please let me return to the stone i appearently came from and I shall never disturb thy again.
     
  5. Offline

    desht

    Touchy much?

    OK, to elaborate on my admittedly short response before: no, INFO isn't really enough for debugging purposes. I want some FINE/FINER/FINEST logging at critical points in my plugins so that if someone hits a problem, I can ask them to set the log level of the plugin to one of the above levels, and send me the resulting log output. With the current plugin.getLogger() architecture, I can't really do that cleanly for reasons described above.
     
  6. Offline

    LucasEmanuel

    1. No, I just have a problem with people putting themselfs on high horses.

    2. You could easily do that with a side class in your plugin. Output it to textfiles or whatever in your pluginfolder with all the information you think would be important.

    But I do see why you would like it to be integrated in bukkit. It would be nice to just type logger.debug(debug info) and it would be output to the serverlog with a debug flag instead of info or higher.

    But still, having a boolean keeping track of debugstatus of your plugin and then use an if-else-statement to check whether or not to output debugging info to the log under info will still be an easier task then having to change the logger level of the entire server.
     
    TheKingElessar and Rasmase like this.
  7. Offline

    desht

    Well, the point of my question was to wonder why Bukkit even has a plugin.getLogger() to get a plugin-specific logger when it isn't actually that useful. I actually already do have a side class for one of my plugins (https://github.com/desht/ScrollingM...me/desht/scrollingmenusign/util/Debugger.java) but I would really prefer to use a Bukkit built-in utility class wherever possible. I'm a firm believer in using every feature an API can offer where possible, but in this case I sense a deficiency (or perhaps I'm just missing something).
     
Thread Status:
Not open for further replies.

Share This Page