On Thu, 16 Aug 2001, James Strachan wrote:
> > 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).
>
I'll defer to Ceki's judgement on what the minimum possible JAR size is.
>
> > 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.
>
As I said, and I will say again, the technical part of this is easy to
address (a drop-in log4j-micro.jar that needs no configuration).
My issue is the developer's *emotional* reaction to a prerequisite that
says "you have to include log4j-micro.jar or the real log4j" to use our
nice shiny connection pool. We cannot solve this with technology - it's
an issue of marketing :-).
>
> > * 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.
>
Yep ... that's the *technical* part of the solution all right :-).
> James
>
Craig
