That's the one thing with java logging, its one build and logging is turned on or off as required at runtime rather than compile time.
As for logging only for particular parts of the programme, yes that's what logging in java can do, again possible to configure at runtime. If this is to be done then ensure use of different Logger objects in different parts of the application (eg. use a logger of the same name as the class the logger is for, so in org.brailleblaster.Main get the logger with Logger.getLogger("org.brailleblaster.Main") ).
Also java logging allows you to configure the format of the log messages (eg. whether the time should be included, if it should come before the message or after, etc).
Please note: I have only discussed the java logging API in the JDK, this is because that is what I am most familiar with, I guess log4j can do all this as well.
Michael Whapples On 28/02/11 15:20, qubit wrote:
On the subject of debugging logs, one of the compiler projects I used to work on started with a general log that could be turned on and off, and evolved into something like what you are talking about, with debugging levels, only in our case the user could specify not just the verbosity, but recorded what phase of compilation was being performed. For example, on the command line it was -DDEBUG to conditionally compile the debugging code into the compiler, and also add flags to bump the level counter for verbosity of debugging for a specified part of the compiler (parsing, type checking, code generation, inline expansion, etc etc). If the command line created too much unuseful verbage, the user could also turn the debugging flags on and off in comments inside the compiler, or as commands in the interpreter. (I know most of the software I worked on was batch commands, but the perhaps some of the coding strategies are useful. --le ----- Original Message ----- From: "Michael Whapples"<mwhapples@xxxxxxx> To:<brailleblaster@xxxxxxxxxxxxx> Sent: Monday, February 28, 2011 7:39 AM Subject: [brailleblaster] Re: Debugging Logging should not always be on as this can affect performance due to outputting all the messages and the volume of output. As for where logging information goes, probably a sensible default might be a log file, possibly in the brailleblaster directory, although another location may be better as BrailleBlaster potentially may be in a read only location. May be near where the user's BrailleBlaster configuration is. Both of those choices should be controlled by a configuration, you are simply providing a default (IE. a configuration file being provided not controlled from BrailleBlaster code). However it may be desirable for BrailleBlaster to be able to adjust the logging level and so provide an easy way for the user to alter the level. As for what should be logged, possibly a question with no definite answer. Remember the various levels, certain people may only want to see certain information. While orca is written in python and not java, I think the debug module of orca may provide a suitable example which I have to hand. It defines the following levels like so: # Used to describe events of considerable importance and which will prevent # normal program execution. # LEVEL_SEVERE = 1000 # Used to decribe events of interest to end users or system managers or which # indicate potential problems, but which Orca can deal with without crashing. # LEVEL_WARNING = 900 # Used to indicate reasonably significant messages that make sense to end users # and system managers. # # For the purposes of Orca, LEVEL_INFO means display the text being sent to # speech and braille. # LEVEL_INFO = 800 # Used to indicate static configuration information to assist in debugging # problems that may be associated with a particular configuration. # # For the purposes of Orca, LEVEL_CONFIGURATION means display the various # apsects of whether a particular feature (e.g., speech, braille, etc.) # is enabled or not as well as details about that feature. # LEVEL_CONFIGURATION = 700 # Used for lowest volume of detailed tracing information. # # For the purposes of Orca, this is braille and keyboard input, script # activation and deletion, locus of focus changes, and visual changes # to the locus of focus. # LEVEL_FINE = 600 # Used for medium volume of detailed tracing information. # # For the purposes of Orca, this is for debugging speech and braille # generators and tracking the synthesis of device events. # LEVEL_FINER = 500 # Used for maximum volume of detailed tracing information. # # For the purposes of Orca, this is for tracking all AT-SPI object # events. NOTE that one can up the debug level of AT-SPI object # events by setting the eventDebugLevel. In addition, one can filter # events by setting eventDebugFilter to a regular expression that # matches event type names. # LEVEL_FINEST = 400 Michael Whapples On 28/02/11 13:23, John J. Boyer wrote:Sounds good. How do I know what to log? Should the logger be always on? Where should it put its files? John On Mon, Feb 28, 2011 at 12:57:35PM +0000, Michael Whapples wrote:Of course its still useful for a GUI application. Think of the support request: "I do something and it does something unusual" You cannot reproduce what they report, what do you do to help them? If logging is implemented then a log file can be produced and sent to you. Logging is great in this respect as internally in the application you just use a logger, the configuration tells it what should be done with the logging information. Michael Whapples On 28/02/11 12:56, John J. Boyer wrote:I'm wondering how important logging is for an application that is primarily a GUI. Of course it also has command-line functions. Lotting might be nice to use with CLI. John On Mon, Feb 28, 2011 at 07:29:52AM -0500, Sina Bahram wrote:Log4j is really easy to use though, and is rather wonderful for logging, if that's what's necessary of course. Take care, Sina -----Original Message----- From: brailleblaster-bounce@xxxxxxxxxxxxx [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Michael Whapples Sent: Monday, February 28, 2011 5:36 AM To: brailleblaster@xxxxxxxxxxxxx Subject: [brailleblaster] Re: Debugging Might you really be wanting logging? The java logging API in the JDK will probably be sufficient although there are alternatives like log4j, etc. Logging has much finer control over what error messages get output and where they go (eg. levels like finest, finer, fine, config, info, warning and severe). I think extra custom levels can be defined although the documentation seems to advise against that unless really needed. Also logging allows you to have multiple loggers which can be set to log at different levels (eg. the documentation suggests a logger per class). Also it is worth noting the following usage: if (logger.isLoggable(Level.FINE)) { logger.log(Level.FINE, "Message to be logged"); } While the log method of the Logger class will test if the level allows logging out, the additional if statement may improve performance as it saves any preparation to construct the message (eg. concatenation of strings). Configuration of the logging API can be done using system properties or a properties file. Also logging was mentioned before to you. Generally logging is easiest to implement at the time of writing the code rather than to add it in later. Michael Whapples On 28/02/11 08:09, John J. Boyer wrote:First, in response to Michael's last message, BrailleBlaster will present the user with a dialog box asking if she wants to continue, change settings read a startup tutorial, see a quick-start guide, etc. Finallyt it will have a checkbox with the message "Do not show me this message again." On to debugging. Can I call BrailleBlaster with the command: java -Ddebug=yes -jar brailleblaster.jar and later have the code String debug System.getProperty ("debug") The immediate reason for this is that I catch the UnsatisfiedLinkError exception if the liblouisutdml library is not found and set a boolean for the rest of the program. However this error could also be caused if one of its dependencies is not found. In this case I want to see the message. There will certainly be other reasons for wanting a debug flag. Thanks, John
