Jason4j,
> The wrapper is specific to Log4j, we could make it non-specific,
> but then we
> get into writting our own logging infrastructer, which is not something I
> would suggest.
>
...
> What is your beef with log4j? I still don't understand why you
> want it to go.
Jason, my view is extremly simple. While I do see a huuuuugggee interest in
log4j (I do really love it, be sure of that, I do) and I even do see a
huuuuuggggee interest in log4j on the client side ***while***
developping/debugging, I see absolutely *no* interest in log4j (that I still
love) on the client side while running in production. Worst, I really think
that this is bad design/packaging.
You tell me "we use log4j on the client side for errors and warnings".
That's not good in production. Either we have a bad behaviour and an
exception is raised (RemoteException exists for any EJB method for example),
either we shut up. Would you appreciate, while we run your new nice command
line tool that you just implemented, that the tool output is suddently
messed up with warnings and info messages from log4j... just because log4j
had something to say? Not in production.
Then, I don't want to "write my own loggging infrastructure" (I repeat it: I
am super-fan of log4j). It is just that we already have and use a wrapper
for log4j. Why have we done that? For many reasons, one of them being to be
able to change the logging infrastructure we use or more simply send it to
/dev/null. It is a minimalistic change. I will take a look at it.
And remember: I love log4j. ;)
Cheers,
Sacha4j
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
