2010/6/29 Nathan Bubna <[email protected]>: > I think the Logkit stuff can go. That's pretty unpopular at this point.
Ok. > Velocity is not a development framework. It is an > oft-embedded component. Sorry? I thought it was a template engine... > Logging should be optional and injectable, > something people use when debugging and can control per-instance, not > just statically. Can you elaborate on this? Do you mean that, if you have two instances of a class, you want two different log messages? > It might seem like we have a lot of "dependencies" > that are only used for one little logging class. But these are all > optional at runtime. With Maven I can create different modules, so dependencies are not optional, but you have to select the correct module you want. > So the end result is a smaller number of > dependencies and freedom for those who wish to see logs to get them > wherever is convenient. In my experience, the best place to see log messages is in log files. Anyway *where* the log should go is easily configurable with Log4j or JDK 1.4 logger. > Personally, i find the ServletLogChute to be > the most convenient, as servlet logs are a great place for "exuberant" > logging output to be controlled. I disagree, I've never seen using ServletContext.log in any project, defaulting to a logging system. > If we move to static logging, we give up logger injectability and > freedom to leave out all logging dependencies. I've become rather > fond of both, and i think a few small classes and compile-time-only > dependencies are a small price to pay for those. > > If anything, the future i see for "logging" in Velocity is a move to > an event/subscriber model, where users could subscribe to certain > types of events (and not others). For a component like this, > organizing debugging output by "event type" makes more sense than > organizing it by super-imposed log-levels. We would still, however, > want to provide some convenient subscribers that would log chosen > events with the usual logging facilities. So those compile time > dependencies are not likely to go anywhere. See the 2nd-to-last > comment in https://issues.apache.org/jira/browse/VELOCITY-168 for the > source of this idea. I think that you are mixing the ideas of "logging" and "event producing and consuming": log messages are not events, while events do not need to be logged. These are orthogonal topics. If "log chute" and similar classes intended to be event listeners, then let's transform into event listeners, creating event classes etc. You're right, this could be a powerful feature to inject listeners. But they are not loggers, I would like to keep them separate. Typical example (for which I see some abuse, like not following the "fail-fast" best practice, but I will address it later) is logging an exception: logging an exception with a particular message is OK, creating an event to inform that an exception occurred is OK too, but they are separate (IMHO). >... and > would very much not like to see support for things like logging to the > servlet log or leaving out all logging dependencies disappear. :) If this "logging" capability turns into an "publish-subscribe", "event producer - event listener" , will you still like it? :-) About the dependencies, I think that adding a simple dependency to commons-logging (or slf4j-api) is not overkill, since these are widely accepted wrapping logging frameworks. With slf4j you can easily plugin in your preferred logging framework, by adding a dependency in your application. And with Maven adding a dependency is really easy, don't think as you are working with Ant. The dependencies that I would like to remove are others (oro, commons-collections, not sure on commons-lang), but I will discuss it later. Thanks Antonio P.S.: At this point I will create more modules, to let the dependencies be as clear as possible. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
