ok, so i said i'd find some time this weekend to finish developing/testing
changes that would allow VelocityTools to stop being dependent on the Velocity
singleton. well, i've done that, and it works. the catch is that it involves
some significant changes to both the current design of things and their
behavior, especially with regard to logging. here's the deal...
if we stop using the singleton for rendering, we must stop using it for
logging. if we stop using it for logging, then many different tools and
classes no longer have static access to a logging mechanism. therefore we
must provide them a new means of access to a logging facility. there are
three options i see here:
- provide a means for those tools/classes to be passed the current
VelocityEngine for logging and make them run silent so long as they aren't
given one.
- convert VelocityTools to use commons-logging and adapt the
LogSystemCommonsLog to work so that users can still direct some or all
commons-logging output into Velocity's log system (either singleton or an
engine) if they want.
- implement our own mini-log adapter/system w/static access to loggers and
ability to register a VelocityEngine(s) to handle output or pass things on to
commons-logging (or maybe the singleton too).
Here's my thoughts on the three options:
- the first sucks. i think it would be a pain to implement and obnoxious
to use. also most of the tools/classes would have no other use for a
VelocityEngine. it's total overkill to pass those around just for logging.
- the second sounds good to me. in fact, i've already implemented and
tested this out. it works just dandy. however there are certain folks around
here that are very anti-commons-logging and pro-IoC that will probably find
this distasteful because c-l would be the default target for output. Users
would have to configure c-l to redirect output to LogSystemsCommonsLog on
their own if they wanted veltools log output to go thru Velocity's log system.
- i just thought of this third one while writing this email. from a
veltools developer standpoint, it would be as easy to use as the second
option. also, it shouldn't be too hard to write (i may just give it a try
after sending this). the big difference between it and the second option is
that it would allow the default logging system for veltools to still be
Velocity's LogSystem. the downside here is that this would pretty much be
YALA/S (yet-another-logging-adapter/system).
To recap:
- option one maintains current behavior but is overkill and a PITA for
veltools developers
- option two is convenient for veltools dev (and already
implemented/tested), but changes default behavior by making c-l the default
log thingy, not Velocity's LogSystem
- option three is undeveloped/tested but should be convenient for veltools
dev and maintain the current default behavior. downside is that it'll be
YALA/S
ok, i think i'll try and whip out an implementation of #3, but in the
meantime, feedback would be appreciated. there are some other smaller issues
involved in the singleton->engine switch, but this one most needs discussion.
oh, and please keep this thread focused on the issue at hand. i really don't
want to start another huge discussion about what to do with logging in the
Velocity core, because even if the core logging stuff was updated tomorrow, i
would still want to solve this problem in a way that maintains compatibility
with versions 1.3.1 and 1.4(.x). i'm not ready to make VelocityTools
dependent on the latest, greatest, and especially non-existent versions of
Velocity so for this thread, issues with core logging are moot. just don't go
there. :) thanks.
Nathan Bubna
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
