[TIP] Setting up your plugin Logger correctly

Discussion in 'Resources' started by RROD, May 10, 2013.

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

    RROD

    Often I'm seeing people do this:
    Code:java
    1.  
    2. private Logger log = Logger.getLogger("Minecraft");
    3.  
    4. @Override
    5. public void onEnable() {
    6. PluginDescriptionFile pdfFile = this.getDescription();
    7. log.info(pdfFile.getName() + " Version: " + pdfFile.getVersion() + " is now enabled!");
    8. }
    9.  
    10. @Override
    11. public void onDisable() {
    12. PluginDescriptionFile pdfFile = this.getDescription();
    13. log.info(pdfFile.getName() + " Version: " + pdfFile.getVersion() + " is now disabled!");
    14. }
    15.  
    16. public void someMethod() {
    17. log.warning("[Plugin Name] Something happened!");
    18. }
    19.  

    This is not the best way to do this (and it really bugs me to see it happen >.>).
    So here's a tip for something you might not be familiar with. Bukkit has a built-in method for getting the Logger, with the Plugin's Name appended as a prefix. Yep, that's right. It's Plugin.getLogger() - and can be accessed via your instance of JavaPlugin.

    There also already is something in Bukkit that automatically appends an enable and disable message to the Logger.

    So with these things in mind, here's a better way to setup your plugin's Logging structure:
    Code:java
    1.  
    2. private Logger log;
    3.  
    4. @Override
    5. public void onEnable() {
    6. log = getLogger();
    7. // Do stuff
    8. }
    9.  
    10. @Override
    11. public void onDisable() {
    12.  
    13. }
    14.  
    15. public void someMethod() {
    16. // Notice how I've removed the plugin name prefix
    17. log.warning("Something happened!");
    18. }
    19.  
     
    Eats_Rainbows likes this.
  2. public Logger log = Logger.getLogger("Minecraft");
    should actually be
    public Logger log = Bukkit.getLogger();
    because the name of the logger has changed without noticing the users at 1.5
     
  3. Offline

    desht

    Leaving out the @Override annotation on methods that you're overriding is really not good practice; please don't recommend it. @Override is there for good reason: it means that if you make a mistake in your method declaration, the compiler will tell you immediately (instead of leaving you wondering why your method was never called at runtime), and it makes it clear to anyone reading the code that this is an overridden method.

    And why, in your second class, are you creating a public log object in exactly the same way you just recommended not to?
     
    RROD and ferrybig like this.
  4. Offline

    RROD

    Thanks for the feedback about this, fixed up the code.
     
  5. Offline

    coldandtired

    This is nonsense. Enabling and disabling messages were added a long time ago and have no connection to using the logger.

    You even linked to code showing it's nonsense!

    Which means your code sets the log variable in three places when only the first one was necessary.
     
  6. Offline

    RROD

    Right, ok. A learning curve for myself, I guess >.>
     
  7. Offline

    coldandtired

    Indeed.

    I didn't intend to sound mean but it's just that there are many people new to programming here so advising bad habits (as desht already pointed out) or strange code could have a bad influence on them.
     
  8. Offline

    RROD

    Yeah, I think I may have picked up on some of these when I was learning. That's what happens when you come from a background of self-teaching :rolleyes:
     
Thread Status:
Not open for further replies.

Share This Page