Since there are big chances that all the instances do log to the same place, option #1 is definitely not a good choice. Should option #2 or #3 be choosen, it is important to have a static access to logging.
With #2, can't you have c-l default configuration redirecting towards the Velocity log ? Otherwise, I guess #3 is okay, it is more or less unavoidable to have chained logging adapters when using several packages. Claude ----- Original Message ----- From: "Nathan Bubna" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, June 12, 2004 7:32 PM Subject: [veltools] of singletons and (un)common logs > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
