And #2 will prepare the transition of the core to commons-logging ;-) CloD
----- Original Message ----- From: "Nathan Bubna" <[EMAIL PROTECTED]> To: "Velocity Developers List" <[EMAIL PROTECTED]> Sent: Friday, June 25, 2004 9:40 PM Subject: Re: [veltools] of singletons and (un)common logs > Geir Magnusson Jr said: > > On Jun 14, 2004, at 10:58 AM, Nathan Bubna wrote: > > > Claude Brisson said: > > >> 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 ? > > > > > > no, i feel pretty strongly that configuring/redirecting c-l output is > > > not > > > something that a component (e.g. veltools) should take upon itself. > > > > That's exactly right. CL is feature incomplete in this way, IMO, > > because you implicitly couple the logging behavior of separate systems > > that use it. > > well, separate components that use it in the same classloader/application. :) > anyway, it is a good point, but i must say, if you point CL to use log4j it is > typically fairly easy to decouple the logging behavior of the separate systems > via configuration. but again, if you don't want all your components to log in > the same place by default (not sure how many people want that) then it is > definitely an area that CL is lacking in. :) > > > > if we take this option, then the user would have to configure c-l to use > > > LogSystemCommonsLog on their own. the most we could do is have the > > > VVS tell > > > the LogSystemCommonsLog to use its particular VelocityEngine for all > > > output > > > (instead of the singleton) just in case the user decides to point c-l > > > in that direction. > > > > > >> Otherwise, I guess #3 is okay, it is more or less unavoidable to > > >> have chained logging adapters when using several packages. > > > ... > > > > > > yeah, it's okay, and i did get a test of this option working. but > > > after > > > trying it out, i think i like #2 a wee bit more. > > > > Can you say why? I thought about the three options, and while I do > > like #1 if you did it w/ magic - i.e. suppose you used annotations in > > the same way that EJB3 was using them, to declare dependencies for > > injection :) - it could be burdensome. > > that stuff about "magic" annotations and EJB3 is over my head. if you think > you can make option #1 (passing velocity engines around) work well, then feel > free to demonstrate. :) > > anyway, i like #2 a wee bit more because VelocityTools already uses Struts and > Digester which already use "clogging" (nothing to do with wooden shoes :). i > can't imagine those will be changing that anytime soon, so it just kinda makes > sense to me to do the same. besides... > > > #3 means that you can then attach to either the Vel core logging, or > > clogging, or LogSystemOfTheMonth2005 or whatever. However, this means > > that things are getting a bit framework-ish. However, things are > > already framework-ish w/ the toolbox mechanisms.... > > with option #2 (just using CL in veltools), you will still be able to attach > to either Vel core logging orLogSystemOfTheMonth2005 or whatever (remember, CL > is a good adapter). functionally, the only difference between option #2 and > #3 is that the default behavior in #3 would be to log to the VVS's > VelocityEngine which is configured by default to log to the servlet context's > log (pretty much the current behavior), whereas #2 would require the user to > point CL to use LogSystemCommonsLog if they wanted that behavior. > > my guess is that users who really care about logging already do custom > configuration, because let's face it, having everything shoved into tomcat's > log file isn't really ideal. so i don't think #2 would be very inconvenient. > > apart from functional difference between #2 and #3, the burden on veltools > developers (mostly Marino and i) is significantly different. #3 requires > reinventing a wheel and maintaining code that's not really pertinent to the > core competencies of VelocityTools. #2, on the other hand, is pretty darn > easy and familiar to us both. so naturally, that's the one we prefer. > > and since there's been so little response to this thread, and no serious > objections to #2 so far, i'm planning to try and get that in in the next week. > if you have serious objections, please make them soon so we can hash things > out aforehand and not have to rollback commits. > > 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]
