You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Nathan Bubna <na...@esha.com> on 2004/06/12 19:32:57 UTC
[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
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [veltools] of singletons and (un)common logs
Posted by 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
Re: [veltools] of singletons and (un)common logs
Posted by Nathan Bubna <na...@esha.com>.
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
Re: [veltools] of singletons and (un)common logs
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
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.
> 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.
#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....
geir
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [veltools] of singletons and (un)common logs
Posted by Nathan Bubna <na...@esha.com>.
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. 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.
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
Re: [veltools] of singletons and (un)common logs
Posted by Claude Brisson <cl...@savoirweb.com>.
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" <na...@esha.com>
To: <ve...@jakarta.apache.org>
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
> 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