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]
