> If we wanted to go this way (i.e. use Log4J's Category API directly), Ceki
> has done this already -- he's got a "micro" JAR that is ~25k, for just
> this sort of purpose.
I know - I was just thinking it could be even smaller - just the Category
class with 1 or two others. (i.e. so it didn't do much really, just logged
to System.out and didn't need any configuration but was API compatible).
> To me personally, size is not big deal (I write server code for a living
> :-). My issues are:
>
> * Tie-in to an API that might not be the developer's choice
> (yes, you can write an Appender etc. but this is an *emotional*
> issue, not a technical one). I don't know how to address
> this one any way other than what I proposed -- gracefully use
> Log4J if it is there, and don't if it's not.
And so you avoid tie-in to log4j by creating tie-in to a new logging API?
That doesn't seem much of a win - creating yet another logging API.
If we have to pick an API, I'd rather it be a *very small* subset of a
popular near-standard then write yet another logging abstraction API.
> * Need to explicitly configure Log4J just to use DBCP or Digester
> or whatever. (This can be made a non-issue by having an included
> Log4J that self-configures itself to System.out gracefully in the
> absence of explicit configuration.
Like I said the commons-logger.jar could just log to System.out - no
configuration or anything fancy. If you want configuration and flashy stuff,
you swap commons-logger.jar with log4j.jar and away you go.
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
