I've not used this before at all, and if I've needed logging have either used a very simple logger facility or System.out.println(...)
I promise that as soon as you get used to a logger-API you'll NEVER go back to System.out.println()...it quickly becomes as essential as syntax-highlighting, auto-complete, "IDE instead of notepad" etc.
Whether or not you agree with my feelings on L4J, if the alternative is "use nothing" then you should definitely use L4J... (although it might get you into bad habits and cause you some considerable pain; if you can, try and find a better API)
Has anyone around here use log4j in anger at all? if so is it any good? if not why not? are there any better alternatives? etc.
IMHO it's one of the those frustrating utility API's: good, but missing one or two absolutely key features ... like java.util when Sun chose not to include List etc (argh!) for the first few years...and omitted regular expressions for many years
On the whole, it's very well designed and a great API. But they made a brain-dead decision that castrates the API somewhat. They take the open-source/free-software programmers somewhat "interesting" approach to logging: you cannot "choose" what you want to log, you can only log "more" or "less".
Anyone with experience of moderately complex projects is liable to quickly run into the brick wall "I want full debug info on methods X Y and Z of class X, but just normal info on the other methods, and Log4j will only let me do 'all debug info on EVERYTHING' or 'normal info on EVERYTHING'". It's like someone giving you a hammer and forgetting to include the handle
The problem is really just that every logging call in l4j has a "priority" which MUST BE an int. And...it REALLY MATTERS which int you choose for your priorities - you cannot select "sets" of ints to log or not log, you can only select "greater than 5" or "less than 3" etc.
This was done originally to achieve high-performance. This is a bit depressing, since there are group-membership tests that could be done with almost the same level of performance that would make the API a hundred times more useful.
I find it annoying and selfish that they make the entirely false claim that it has "arbitrarily fine granularity" since this is precisely what it DOESN'T have. There are plenty of other logging API's around that are based on sets of priorities, or groups, or flags (e.g. bit-strings), instead of the stupid l4j decision to be based on a single int. (I've run into several in java, although I'm not sure which are free and which are not. We currently use one that is similar to l4j but fixes some of the problems...but it's a lot slower
If you do want to choose, you (as programmer) have to manually write all the code to do it, and encode it into your application. If you are always working for the same company, you can just make a harness for this (takes a while, pain in the butt, but once it's done doesn't need much tweaking). But...it takes you no less time to do that than to build an entire logging API of your own
. And many programmers simply can't take code they write for one employer with them when they move to a next job
Even when you have the harness, unless you make it a really complex one with lots of reflection (nb: reflection is probably still expensive enough in terms of performance that it completely negates all the speed of l4j) you're going to be writing 50+ lines of code in EVERY CLASS that is only there in order to coax l4j into working like a proper logging API.
Oh, there is another way - use "aspects" together with l4j. Aspect-oriented-programming is a whole mega-topic of it's own, but it's a *very* neat way of overcoming most of l4j's shortcomings. Again, though, I suspect that by the time you've done that you'll have so little of l4j left that you needn't bother with the l4j parts.