On Tue, Jun 29, 2010 at 8:04 AM, Antonio Petrelli <antonio.petre...@gmail.com> wrote: > 2010/6/29 Nathan Bubna <nbu...@gmail.com>: ... >> Velocity is not a development framework. It is an >> oft-embedded component. > > Sorry? I thought it was a template engine...
yes, a template engine is (or should be) more of a component for use within a larger framework. it does not provide structure around which to build your apps, but rather a tool to use within your structure. It actually has more in common with JSTL than JSP. >> 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? Yes, it is not uncommon for users to have multiple instances of VelocityEngine that serve significantly different purposes (email, documentation, web pages, code generation, etc). This also distinguishes component from framework. It doesn't make much sense to have multiple Struts instances (or even VelocityView instances), but it is common to have multiple VelocityEngine instances. Velocity was originally created as a singleton, until it was quickly realized that this was a huge drawback for integration and diverse usage. >> 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. No. Users should not have to select a different build of Velocity for different logging purposes. That's totally overkill. If Maven can't understand dependencies that are required-for-compilation-but-optional-at-runtime, then it will never work as our build tool. >> 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. Ok, if we convert Velocity logging to be static, then how do i configure either of those to mix my log messages into my servlet log files for my web-page server and not log anything from my email-generating instance? >> 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. Lovely. Am i supposed to care that you disagree with the way i personally configure my apps? And this is the default setting for all VelocityView-based applications (both Tools 1.x and 2.x). So, it's not something we're about to get rid of. :) >> 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. not at all! what is logging if not the recording of events? every popular logging utility out there tries to provide ways to listen to some events and not others, trying to generically categorize them by "level" or provide means to filter events by "category". logging is and always has been an obvious subset of event/subscriber activity, and it would be better done if people thought of it that way more often. > 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. i don't know that Velocity's range of events warrants separate event classes; perhaps, but i'm skeptical. and no, loggers would simple be a specific type of listener provided for users' convenience. > 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). i can concieve of no reason why they are or should be separate things. it seems like a very arbitrary and artificial distinction. can you explain? >>... 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? :-) i believe so, but neither i nor anyone else has written it yet, so who can be sure? > 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. No, they both are statically configured (complicating multiple instance situations and making injectability unpleasant if not impossible), neither has an easy bridge to the servlet log, and many of our users care nothing at all for Velocity log messages and will be irked that they have to drag along another library that does not serve them. > And with Maven adding a dependency is really easy, don't think as you > are working with Ant. It is debatable whether that is a useful feature. :) > The dependencies that I would like to remove are others (oro, > commons-collections, not sure on commons-lang), but I will discuss it > later. YES! oro definitely MUST go in 2.0. and i agree that collections and lang are of questionable utility. eliminating dependency on them is worth looking into. > 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: dev-unsubscr...@velocity.apache.org > For additional commands, e-mail: dev-h...@velocity.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
