It also gave rise to slf4j, to tie the various (java) logging solutions together.

From a core library standpoint, the slf4j model might be a good one to emulate - provide a basic logging abstraction that can then be plumbed to whichever logging implementation is needed.  Logback is essentially the logging framework written by the slf4j guys, which is why I used it as an example.

And though I am not Eric, I do have a short list.  These are things that log4j/slf4j/etc provide that I'd consider required of any log framework before I use it in a production* environment:

Multiple log destinations (sinks/appenders), configurable.

  - required for logging to file, syslog, etc as appropriate

  - different running instances of same code may need different log names/locations/appenders

Hierarchical logs, with inheritance of levels, configure at runtime.  Turn on/off log level for part of hierarchy.

  - for debugging own code without being overwhelmed with log statements from elsewhere

  - turn off extraneous logging in dependencies, or turn it on for deep diving

Configurable log ouput with custom fields (time, thread, etc).

  - required for making log output match predefined formats

  - include needed metadata in the log line

Allow 'lazy' evaluation/formatting of log output (parameterized logging equivalent).

  - no performance excuse not to log

Log rotation

  - if this isn't there out of the box, guarantee will be first customization

* where 'production' is biased towards high availability services