You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Geir Magnusson Jr." <ge...@optonline.net> on 2003/10/25 14:24:35 UTC
Re: logging?
On Tuesday, September 2, 2003, at 11:59 AM, Nathan Bubna wrote:
> Henning P. Schmiedehausen said:
>> Did we get any consensus on this matter? Or did the discussion just
>> abruptly die?
>
> appearances indicate the latter. <sigh/>
Out of idle curiosity, and utter resentment for c-l having been forced
to drag that into a project due to Hibernate,
<aside>
It also uses commons-lang, specifically to add a few layers of class
hierarchy between Exception as we know and love it, and
HibernateException. Imagine my surprise when IDEA thought that
public static void main(String[] args)
throws Exception
{
// do some hibernate stuff
}
wasn't adequate for dealing with the exceptions thrown by the said
Hibernate stuff. After banging head on desk for a while, finally I got
some help when a friend asked "Does it use commons-lang?" and indeedy -
when c-lang was tossed into the classpath for the project, it was able
to figure it out. Quite baffling, and a good FYI for IDEA users. I
assume that any IDE will have this problem when it can't trace the
inheritance tree...
</aside>
I wanted to see if we could make everyone happy w/o tying in another
dependency. Here's an example LogSystem implementation to work with
c-l. I'm not going to commit this w/o discussion. Does this address
the issue adequately?
package org.apache.velocity.runtime.log;
import org.apache.velocity.runtime.RuntimeServices;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
/**
* Commons-logging LogSystem adapter. Can we call it the
*
* CloggingLogSystem?
*
* @author <a href="mailto:geirm@optonline.net">Geir Magnusson Jr.</a>
* @version $Id: $
*/
public class CommonsLoggingLogSystem implements LogSystem
{
private static Log log =
LogFactory.getLog(CommonsLoggingLogSystem.class);
public void init(RuntimeServices rs)
throws Exception
{
}
public void logVelocityMessage(int level, String message)
{
switch (level)
{
case LogSystem.WARN_ID:
log.warn(message);
break;
case LogSystem.INFO_ID:
log.info(message);
break;
case LogSystem.DEBUG_ID:
log.debug(message);
break;
case LogSystem.ERROR_ID:
log.error(message);
break;
default:
log.debug(message);
break;
}
}
}
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: logging?
Posted by Nathan Bubna <na...@esha.com>.
Jeff Schnitzer said:
...
> I'd propose not only adopting C-L, but also the new logger pattern.
i'm totally for it, but if part B (the new logger pattern) is something that
will hold up progress on the issue, i'd settle for starting with adopting C-L
and keeping the current pattern. certainly, that may be necessary (for a
time) anyway due to b.c. issues.
> This is _especially_ useful for third-party libraries like Velocity and
> Hibernate. I very, very, VERY rarely ever want to see debug messages
> from either of these libraries, and in the rare case that I do it's
> under very carefully controlled circumstances. In a normal running
> application I only want to see WARNand more serious messages, and in
> this case I want to see ALL of them. I'm having a hard time imagining a
> practical need for different logger configurations for different
> Velocity engines.
>
> In fact, there are things that the new pattern (and tools) would give me
> that I really _do_ consider useful: Priorities, and finer granularity
> over log message configuration (so I can block out messages that I feel
> have been misprioritized above my threshhold). In addition, the
> isDebugEnabled() method could improve performance considerably.
agreed.
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: logging?
Posted by Jeff Schnitzer <je...@infohazard.org>.
Geir Magnusson Jr. wrote:
>
>> First of all I should say that this is just as easy to do using C-L as
>> it is using LogSystem. If you want a single Logger, you can create it
>> and pass it down through the entire object hierarchy as you create it
>> just the same way you do this with a LogSystem logger.
>
> I think I know what you mean, but that presumes that you have to use c-l
> in addition to whatever logging system you want to use in your
> container, right?
I'm not sure what you mean. C-L is a tool and an API used internally by
third-party software. I don't "use" C-L, the people that write the
software I'm using do. Personally I use log4j because it's builtin to
JBoss.
As someone who develops with third-party code, my visibility of C-L is
pretty much zero.
> I agree with all - my point though is that you can pass differently
> configured loggers to different things. For example, when I added
> HttpClient to an existing server application, I had to modify the
> container's logging system to quiet it down - I would have simply loved
> to tell HttpClient to shut up by passing it a null logger.
Your scenario: A third-party library is too loud.
I would much rather change a configuration parameter in the container's
logging system than to modify code! I can even change the logging
configuration at runtime...
"Passing in a null logger" might not even be possible. You're assuming
that you are instantiating HttpClient directly, but what if you are
using third-party software (say, Cactus) that itself instantiates
HttpClient? Even if you can pass a null logger into the third-party
software, you're screwed if you want to see Cactus messages without
HttpClient messages.
> Here's the thing. I think you find it especially useful because you
> already use it. What if you don't use it?
Actually, I've never used C-L myself. That is to say, I've never
written a line of code that calls a method on a C-L class. I'm sure
that I use several third-party libraries that themselves use C-L, but
other than the fact that my applications won't work without
commons-logging.jar I really have little idea where it's used or how.
All my apps use Log4J directly; as an application developer it's just
part of my platform. I like the fact that Hibernate log messages
miraculously find their way into my logfiles with NO effort on my part;
it just works and I don't really know why.
Not only does it just work, it just works _right_. I have my root
logger configured to ignore anything less than INFO, and woah, I don't
get anything from Hibernate less than INFO. On the rare occasion that I
have wanted debug output from Hibernate, I simply increase the
sensitivity of the "net.sf.hibernate" category.
Contrast this with my Velocity experience: By default, Velocity logs to
stderr (or stdout?), which JBoss fortunately traps but doesn't really
offer any good way of filtering. It's also way too loud, logging at
every template execution. Ok, a little digging through documentation
and I find that it's possible to integrate with Log4J by adding a line
to velocity.properties. It's still too loud because every template
execution has priority INFO, so I decrease the sensitivity of
"org.apache.velocity" to WARN. Finally I have tolerable logging
output... but if I ever wanted more fine granularity (say, to get
debug-level output of just the template loading process) I'm hosed
because all Velocity logs go to a single category.
> And if you just could use c-l w/ velocity w/ a single config line, would
> that be ok?
I'm an application developer (as opposed to a tool developer). I don't
"use" C-L. If the people that write third-party libraries use C-L, it
means everything will work seamlessly with my Log4J environment. People
with JDK1.4, LogKit, or other environments will feel likewise.
> I've been thinking about this for a while now, and my first conclusion
> is that logging in the JDK was a huge disservice, because it's not going
> to change very rapidly, and it's the "standard". Thus, things like c-l
> have a reason to exist, but also will 'dumb down' how things log, as (if
> I understand correctly) you can't do logging impl specific things though
> the c-l api...
It won't be an LCD any more than LogSystem or any other abstraction
layer. But this doesn't bother me. In fact, I'm starting to consider
that thought to be a blessing.
There is a project here at EA that the devs at the time decided to give
a very complicated logging setup. It was an interesting experiment but
it turns out to be a major pain in the ass, both to code to and to
configure. Logging shouldn't be this complicated, it's just a way of
spitting out interesting messages! I'm replacing every last bit that I
touch.
If the API of logging never progressed beyond what C-L currently offers,
I will *cheer*.
> This reminds me of a discussion I had with someone about EJBs. I was
> doing some research on O/R tools, and he suggested using EJBs. He said
> that they were widely used, and a standard, so what were the drawbacks?
> I said "having to have a container around". That's the biggest
> drawback about usage patterns like this - pulling them out of thing air
> requires that you have the machinery around to support it. I use the
> pattern all the time in my own stuff, including a c-l-ish impl for
> logging I did in a previous project. The model has benefits. However,
> it also had drawbacks and that's what bugs me. I'm not convinced that
> it's worth the change. LogSystem is worth improving, but all the way to
> using c-l?
Your code always has to have a container of some sort, the question is
how much of it do you want to write yourself? I've had the EJB argument
at EA too. My point was this: After your proposed framework handles
object lifecycles, remoting, defines transaction boundaries, and assigns
security permissions, you have an EJB container. Now, do you want to
write it yourself or use JBoss?
Why write LogSystem when C-L is sitting on the shelf ready for use?
Jeff Schnitzer
jeff@infohazard.org
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: logging?
Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr. said:
...
> I've been thinking about this for a while now, and my first conclusion
> is that logging in the JDK was a huge disservice, because it's not
> going to change very rapidly, and it's the "standard". Thus, things
> like c-l have a reason to exist, but also will 'dumb down' how things
> log, as (if I understand correctly) you can't do logging impl specific
> things though the c-l api...
two slightly off topic and mildly contradictory points...
1. i believe JDK development has easily progressed more quickly in the last
year+ than that of LogSystem.
2. the speed of change in a product's API does not alone provide any evidence
of the quality of that product.
> Thanks. This was good. I still disagree that we need to switch.
> Despite repeated claims to the contrary, I do understand the benefits.
yet you still speak about "using" c-l in strange and confused (or at least
confusing) ways.
> I certainly appreciate the benefits of the pattern, but I also see some
> drawbacks.
>
> This reminds me of a discussion I had with someone about EJBs. I was
> doing some research on O/R tools, and he suggested using EJBs. He said
> that they were widely used, and a standard, so what were the drawbacks?
> I said "having to have a container around". That's the biggest
> drawback about usage patterns like this - pulling them out of thing air
> requires that you have the machinery around to support it.
comparing the need for a commons-logging.jar to the need for a container is
hardly fair.
> I use the
> pattern all the time in my own stuff, including a c-l-ish impl for
> logging I did in a previous project. The model has benefits. However,
> it also had drawbacks and that's what bugs me. I'm not convinced that
> it's worth the change. LogSystem is worth improving, but all the way
> to using c-l?
i'm not convinced LogSystem is worth the time and effort to improve it whilst
a superior alternative exists. and i still think you've failed to make your
case that commons-logging cannot do what LogSystem currently does.
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: logging?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Monday, October 27, 2003, at 09:35 PM, Jeff Schnitzer wrote:
> Geir Magnusson Jr. wrote:
>
>> What I was hinting at was how do you, in the same JVM, take two
>> instances of the same class (say velocity), and configure things so
>> they log differently?
>>
>> Call it an academic, hypothetical question if you want... :)
>>
>> Do you understand the difference between the pattern of having
>> control with each component, and having the component reach out into
>> the environment for it's logger? Sometimes the latter is
>> preferential, but many times it isn't. I know how to implement the
>> latter with the former, but not the reverse.
>
>
> First of all I should say that this is just as easy to do using C-L as
> it is using LogSystem. If you want a single Logger, you can create it
> and pass it down through the entire object hierarchy as you create it
> just the same way you do this with a LogSystem logger.
I think I know what you mean, but that presumes that you have to use
c-l in addition to whatever logging system you want to use in your
container, right?
>
> However, this is not the point I want to make. Quite the opposite
> really.
>
> I believe the logging _pattern_ that Geir is describing (IoC and all
> that) has fallen out of general favor in the Java community and been
> replaced with a different pattern, which I'll call the "Log4J
> pattern". I'm calling it that because it's the first time I saw this
> pattern in use.
I agree, and I think that in general, it's a great pattern. It's very
convenient.
>
> In the old pattern, a logger object is passed around from object to
> object as they are created, with new objects "inheriting" a logger
> from older ones. This has the advantage of maximum flexibility (every
> _object_ can log to a different logger) with the cost of extra effort
> by the programmer (gotta pass that object around and store it). It
> also presents a significant configuration problem - how do you decide
> which objects log where?
>
> I'm speculating here, but I think the people that wrote and used Log4J
> realized a few lessons:
>
> 1) Passing a logger object around is a pain in the ass. Logging needs
> to be as noninvasive as possible, otherwise lazy developers won't do
> it. If an class doesn't have immediate access to a logger, how many
> programmers go through the work building in the logger infrastructure
> instead of simply printing to stdout and commenting it out later?
>
> 2) Static methods can't issue log statements.
>
> 3) Object-by-object control over logging is not really that useful.
> Programmers have been logging to stdout for decades, and it's met most
> of our needs. If every object of a particular class spits out logs,
> we can figure out the details of which object is which from the
> context.
>
> 4) How do you configure object-by-object logging? It may be granular
> in theory but in practice you have to write code to turn on and off
> log messages. What about code that you don't have control over, like
> third-party modules? Your level of granularity degenerates to the
> whole module. Priority-level control helps
> (DEBUG/INFO/WARN/ERROR/FATAL/FLEETHECOUNTRY) but what if I want to see
> Veloctiy log messages related to template loading and block log
> messages related to template rendering? Can I do this without
> modifying Velocity (to me, a third-party library) code? Can I do this
> without modifying any code? Can I do this at runtime without
> restarting the application?
I agree with all - my point though is that you can pass differently
configured loggers to different things. For example, when I added
HttpClient to an existing server application, I had to modify the
container's logging system to quiet it down - I would have simply loved
to tell HttpClient to shut up by passing it a null logger.
>
>
> The new logging pattern, espoused by Log4J in their examples, eschews
> object-by-object loggers in favor of class-by-class loggers. This
> provides some major advantages:
>
> 1) Near-zero effort to add logging to a class, with zero impact on
> application architecture. Any object can have a logger without
> worrying about where it will come from. Every class is autonomous.
>
> 2) Static methods can log just as easily as any other method.
>
> 3) The java package hierarchy presents a natural hierarchy of logger
> objects. Without any extra effort by the programmer, the logging
> system automatically defines levels of logger granularity much finer
> than just modules.
>
> 4) Configuration is straightforward and doesn't require code, because
> it's based on the ad-hoc logger hierarchy. Many tools like Log4J can
> even let you do this at runtime!
>
> I'd propose not only adopting C-L, but also the new logger pattern.
> This is _especially_ useful for third-party libraries like Velocity
> and Hibernate. I very, very, VERY rarely ever want to see debug
> messages from either of these libraries, and in the rare case that I
> do it's under very carefully controlled circumstances. In a normal
> running application I only want to see WARNand more serious messages,
> and in this case I want to see ALL of them. I'm having a hard time
> imagining a practical need for different logger configurations for
> different Velocity engines.
Here's the thing. I think you find it especially useful because you
already use it. What if you don't use it?
And if you just could use c-l w/ velocity w/ a single config line,
would that be ok?
>
> In fact, there are things that the new pattern (and tools) would give
> me that I really _do_ consider useful: Priorities, and finer
> granularity over log message configuration (so I can block out
> messages that I feel have been misprioritized above my threshhold).
> In addition, the isDebugEnabled() method could improve performance
> considerably.
Yes - that is the one thing that I do find lacking in log system.
I've been thinking about this for a while now, and my first conclusion
is that logging in the JDK was a huge disservice, because it's not
going to change very rapidly, and it's the "standard". Thus, things
like c-l have a reason to exist, but also will 'dumb down' how things
log, as (if I understand correctly) you can't do logging impl specific
things though the c-l api...
Thanks. This was good. I still disagree that we need to switch.
Despite repeated claims to the contrary, I do understand the benefits.
I certainly appreciate the benefits of the pattern, but I also see some
drawbacks.
This reminds me of a discussion I had with someone about EJBs. I was
doing some research on O/R tools, and he suggested using EJBs. He said
that they were widely used, and a standard, so what were the drawbacks?
I said "having to have a container around". That's the biggest
drawback about usage patterns like this - pulling them out of thing air
requires that you have the machinery around to support it. I use the
pattern all the time in my own stuff, including a c-l-ish impl for
logging I did in a previous project. The model has benefits. However,
it also had drawbacks and that's what bugs me. I'm not convinced that
it's worth the change. LogSystem is worth improving, but all the way
to using c-l?
geir
>
> Jeff
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: logging?
Posted by Jeff Schnitzer <je...@infohazard.org>.
Geir Magnusson Jr. wrote:
> What I was hinting at was how do you, in the same JVM, take two
> instances of the same class (say velocity), and configure things so
> they log differently?
>
> Call it an academic, hypothetical question if you want... :)
>
> Do you understand the difference between the pattern of having control
> with each component, and having the component reach out into the
> environment for it's logger? Sometimes the latter is preferential,
> but many times it isn't. I know how to implement the latter with the
> former, but not the reverse.
First of all I should say that this is just as easy to do using C-L as
it is using LogSystem. If you want a single Logger, you can create it
and pass it down through the entire object hierarchy as you create it
just the same way you do this with a LogSystem logger.
However, this is not the point I want to make. Quite the opposite really.
I believe the logging _pattern_ that Geir is describing (IoC and all
that) has fallen out of general favor in the Java community and been
replaced with a different pattern, which I'll call the "Log4J pattern".
I'm calling it that because it's the first time I saw this pattern in use.
In the old pattern, a logger object is passed around from object to
object as they are created, with new objects "inheriting" a logger from
older ones. This has the advantage of maximum flexibility (every
_object_ can log to a different logger) with the cost of extra effort by
the programmer (gotta pass that object around and store it). It also
presents a significant configuration problem - how do you decide which
objects log where?
I'm speculating here, but I think the people that wrote and used Log4J
realized a few lessons:
1) Passing a logger object around is a pain in the ass. Logging needs
to be as noninvasive as possible, otherwise lazy developers won't do
it. If an class doesn't have immediate access to a logger, how many
programmers go through the work building in the logger infrastructure
instead of simply printing to stdout and commenting it out later?
2) Static methods can't issue log statements.
3) Object-by-object control over logging is not really that useful.
Programmers have been logging to stdout for decades, and it's met most
of our needs. If every object of a particular class spits out logs, we
can figure out the details of which object is which from the context.
4) How do you configure object-by-object logging? It may be granular in
theory but in practice you have to write code to turn on and off log
messages. What about code that you don't have control over, like
third-party modules? Your level of granularity degenerates to the whole
module. Priority-level control helps
(DEBUG/INFO/WARN/ERROR/FATAL/FLEETHECOUNTRY) but what if I want to see
Veloctiy log messages related to template loading and block log messages
related to template rendering? Can I do this without modifying Velocity
(to me, a third-party library) code? Can I do this without modifying
any code? Can I do this at runtime without restarting the application?
The new logging pattern, espoused by Log4J in their examples, eschews
object-by-object loggers in favor of class-by-class loggers. This
provides some major advantages:
1) Near-zero effort to add logging to a class, with zero impact on
application architecture. Any object can have a logger without worrying
about where it will come from. Every class is autonomous.
2) Static methods can log just as easily as any other method.
3) The java package hierarchy presents a natural hierarchy of logger
objects. Without any extra effort by the programmer, the logging system
automatically defines levels of logger granularity much finer than just
modules.
4) Configuration is straightforward and doesn't require code, because
it's based on the ad-hoc logger hierarchy. Many tools like Log4J can
even let you do this at runtime!
I'd propose not only adopting C-L, but also the new logger pattern.
This is _especially_ useful for third-party libraries like Velocity and
Hibernate. I very, very, VERY rarely ever want to see debug messages
from either of these libraries, and in the rare case that I do it's
under very carefully controlled circumstances. In a normal running
application I only want to see WARNand more serious messages, and in
this case I want to see ALL of them. I'm having a hard time imagining a
practical need for different logger configurations for different
Velocity engines.
In fact, there are things that the new pattern (and tools) would give me
that I really _do_ consider useful: Priorities, and finer granularity
over log message configuration (so I can block out messages that I feel
have been misprioritized above my threshhold). In addition, the
isDebugEnabled() method could improve performance considerably.
Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: logging?
Posted by Nathan Bubna <na...@esha.com>.
Will Glass-Husain said:
> <hand raised>
:)
> I use multiple Velocity instances in the same VM. I have a turbine based
> web app that uses Velocity to present web pages. In some of the actions
> (e.g. "Create Account"), the app uses a second instance of Velocity Engine
> to pre-process textual information (e.g. default account information). This
> happens in 3 or 4 places.
cool. and i'm sure you're not the only one. please don't think i'm
advocating making this impossible, i'm not. i see Geir's point that this has
use, and i don't doubt some people are using it. i just don't think the
significant majority of people are, thus i'm not opposed to making this
behavior take slightly more effort if need be. it may be that this won't
really be any harder even if we do switch to c-l.
> Currently, I'm logging the results to different files. I don't really care
> that much, except that Velocity produces a bunch of lines when it starts up
> and I thought it was annoying to have the same startup lines in my main log
> file every time the secondary instance starts up.
here is somewhere where using c-l could help! most logging solutions (e.g.
log4j) provide support for en/disabling output by log level. LogSystem does
not. if we switched to c-l, i believe you could get the behavior you have
without so much annoyance.
> I'm not familiar enough with commons-logging to know if this would help.
> But it'd be nice to configure everything in the same place, with flexibility
> as to location of log information. (are these conflicting goals?)
i think this is doable with c-l.
> </hand raised>
...
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: logging?
Posted by Will Glass-Husain <wg...@forio.com>.
<hand raised>
I use multiple Velocity instances in the same VM. I have a turbine based
web app that uses Velocity to present web pages. In some of the actions
(e.g. "Create Account"), the app uses a second instance of Velocity Engine
to pre-process textual information (e.g. default account information). This
happens in 3 or 4 places.
Currently, I'm logging the results to different files. I don't really care
that much, except that Velocity produces a bunch of lines when it starts up
and I thought it was annoying to have the same startup lines in my main log
file every time the secondary instance starts up.
I'm not familiar enough with commons-logging to know if this would help.
But it'd be nice to configure everything in the same place, with flexibility
as to location of log information. (are these conflicting goals?)
</hand raised>
WILL
Nathan:
> maybe that's not ideal, but i don't hear a lot of people around here using
> Velocity like this. in fact, i can't say i've ever heard anyone talk or
ask
> about this capability in my years on these lists. afaik, most of our
users
> still use Velocity as a singleton. further, i'd even be surprised if many
who
> use multiple VelocityEngine's in the same JVM (are there even that many of
> those users?) configure their logging differently for each (which is what
> you're talking about, right?).
WILL
----- Original Message -----
From: "Nathan Bubna" <na...@esha.com>
To: "Velocity Developers List" <ve...@jakarta.apache.org>
Sent: Monday, October 27, 2003 3:14 PM
Subject: Re: logging?
> Geir Magnusson Jr. said:
> > On Saturday, October 25, 2003, at 08:35 PM, Nathan Bubna wrote:
> > > Geir Magnusson Jr. said:
> > >> On Saturday, October 25, 2003, at 05:04 PM, Nathan Bubna wrote:
> > >>> Geir Magnusson Jr. said:
> > >>>> On Saturday, October 25, 2003, at 11:53 AM, Nathan Bubna wrote:
> ...
> > >> The problem I have with c-l is that you, as the user of the
component,
> > >> have no choice in the matter. You have to bring c-l.jar around even
> > >> if
> > >> you don't want any logging. That's why I advocate having an
adapter -
> > >> then the user is in control - we aren't forcing anything on the user.
> > >
> > > good grief. did you hear me? commons-logging _*IS*_ an
> > > adapter!!!!!!!!!
> >
> > Calm down. I meant an adapter to our core. That way you have a choice.
>
> ok, so that i don't respond over-excitedly to another incomplete
statement,
> what is the choice? and how exactly does c-l not give this choice?
>
> > >> Then, it goes and grabs out of thin air the logger and goes to town.
> > >> You can't even tell c-l that you don't want something to be able to
> > >> log on an instance by instance basis.
> > >
> > > huh? i have no idea what you are trying to say here. we are so very
> > > clearly not on the same page right now.
> >
> > To make sure we're on the same page, I'll go re-read c-l docs to be
> > sure that I'm up-to-date. That's only fair. Things may have changed
> > since I stared at it hard.
> >
> > What I was hinting at was how do you, in the same JVM, take two
> > instances of the same class (say velocity), and configure things so
> > they log differently?
>
> ah, i see what you're getting at now. well, i suppose it's a matter of
how
> you use c-l (or anything else) in the project. i don't see any reason you
> can't have setLog(o.a.c.l.Log log) methods. then you could get multiple
Log
> instances with different names and configure your underlying logging
solution
> to handle them differently.
> maybe that's not ideal, but i don't hear a lot of people around here using
> Velocity like this. in fact, i can't say i've ever heard anyone talk or
ask
> about this capability in my years on these lists. afaik, most of our
users
> still use Velocity as a singleton. further, i'd even be surprised if many
who
> use multiple VelocityEngine's in the same JVM (are there even that many of
> those users?) configure their logging differently for each (which is what
> you're talking about, right?).
>
> in programming, i feel that the convenience of the practical many must
> sometimes override the elegance of the idealistic few. :)
>
> > Call it an academic, hypothetical question if you want... :)
>
> well, isn't it? i don't think many people are using or trying to use
Velocity
> in this way. that said, i have no problem considering hypothetical
situations
> as long as they don't always override real ones. balance is good.
>
> > Do you understand the difference between the pattern of having control
> > with each component, and having the component reach out into the
> > environment for it's logger?
>
> i do, but i can't say i understand yet how that is so valuable for
Velocity.
> :-/
>
> > Sometimes the latter is preferential, but
> > many times it isn't.
>
> really? how many times? :)
>
> > I know how to implement the latter with the
> > former, but not the reverse.
>
> uh... ok.
>
> ...
> > How would you propose we do this
> > w/o forcing our users to use c-l or abandon the pattern of control we
> > give them now?
>
> i still don't grep this "forcing our users to use c-l" stuff. both it and
our
> LogSystem are adapters. neither forces users into any particular logging
> solution. if nothing else, the contents of the o.a.v.tools.generic.log
> package should demonstrate this principle clearly.
>
> as for the current "pattern of control" available to users, i personally
don't
> see what's so important about it. perhaps that's just my ignorance, but
> regardless, i don't presently see any reason c-l can't be used in similar
> fashion to how LogSystem currently is. if you can explain to me what c-l
is
> lacking, then by all means do.
>
> > That's the key for me. If you have an example of retaining control
> > using c-l, please point me to it.
>
> i can't think of any out there, but that doesn't mean it can't be or
hasn't
> been done. i would love to have the time to find/make one or even give
you a
> big fat Velocity patch to show you what i'm thinking, but i don't. as it
is,
> this debate is heavily taxing what free time i do have. also, as i've
said in
> the past, i don't see this as any sort of priority. there are more
important
> features on the average user's wish list (and mine). unless you've
started to
> "get it" :) and feel like putting in the elbow grease here for me/us, we
> should probably shelve this for now. cool?
>
> Nathan Bubna
> nathan@esha.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: logging?
Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr. said:
> On Monday, October 27, 2003, at 06:14 PM, Nathan Bubna wrote:
> ...
> > in programming, i feel that the convenience of the practical many must
> > sometimes override the elegance of the idealistic few. :)
>
> Unless you get the elegance and the convenience at the same time.
>
> With c-l, you get the least-common-denominator logging interface.
> While I wouldn't dare argue that LogSystem is superior, we do have the
> ability to do whatever we want, and still make it trivially usable for
> those that want c-l. In the other direction, you can't get anything
> more than the lcd of c-l.
and round in circles we go... again, this argument is ridiculous. the
current state of Velocity's logging is far inferior to c-l. it is a
lower-than-the-lowest-common-denominator logging interface. i don't believe
we have anything more than the LCD of c-l as it is!
and this "for those that want c-l" thing is still sketchy. remember, c-l is
an adapter just as LogSystem is. developers should not use c-l as a logging
solution for their end products. when talking about "those that want c-l", we
should only be talking about developers of "components" (used here loosely to
include things like frameworks and containers and anything that is not an
end-product) who don't want to force their users (those using the
"components") into a particular logging solution.
> >> Do you understand the difference between the pattern of having control
> >> with each component, and having the component reach out into the
> >> environment for it's logger?
> >
> > i do, but i can't say i understand yet how that is so valuable for
> > Velocity.
> > :-/
>
> Because then I can do what I want, you can do what you want, and a
> person we haven't met yet can do what he or she wants....
that is so incredibly vague, how could i possibly contest it? :)
...
> >> How would you propose we do this
> >> w/o forcing our users to use c-l or abandon the pattern of control we
> >> give them now?
> >
> > i still don't grep this "forcing our users to use c-l" stuff. both it
> > and our
> > LogSystem are adapters. neither forces users into any particular
> > logging
> > solution. if nothing else, the contents of the o.a.v.tools.generic.log
> > package should demonstrate this principle clearly.
>
> You can't use Velocity w/o c-l if we use c-l. It's that simple.
in other words, you don't want a dependency. well, i simply disagree here.
> We can't make our logging any richer than what c-l does.
> We'd be stuck.
from my perspective, i'm already stuck with a buggier, less powerful, and less
actively maintained/developed logging adapter. i'd rather be "stuck" with
c-l, thanks very much. remember, c-l is small. if we really wanted to take a
different direction than them, we could just grab the code, throw it in our
project and hack away! it's open-source. you're never truly "stuck"
> > as for the current "pattern of control" available to users, i
> > personally don't
> > see what's so important about it. perhaps that's just my ignorance,
> > but
> > regardless, i don't presently see any reason c-l can't be used in
> > similar
> > fashion to how LogSystem currently is. if you can explain to me what
> > c-l is
> > lacking, then by all means do.
>
> I've been trying. It gives us the freedom to log the way we want, not
> on the 'average' of log4j, System.out.println, and JDK1.4. That fact
> that LogSystem isn't great doesn't change that fact.
hmm. i think now this is really more about you wanting to maintain
independence of other projects, not the technical merits of c-l vs. LogSystem.
explains a lot.
> >> That's the key for me. If you have an example of retaining control
> >> using c-l, please point me to it.
> >
> > i can't think of any out there, but that doesn't mean it can't be or
> > hasn't
> > been done. i would love to have the time to find/make one or even
> > give you a
> > big fat Velocity patch to show you what i'm thinking, but i don't. as
> > it is,
> > this debate is heavily taxing what free time i do have. also, as i've
> > said in
> > the past, i don't see this as any sort of priority. there are more
> > important
> > features on the average user's wish list (and mine). unless you've
> > started to
> > "get it" :) and feel like putting in the elbow grease here for me/us,
> > we
> > should probably shelve this for now. cool?
>
> It's actually a very interesting question. (I like to think about
> application architecture and patterns). The nice thing about c-l is
> that it's easy. really easy. And it's a reasonable model for
> containers and frameworks. I just think that for components, it isn't,
> or if it is, there should be a good reason
i think it can be just fine for components. i believe you can use c-l in an
IoC manner. i believe the good reasons are clear. benefit from a larger
communities support, maintenance, and mindshare. also the components are
typically used by and/or with the containers and frameworks. if they use c-l,
then the integration is seamless and easy.
> Anyway, I agree. I think that we can improve LogSystem w/o much
> effort, get the features that we need,
and generally reinvent wheels already invented. that's not always a bad
thing, but be sure to put your money (read: time and effort) where your mouth
is. if you're gonna build a competing logging adapter that fits more
obviously into an IoC pattern, then you'd better make it a worthy competitor.
what we've got right now is nowhere close to that.
> and if we can switch to c-l w/o
> mortgaging the future, I'm all for it.
i believe we can. (and don't think i didn't notice that in this reply of
yours, you didn't address my comments on how one might use c-l in an IoC
pattern. :) ) though i'll admit, i've not tried implementing any of the
ideas this all has given me.
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: logging?
Posted by Will Glass-Husain <wg...@forio.com>.
Nice commentary Jeff. I especially like the line below.
> This is _especially_ useful for third-party libraries like Velocity and
> Hibernate. I very, very, VERY rarely ever want to see debug messages
> from either of these libraries, and in the rare case that I do it's
> under very carefully controlled circumstances.
As a related note, a problem I have with Velocity logging is that it does
too many error logging messages. If a resource is not found, I want my app
to log the message, not Velocity. I've built apps that search for one
template, and if it's not found it grabs a default template. Not an error
condition in this case, yet Velocity still logs a message. If I want this
to be logged, then when getTemplate returns null the calling app can still
do this.
My solution for this right now is a custom Velocity logger that filters out
unwanted messages. But this seems a bit extreme.
Best,
WILL
----- Original Message -----
From: "Jeff Schnitzer" <je...@infohazard.org>
To: "Velocity Developers List" <ve...@jakarta.apache.org>
Sent: Monday, October 27, 2003 6:55 PM
Subject: Re: logging?
> Geir Magnusson Jr. wrote:
>
> > With c-l, you get the least-common-denominator logging interface.
> > While I wouldn't dare argue that LogSystem is superior, we do have the
> > ability to do whatever we want, and still make it trivially usable for
> > those that want c-l. In the other direction, you can't get anything
> > more than the lcd of c-l.
>
>
> This is a debate which can be made about all third-party libraries.
> Yes, you trade off control for reduced effort. Fortunately, I don't
> hear anyone arguing that Velocity should include it's own JVM :-)
>
> I don't think the reduced control is all that much of an issue though:
>
> 1) C-L is part of Jakarta. It's pretty close to home and not that hard
> to change.
>
> 2) C-L is not a lowest common denominator; it adapts features to
> less-capable environments. Stdout doesn't have any concept of
> priorities and logging categories, but C-L provides them.
>
> 3) C-L, in its current state, has more than what we need for the
> forseeable future and significantly more than what is offered by
LogSystem.
>
> 4) Practical limitations (lack of manpower and time to enhance
> LogSystem) are in reality far more restrictive than any theoretical
> limitations on C-L. Here and now C-L offers tons more features than
> LogSystem, and this condition is highly unlikely to ever change.
>
> Jeff
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: logging?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Monday, October 27, 2003, at 09:55 PM, Jeff Schnitzer wrote:
> Geir Magnusson Jr. wrote:
>
>> With c-l, you get the least-common-denominator logging interface.
>> While I wouldn't dare argue that LogSystem is superior, we do have
>> the ability to do whatever we want, and still make it trivially
>> usable for those that want c-l. In the other direction, you can't
>> get anything more than the lcd of c-l.
>
>
> This is a debate which can be made about all third-party libraries.
> Yes, you trade off control for reduced effort. Fortunately, I don't
> hear anyone arguing that Velocity should include it's own JVM :-)
It's probably coming next. And hardware. We need to include hardware
to run it on :)
>
> I don't think the reduced control is all that much of an issue though:
>
> 1) C-L is part of Jakarta. It's pretty close to home and not that
> hard to change.
>
> 2) C-L is not a lowest common denominator; it adapts features to
> less-capable environments. Stdout doesn't have any concept of
> priorities and logging categories, but C-L provides them.
>
> 3) C-L, in its current state, has more than what we need for the
> forseeable future and significantly more than what is offered by
> LogSystem.
>
> 4) Practical limitations (lack of manpower and time to enhance
> LogSystem) are in reality far more restrictive than any theoretical
> limitations on C-L. Here and now C-L offers tons more features than
> LogSystem, and this condition is highly unlikely to ever change.
:)
I hear you.
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: logging?
Posted by Jeff Schnitzer <je...@infohazard.org>.
Geir Magnusson Jr. wrote:
> With c-l, you get the least-common-denominator logging interface.
> While I wouldn't dare argue that LogSystem is superior, we do have the
> ability to do whatever we want, and still make it trivially usable for
> those that want c-l. In the other direction, you can't get anything
> more than the lcd of c-l.
This is a debate which can be made about all third-party libraries.
Yes, you trade off control for reduced effort. Fortunately, I don't
hear anyone arguing that Velocity should include it's own JVM :-)
I don't think the reduced control is all that much of an issue though:
1) C-L is part of Jakarta. It's pretty close to home and not that hard
to change.
2) C-L is not a lowest common denominator; it adapts features to
less-capable environments. Stdout doesn't have any concept of
priorities and logging categories, but C-L provides them.
3) C-L, in its current state, has more than what we need for the
forseeable future and significantly more than what is offered by LogSystem.
4) Practical limitations (lack of manpower and time to enhance
LogSystem) are in reality far more restrictive than any theoretical
limitations on C-L. Here and now C-L offers tons more features than
LogSystem, and this condition is highly unlikely to ever change.
Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: logging?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Monday, October 27, 2003, at 06:14 PM, Nathan Bubna wrote:
>
>
> in programming, i feel that the convenience of the practical many must
> sometimes override the elegance of the idealistic few. :)
Unless you get the elegance and the convenience at the same time.
With c-l, you get the least-common-denominator logging interface.
While I wouldn't dare argue that LogSystem is superior, we do have the
ability to do whatever we want, and still make it trivially usable for
those that want c-l. In the other direction, you can't get anything
more than the lcd of c-l.
>
>> Do you understand the difference between the pattern of having control
>> with each component, and having the component reach out into the
>> environment for it's logger?
>
> i do, but i can't say i understand yet how that is so valuable for
> Velocity.
> :-/
Because then I can do what I want, you can do what you want, and a
person we haven't met yet can do what he or she wants....
>
>> Sometimes the latter is preferential, but
>> many times it isn't.
>
> really? how many times? :)
I dunno. Go look at all the IoC containers out there. I'm not an IoC
guy, but there's clearly some great ideas in that component model.
>
> ...
>> How would you propose we do this
>> w/o forcing our users to use c-l or abandon the pattern of control we
>> give them now?
>
> i still don't grep this "forcing our users to use c-l" stuff. both it
> and our
> LogSystem are adapters. neither forces users into any particular
> logging
> solution. if nothing else, the contents of the o.a.v.tools.generic.log
> package should demonstrate this principle clearly.
You can't use Velocity w/o c-l if we use c-l. It's that simple. We
can't make our logging any richer than what c-l does. We'd be stuck.
>
> as for the current "pattern of control" available to users, i
> personally don't
> see what's so important about it. perhaps that's just my ignorance,
> but
> regardless, i don't presently see any reason c-l can't be used in
> similar
> fashion to how LogSystem currently is. if you can explain to me what
> c-l is
> lacking, then by all means do.
I've been trying. It gives us the freedom to log the way we want, not
on the 'average' of log4j, System.out.println, and JDK1.4. That fact
that LogSystem isn't great doesn't change that fact.
>
>> That's the key for me. If you have an example of retaining control
>> using c-l, please point me to it.
>
> i can't think of any out there, but that doesn't mean it can't be or
> hasn't
> been done. i would love to have the time to find/make one or even
> give you a
> big fat Velocity patch to show you what i'm thinking, but i don't. as
> it is,
> this debate is heavily taxing what free time i do have. also, as i've
> said in
> the past, i don't see this as any sort of priority. there are more
> important
> features on the average user's wish list (and mine). unless you've
> started to
> "get it" :) and feel like putting in the elbow grease here for me/us,
> we
> should probably shelve this for now. cool?
It's actually a very interesting question. (I like to think about
application architecture and patterns). The nice thing about c-l is
that it's easy. really easy. And it's a reasonable model for
containers and frameworks. I just think that for components, it isn't,
or if it is, there should be a good reason.
Anyway, I agree. I think that we can improve LogSystem w/o much
effort, get the features that we need, and if we can switch to c-l w/o
mortgaging the future, I'm all for it.
geir
> Nathan Bubna
> nathan@esha.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: logging?
Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr. said:
> On Saturday, October 25, 2003, at 08:35 PM, Nathan Bubna wrote:
> > Geir Magnusson Jr. said:
> >> On Saturday, October 25, 2003, at 05:04 PM, Nathan Bubna wrote:
> >>> Geir Magnusson Jr. said:
> >>>> On Saturday, October 25, 2003, at 11:53 AM, Nathan Bubna wrote:
...
> >> The problem I have with c-l is that you, as the user of the component,
> >> have no choice in the matter. You have to bring c-l.jar around even
> >> if
> >> you don't want any logging. That's why I advocate having an adapter -
> >> then the user is in control - we aren't forcing anything on the user.
> >
> > good grief. did you hear me? commons-logging _*IS*_ an
> > adapter!!!!!!!!!
>
> Calm down. I meant an adapter to our core. That way you have a choice.
ok, so that i don't respond over-excitedly to another incomplete statement,
what is the choice? and how exactly does c-l not give this choice?
> >> Then, it goes and grabs out of thin air the logger and goes to town.
> >> You can't even tell c-l that you don't want something to be able to
> >> log on an instance by instance basis.
> >
> > huh? i have no idea what you are trying to say here. we are so very
> > clearly not on the same page right now.
>
> To make sure we're on the same page, I'll go re-read c-l docs to be
> sure that I'm up-to-date. That's only fair. Things may have changed
> since I stared at it hard.
>
> What I was hinting at was how do you, in the same JVM, take two
> instances of the same class (say velocity), and configure things so
> they log differently?
ah, i see what you're getting at now. well, i suppose it's a matter of how
you use c-l (or anything else) in the project. i don't see any reason you
can't have setLog(o.a.c.l.Log log) methods. then you could get multiple Log
instances with different names and configure your underlying logging solution
to handle them differently.
maybe that's not ideal, but i don't hear a lot of people around here using
Velocity like this. in fact, i can't say i've ever heard anyone talk or ask
about this capability in my years on these lists. afaik, most of our users
still use Velocity as a singleton. further, i'd even be surprised if many who
use multiple VelocityEngine's in the same JVM (are there even that many of
those users?) configure their logging differently for each (which is what
you're talking about, right?).
in programming, i feel that the convenience of the practical many must
sometimes override the elegance of the idealistic few. :)
> Call it an academic, hypothetical question if you want... :)
well, isn't it? i don't think many people are using or trying to use Velocity
in this way. that said, i have no problem considering hypothetical situations
as long as they don't always override real ones. balance is good.
> Do you understand the difference between the pattern of having control
> with each component, and having the component reach out into the
> environment for it's logger?
i do, but i can't say i understand yet how that is so valuable for Velocity.
:-/
> Sometimes the latter is preferential, but
> many times it isn't.
really? how many times? :)
> I know how to implement the latter with the
> former, but not the reverse.
uh... ok.
...
> How would you propose we do this
> w/o forcing our users to use c-l or abandon the pattern of control we
> give them now?
i still don't grep this "forcing our users to use c-l" stuff. both it and our
LogSystem are adapters. neither forces users into any particular logging
solution. if nothing else, the contents of the o.a.v.tools.generic.log
package should demonstrate this principle clearly.
as for the current "pattern of control" available to users, i personally don't
see what's so important about it. perhaps that's just my ignorance, but
regardless, i don't presently see any reason c-l can't be used in similar
fashion to how LogSystem currently is. if you can explain to me what c-l is
lacking, then by all means do.
> That's the key for me. If you have an example of retaining control
> using c-l, please point me to it.
i can't think of any out there, but that doesn't mean it can't be or hasn't
been done. i would love to have the time to find/make one or even give you a
big fat Velocity patch to show you what i'm thinking, but i don't. as it is,
this debate is heavily taxing what free time i do have. also, as i've said in
the past, i don't see this as any sort of priority. there are more important
features on the average user's wish list (and mine). unless you've started to
"get it" :) and feel like putting in the elbow grease here for me/us, we
should probably shelve this for now. cool?
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: logging?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Saturday, October 25, 2003, at 08:35 PM, Nathan Bubna wrote:
> Geir Magnusson Jr. said:
>> On Saturday, October 25, 2003, at 05:04 PM, Nathan Bubna wrote:
>>> Geir Magnusson Jr. said:
>>>> On Saturday, October 25, 2003, at 11:53 AM, Nathan Bubna wrote:
> ...
>>> both their "generic" logging system and Velocity's own
>>> "generic" logging system are easy to implement redirection for.
>>>
>>> the issue is that they both serve the same purpose, and one is
>>> better.
>>> why
>>> should we continue to support/develop/maintain this LogSystem stuff
>>> when c-l
>>> is a better (and better maintained) implementation of the *same*
>>> concept?
>>
>> There's been almost zero work to do to support LogSystem - the only
>> thing I can recall is changing log4j support, to use Logger, and
>> ditching the old log4j impl.
>
> i must disagree. i count 12 Velocity logging issues open in bugzilla.
> several appear to be significant. at quick glance, all but one or two
> would
> be eliminated or significantly ameliorated were we to switch to
> commons-logging. almost zero work done does not mean almost zero work
> to do.
True.
>
>> The problem I have with c-l is that you, as the user of the component,
>> have no choice in the matter. You have to bring c-l.jar around even
>> if
>> you don't want any logging. That's why I advocate having an adapter -
>> then the user is in control - we aren't forcing anything on the user.
>
> good grief. did you hear me? commons-logging _*IS*_ an
> adapter!!!!!!!!!
Calm down. I meant an adapter to our core. That way you have a choice.
>
>> Then, it goes and grabs out of thin air the logger and goes to town.
>> You can't even tell c-l that you don't want something to be able to
>> log
>> on an instance by instance basis.
>
> huh? i have no idea what you are trying to say here. we are so very
> clearly
> not on the same page right now.
To make sure we're on the same page, I'll go re-read c-l docs to be
sure that I'm up-to-date. That's only fair. Things may have changed
since I stared at it hard.
What I was hinting at was how do you, in the same JVM, take two
instances of the same class (say velocity), and configure things so
they log differently?
Call it an academic, hypothetical question if you want... :)
Do you understand the difference between the pattern of having control
with each component, and having the component reach out into the
environment for it's logger? Sometimes the latter is preferential, but
many times it isn't. I know how to implement the latter with the
former, but not the reverse.
I dropped off the rest of the response not because it wasn't worth
answering (it was), but I want to get to the core issue, rather than
just discuss how I don't 'get it'. How would you propose we do this
w/o forcing our users to use c-l or abandon the pattern of control we
give them now?
That's the key for me. If you have an example of retaining control
using c-l, please point me to it.
geir
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: logging?
Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr. said:
> On Saturday, October 25, 2003, at 05:04 PM, Nathan Bubna wrote:
> > Geir Magnusson Jr. said:
> >> On Saturday, October 25, 2003, at 11:53 AM, Nathan Bubna wrote:
...
> > both their "generic" logging system and Velocity's own
> > "generic" logging system are easy to implement redirection for.
> >
> > the issue is that they both serve the same purpose, and one is better.
> > why
> > should we continue to support/develop/maintain this LogSystem stuff
> > when c-l
> > is a better (and better maintained) implementation of the *same*
> > concept?
>
> There's been almost zero work to do to support LogSystem - the only
> thing I can recall is changing log4j support, to use Logger, and
> ditching the old log4j impl.
i must disagree. i count 12 Velocity logging issues open in bugzilla.
several appear to be significant. at quick glance, all but one or two would
be eliminated or significantly ameliorated were we to switch to
commons-logging. almost zero work done does not mean almost zero work to do.
> The problem I have with c-l is that you, as the user of the component,
> have no choice in the matter. You have to bring c-l.jar around even if
> you don't want any logging. That's why I advocate having an adapter -
> then the user is in control - we aren't forcing anything on the user.
good grief. did you hear me? commons-logging _*IS*_ an adapter!!!!!!!!!
> Then, it goes and grabs out of thin air the logger and goes to town.
> You can't even tell c-l that you don't want something to be able to log
> on an instance by instance basis.
huh? i have no idea what you are trying to say here. we are so very clearly
not on the same page right now.
...
> Other than the recent note that it would be nice if we supported Logger
> in log4j, we haven't had to do anything. And when c-l became the new
> logging kid on the block, you were able to spend the same 3 minutes I
> did writing CloggerLogSystem impl... So your existing Velocity worked
> with the logging flavor of the month.
for the umpteenth time, the issue IS NOT getting Velocity to work with a
logger.
> > i really just
> > don't see the point of keeping it around to avoid having a dependency
> > on
> > another library. if Hibernate, Tomcat, Struts, and many commons
> > projects see
> > c-l as a very useful addition, i think that's worth taking note of.
>
> Yes, and it makes sense for Tomcat and Struts. I really do see good
> reasons why frameworks and containers would use it. I'm supposing
> that vel-tools uses it, but pray ever tool doesn't dictate the logging
> solution to the user.
VelocityView/Struts uses Velocity's LogSystem (with the ServletLogger by
default). the GenericTools do no logging, but due to the c-l/LogSystem
bridges i wrote, c-l is a compile time dependency. also, the "simple"
VelocityView example provides a one-line commons-logging.properties to
configure c-l to redirect messages from Digester to Velocity's LogSystem via
GenericTools' LogSystemCommonsLog.
that's the extent of c-l penetration thus far.
> However, I think it's a bad idea for Hibernate to use it, and I think
> many commons projects should definitely *NOT* be using it. Why?
i definitely disagree. i'm very thankful that things like digester use c-l.
> Ignoring the fact that I don't think every component and bean should be
> blathering log messages (that's the choice of the designer, but can't
> you just throw an exception?), if they do have the capability to log, I
> want the programmatic control of where or what they log. I want the
> choice of doing it locally or in my environmental config. If my class
> Foo is using a Bar that for some reason can log, I want Foo to be able
> to make the decision if the Bar logs, or at least have the option.
> With c-l, I don't see how I get that.
clearly you don't see it, but that doesn't mean it's not there! my
suggestion: in this hypothetical product, choose log4j as your logging
system, and configure c-l (and i do believe you can do this environmentally or
in your app) to feed messages to log4j (which gives *ample* control). or if
you don't want to see any c-l output, just don't configure it and it will
throw away all messages sent to it.
> Because c-l is so thin, I can't
> tell c-l that instance 1 of Foo can log, and instance 2 of Foo can't....
personally, i think you'd be a fool to use c-l as anything but an adapter to a
real logging system like log4j or logkit or jdk1.4 because c-l was designed
to be an adapter to such things, not a competitor to them.
...
> >> If this solves the problem for people that want to use, or have to use
> >> c-l, and we still give people the freedom to not use it, where's the
> >> rub?
> >
> > again, we're already "forcing" people to use a commons logging library
> > (cause
> > that's what LogSystem is!). if we used the "standard" c-l, then that
> > saves
> > the many people using projects that already use it (and plenty of
> > people do
> > use things like Hibernate, Tomcat, and other commons libraries) from
> > having to
> > also configure our LogSystem.
>
> ?
> >
> >> I don't get it.
yeah, i can tell. you're still not getting it. <sigh/>
...
> > the important thing to realize is that commons-logging and our
> > LogSystem stuff
> > fit the *same* problem space.
>
> 1) I don't buy that two different solutions shouldn't exist for the
> same problem. I'd be using WeMacro if I believed that. :)
of course, but there's a reason i don't use WebMacro.... Velocity is better.
:)similarly, i'd prefer to use c-l instead of LogSystem for the same reason.
> 2) The aren't the same solution. Ours give the user the choice.
huh?!? how does LogSystem give any more choice than c-l? the whole point of
c-l is to avoid locking users into a logging solution. it was designed
specifically to be a configurable adapter to various logging APIs in order to
give users the choice.
> 3) Just like JDK1.4 logging fit the same problem space as log4j, and
> commons-logging fits the same problem space as log4j.
look at the following link and then come back here and tell me again precisely
how you think commons-logging relates to log4j and what problem space they are
addressing.
http://jakarta.apache.org/commons/logging/apidocs/org/apache/commons/logging/package-summary.html
> I'm wondering if
> log4j will create a c-l like feature and eliminate the need. I'm
> hoping then you petition commons to deprecate c-l and support log4j :)
"I am not able rightly to apprehend the kind of confusion of ideas that could
provoke such a question." --Charles Babbage
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: logging?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Saturday, October 25, 2003, at 05:04 PM, Nathan Bubna wrote:
> Geir Magnusson Jr. said:
>> On Saturday, October 25, 2003, at 11:53 AM, Nathan Bubna wrote:
>>> been there. done that. and sorry, but no, it doesn't resolve the
>>> issue
>>> adequately. :)
>>>
>>
>> Why? Wouldn't this allow you to use Vel w/ c-l?
>
> the issue has never been "being able to use V w/c-l." (how's that for
> abbreviations! :)
That beats mine. Last time, I made a mistake on calling c-l
'commons-logger' and was corrected, so I figured I'd save time. My pet
name is 'clogger', of course :)
> both their "generic" logging system and Velocity's own
> "generic" logging system are easy to implement redirection for.
>
> the issue is that they both serve the same purpose, and one is better.
> why
> should we continue to support/develop/maintain this LogSystem stuff
> when c-l
> is a better (and better maintained) implementation of the *same*
> concept?
There's been almost zero work to do to support LogSystem - the only
thing I can recall is changing log4j support, to use Logger, and
ditching the old log4j impl.
The problem I have with c-l is that you, as the user of the component,
have no choice in the matter. You have to bring c-l.jar around even if
you don't want any logging. That's why I advocate having an adapter -
then the user is in control - we aren't forcing anything on the user.
Then, it goes and grabs out of thin air the logger and goes to town.
You can't even tell c-l that you don't want something to be able to log
on an instance by instance basis.
I am in no way a IoC partisan, but they are right on with things like
this.
>
> ...
>>> look at all the major projects using c-l. sometimes the mob is
>>> right.
>>
>> You haven't told me why this doesn't solve it. All you are saying is
>> that we aren't joining the mob, and it's somehow wrong to ignore the
>> mob.
>
>
> here in Velocity, we essentially have our own little commons-logging
> project
> that has less developer attention, a less useful/powerful API, and
> probably
> more outstanding bugs (i haven't actually looked though :).
Other than the recent note that it would be nice if we supported Logger
in log4j, we haven't had to do anything. And when c-l became the new
logging kid on the block, you were able to spend the same 3 minutes I
did writing CloggerLogSystem impl... So your existing Velocity worked
with the logging flavor of the month.
> i really just
> don't see the point of keeping it around to avoid having a dependency
> on
> another library. if Hibernate, Tomcat, Struts, and many commons
> projects see
> c-l as a very useful addition, i think that's worth taking note of.
Yes, and it makes sense for Tomcat and Struts. I really do see good
reasons why frameworks and containers would use it. I'm supposing
that vel-tools uses it, but pray ever tool doesn't dictate the logging
solution to the user.
However, I think it's a bad idea for Hibernate to use it, and I think
many commons projects should definitely *NOT* be using it. Why?
Ignoring the fact that I don't think every component and bean should be
blathering log messages (that's the choice of the designer, but can't
you just throw an exception?), if they do have the capability to log, I
want the programmatic control of where or what they log. I want the
choice of doing it locally or in my environmental config. If my class
Foo is using a Bar that for some reason can log, I want Foo to be able
to make the decision if the Bar logs, or at least have the option.
With c-l, I don't see how I get that. Because c-l is so thin, I can't
tell c-l that instance 1 of Foo can log, and instance 2 of Foo can't....
But if Foo was
public class Foo
{
setLog(FooLog foolog);
}
public interface FooLog {
...
}
Then I can make Foo do what I want, not what the Foo author thinks I
want. And if I was Foo author, I would include (you had to know this
was coming...)
public class CommonsLoggerFooLog implement FooLog {
...
}
:)
I even tried to get the c-l people to define a marker interface :
public interface CloggerLogger {
public void setLogger(Logger clogger);
}
So that you get IoC :
public class Foo implements CloggerLogger
{
setLogger(Logger clogger);
}
While this doesn't solve the dependency problem, I can at least make
components for which the logging is optional... the container
controls... Same thing, I guess.
>
>> If this solves the problem for people that want to use, or have to use
>> c-l, and we still give people the freedom to not use it, where's the
>> rub?
>
> again, we're already "forcing" people to use a commons logging library
> (cause
> that's what LogSystem is!). if we used the "standard" c-l, then that
> saves
> the many people using projects that already use it (and plenty of
> people do
> use things like Hibernate, Tomcat, and other commons libraries) from
> having to
> also configure our LogSystem.
?
>
>> I don't get it.
>
> that's ok. it happens to the best of us. ;)
>
> the important thing to realize is that commons-logging and our
> LogSystem stuff
> fit the *same* problem space.
1) I don't buy that two different solutions shouldn't exist for the
same problem. I'd be using WeMacro if I believed that. :)
2) The aren't the same solution. Ours give the user the choice.
3) Just like JDK1.4 logging fit the same problem space as log4j, and
commons-logging fits the same problem space as log4j. I'm wondering if
log4j will create a c-l like feature and eliminate the need. I'm
hoping then you petition commons to deprecate c-l and support log4j :)
geir
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: logging?
Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr. said:
> On Saturday, October 25, 2003, at 11:53 AM, Nathan Bubna wrote:
> > been there. done that. and sorry, but no, it doesn't resolve the
> > issue
> > adequately. :)
> >
>
> Why? Wouldn't this allow you to use Vel w/ c-l?
the issue has never been "being able to use V w/c-l." (how's that for
abbreviations! :) both their "generic" logging system and Velocity's own
"generic" logging system are easy to implement redirection for.
the issue is that they both serve the same purpose, and one is better. why
should we continue to support/develop/maintain this LogSystem stuff when c-l
is a better (and better maintained) implementation of the *same* concept?
...
> > look at all the major projects using c-l. sometimes the mob is right.
>
> You haven't told me why this doesn't solve it. All you are saying is
> that we aren't joining the mob, and it's somehow wrong to ignore the
> mob.
here in Velocity, we essentially have our own little commons-logging project
that has less developer attention, a less useful/powerful API, and probably
more outstanding bugs (i haven't actually looked though :). i really just
don't see the point of keeping it around to avoid having a dependency on
another library. if Hibernate, Tomcat, Struts, and many commons projects see
c-l as a very useful addition, i think that's worth taking note of.
> If this solves the problem for people that want to use, or have to use
> c-l, and we still give people the freedom to not use it, where's the
> rub?
again, we're already "forcing" people to use a commons logging library (cause
that's what LogSystem is!). if we used the "standard" c-l, then that saves
the many people using projects that already use it (and plenty of people do
use things like Hibernate, Tomcat, and other commons libraries) from having to
also configure our LogSystem.
> I don't get it.
that's ok. it happens to the best of us. ;)
the important thing to realize is that commons-logging and our LogSystem stuff
fit the *same* problem space. they *both* exist to avoid tying those using
projects into a particular logging system (like log4j, logkit, jdk1.4, etc) by
providing a generic interface into a common subset of the features of "real"
logging solutions. once you get that, the rest becomes clearer.
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: logging?
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Saturday, October 25, 2003, at 11:53 AM, Nathan Bubna wrote:
> been there. done that. and sorry, but no, it doesn't resolve the
> issue
> adequately. :)
>
Why? Wouldn't this allow you to use Vel w/ c-l?
> IMO, LogSystem *IS* a commons-logging library. it's just smaller and
> less
> useful than the standard c-l. we should use the better system. share
> effort.
> if you hate dependencies so much, let's just import the latest c-l code
> directly into Velocity as a superior replacement for LogSystem. (note
> that i
> don't actually want to do that, i'm just trying to make a point.
I wouldn't want to do that either. Eek.
>
> look at all the major projects using c-l. sometimes the mob is right.
You haven't told me why this doesn't solve it. All you are saying is
that we aren't joining the mob, and it's somehow wrong to ignore the
mob.
If this solves the problem for people that want to use, or have to use
c-l, and we still give people the freedom to not use it, where's the
rub? I don't get it.
geir
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: logging?
Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr. said:
> On Tuesday, September 2, 2003, at 11:59 AM, Nathan Bubna wrote:
> > Henning P. Schmiedehausen said:
> >> Did we get any consensus on this matter? Or did the discussion just
> >> abruptly die?
> >
> > appearances indicate the latter. <sigh/>
>
> Out of idle curiosity, and utter resentment for c-l having been forced
> to drag that into a project due to Hibernate,
...
> I wanted to see if we could make everyone happy w/o tying in another
> dependency. Here's an example LogSystem implementation to work with
> c-l. I'm not going to commit this w/o discussion. Does this address
> the issue adequately?
>
...
<wheel action="reinvent">
> /**
> * Commons-logging LogSystem adapter. Can we call it the
> *
> * CloggingLogSystem?
> *
> * @author <a href="mailto:geirm@optonline.net">Geir Magnusson Jr.</a>
> * @version $Id: $
> */
> public class CommonsLoggingLogSystem implements LogSystem
> {
...
</wheel>
http://cvs.apache.org/viewcvs.cgi/jakarta-velocity-tools/src/java/org/apache/velocity/tools/generic/log/
been there. done that. and sorry, but no, it doesn't resolve the issue
adequately. :)
IMO, LogSystem *IS* a commons-logging library. it's just smaller and less
useful than the standard c-l. we should use the better system. share effort.
if you hate dependencies so much, let's just import the latest c-l code
directly into Velocity as a superior replacement for LogSystem. (note that i
don't actually want to do that, i'm just trying to make a point.
look at all the major projects using c-l. sometimes the mob is right.
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org