RE: switch to commons-logging

[Tim Colson <tc...@cisco.com>]

> >> Serious question : Do you know anyone who switches?
> > i don't think it's really about people being able to switch.
> I know.  I just think the idea is funny.

I may be forced to switch to JDK 1.4 logging if it is deemed the group
'standard'. Yikes. Next thing you know, they'll be saying we must use
'standard' JSP. <grin>

I wish I had already started using commons-logging so the log4j switch
would be painless, but I wasn't that bright at the time. ;-)

Regarding the Velocity angle... personally, I want logging, but I don't
want to care and feed it all that much. Heck - I'm apparently not bright
enough to hand VelocityViewServlet, Hibernate, My Toolbox Tools, and
Struts a logger I've already created and so I wind up with a lot of ugly
console mesgs. From this point of view, a consistent and simple commons
logging soln for all tools sounds like a Good Thing(tm).

But then, I see Geirs 'least common denominator' perspective. For
example, I don't know if C-L can even handle log4j NDC's (nested
diagnostic contexts) or all of JDK 1.4's silly logging levels (fine,
finer, finest, supa-fine, ultra-fine, yo-mama-is-fine, etc.).

Switching sides again... Velocity core probably only uses basic log
stuff - so I tend to agree with Nathan that the LCD functionality of CL
might be suitable, and I for one don't mind another jar. 

But in the end, I just want simple configuration and logging - however
you blokes care to do it. <grin>

Cheers,
Timo

Re: switch to commons-logging

[Nathan Bubna <na...@esha.com>]

Tim Colson said:
...
> But then, I see Geirs 'least common denominator' perspective. For
> example, I don't know if C-L can even handle log4j NDC's (nested
> diagnostic contexts) or all of JDK 1.4's silly logging levels (fine,
> finer, finest, supa-fine, ultra-fine, yo-mama-is-fine, etc.).

i don't think Velocity does anything that requires NDC's.  remember, we're
talking about what log system velocity passes *its* log messages to.  as long
as we stick to a "logger agnostic" system like the current one or
commons-logging, you are free to use log4j or whatever feature-happy log
system your application needs.

that said, i don't actually think the current velocity log system is all that
great.  it mostly works and that's good.  but i think it would work better if
we used commons-logging, even were it only for the performance benefits of the
is<Priority>Enabled() checks that the commons-logging API supports and the
velocity logging API does not.

Nathan Bubna
nathan@esha.com

Re: switch to commons-logging

[Nathan Bubna <na...@esha.com>]

Geir Magnusson Jr.
> On Tuesday, August 26, 2003, at 10:23 PM, Tim Colson wrote:
> > But in the end, I just want simple configuration and logging - however
> > you blokes care to do it. <grin>
>
> This is the core as I see it.  The best solution, given that the
> existing code has been really easy to maintain and use so far, would be
> one that puts the least burden on users, while providing the
> functionality people want.
>
> Right?

in that case:

1. Velocity's log system does not have all the functionality i want (i doubt
i'm alone there).

2. commons-logging is no more difficult to set up than velocity's LogSystem.
it too searches the classpath for log4j and logkit and adds to that the
jdk1.4.  and just like velocity, it also has a simple default logger.

3.  the only real added "burden" is one small dependency that can be
distributed with velocity and is already something of a "standard" for
middleware libraries (used by the likes tomcat, struts, and many of its fellow
commons libraries).

is that really so much?

Nathan Bubna
nathan@esha.com

Re: switch to commons-logging

["Geir Magnusson Jr." <ge...@adeptra.com>]

On Tuesday, August 26, 2003, at 10:23 PM, Tim Colson wrote:
>
> But in the end, I just want simple configuration and logging - however
> you blokes care to do it. <grin>
>

This is the core as I see it.  The best solution, given that the 
existing code has been really easy to maintain and use so far, would be 
one that puts the least burden on users, while providing the 
functionality people want.

Right?

geir

-- 
Geir Magnusson Jr                                   203-956-2604(w)
Adeptra, Inc.                                       203-434-2093(m)
geirm@adeptra.com                                   203-247-1713(m)