"William Mok" <[EMAIL PROTECTED]> wrote on 08/17/2005 05:47:29 PM: > Your explanation is a lot better than those I found on web. Thx. > I still have some questions, see below:
Cool, glad it helped. I've run into all these problems before, so that why I've got a good knowledge of all the ways you can screw it up :^) > ----- Original Message ----- > From: <[EMAIL PROTECTED]> > > "William Mok" <[EMAIL PROTECTED]> wrote on 08/16/2005 03:59:25 PM: > >> Thanks. Your explanation make everything much clearer. > > Look at the call to Logger.getLogger(EchoService.class): what it does is > > retrieves the fully qualified name of that class, e.g. > > com.mycompany.mypackage.echo.EchoService. It then looks for a logger > > defined for com.mycompany.mypackage.echo.EchoService. If it doesn't find > > that, it'll look for the next step up the hierarchy, i.e. > > com.mycompany.mypackage.echo, then com.mycompany.mypackage, and so on. > > Once you've defined this logger for com.mycompany.mypackage.echo, that's > > what it'll find. It will then write whatever messages you send to that > > logger to the defined appenders, as long as those messages have the > > effective level of the logger or above. > > I am a bit confused about the rootlogger and childlogger concepts, what's > the reason behind having different logging hierarchy? What does the > rootLogger actually do? , i.e. when do I use the rootLogger? The root logger is just kind of a default handler so that if you don't have any specific logging stuff set up for a particular area of your code there's a place for the messages to go. That's why the root logger is usually set to ERROR or FATAL. Wherever a critical error occurs in your code, you generally want to know about it. Child loggers for particular parts of your code hierarchy then let you set the logging levels and output for particular parts of the functionality you're developing. You can set the root logger to ERROR, so that anything critical that occurs anywhere in your application is logged. You can then set the logging levels for each area that you're developing to different levels so you can see what's going on in there. So let's say, in addition to all of the framework code, you've got two packages in your application, one for business objects and one for the interface. When you're working on the business objects, you can set the logging level to DEBUG and get verbose information about that package, but set the interface logging level to WARN. This means that you'll see a ton of information in the logs about your business objects and only interesting stuff about your interface code. Now you've developed the business objects, change the settings to WARN for your business objects and DEBUG for your interface and get a ton of information about your interface code. This change in the amount and type of information you get from each section is done without changing your code at all, since the filtering is done by just not sending messages to the log when they're sent with Logger.debug() when that's below the logging level you've set. The cool thing is that, if you're suddenly getting weird results from a section of your code, just ratchet down the logging level and you get a bunch more information out of that section. For example, when I've got a bunch of queries that are getting run, I always output the query itself as info and usually output the results (as long as there aren't TOO too many results expected) with debug. That way, if something odd happens, I can see the query and its results without having to step through the debugger slowly, etc. > > That's probably because the stdout is being diverted somewhere. If you're > > running your servlet container (e.g. Tomcat) from a shell script, then > > that > > message will be displayed on the actual console. If you're running from a > > service on Windows or some other script on *nix, then stdout is usually > > diverted to something like localhost_log.<date>.txt or something like > > that. > > Another option is to replace the System.out.println() call by opening a > > file in a known location and writing out to that. It's completely > > impossible that you're not getting a class loader, otherwise... well, none > > of your classes would load :^) > > That's correct, if I run it using Eclipse, I can see the "search and > destroy" on the Eclipse console but not appearing in any of the logs. Yeah, then that's just a matter of figuring out what your servlet container thinks is stdout. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
