Re: [veltools] of singletons and (un)common logs

[Claude Brisson <cl...@savoirweb.com>]

And #2 will prepare the transition of the core to commons-logging ;-)

CloD

----- Original Message ----- 
From: "Nathan Bubna" <na...@esha.com>
To: "Velocity Developers List" <ve...@jakarta.apache.org>
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
> nathan@esha.com
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org