You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Daniel Rall <dl...@finemaltcoding.com> on 2003/08/23 01:39:12 UTC
Re: DO NOT REPLY [Bug 19140] - RFE: switch to commons-logging
"Henning P. Schmiedehausen" <hp...@intermeta.de> writes:
> Kasper Nielsen <ne...@kav.dk> writes:
> [...]
>
> Ceki tried to pull off the same thing when we converted Turbine to
> commons-logging and IMHO the only real alternative to this step
> would've been converting to avalon logging.
>
> By not pulling in a middle layer we would have locked ourselves into
> an (open-source) product which is underdocumented and the only real
> docs available are for money. So our alternative for Turbine would've
> been either Avalon or "JDK 1.4 logging and no log4j at all".
>
> In the end, most of the points in the paper you've cited are moot, if
> you look at the links that he gives, you'll see that these people
> simply didn't understand the role of c-l and log4j or were not able to
> set up a root logger which you will have to do with pure log4j
> too. And "where to put the log4j jar?" is simply pathetic with todays
> servlet containers which are able to separate out the class pathes.
>
> We've converted Turbine to commons-logging in the currently running
> 2.3-dev cycle and as far as I can see, all of the early adopters are
> really happy that we have a consistent and working logging all over
> the application for the first time since Turbine inception. ATM we
> spawn off Velocity with a preset logger so that it integrates into our
> logging framework and at last I (I can't, won't and don't speak for
> the whole Turbine team) would wholeheartedly welcome the conversion of
> Velocity to commons-logging. It would fit even better together with
> Turbine.
I pretty much agree with Henning's summary here.
--
Daniel Rall
Re: DO NOT REPLY [Bug 19140] - RFE: switch to commons-logging
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Geir Magnusson Jr." <ge...@adeptra.com> writes:
>What if I want to take advantage of log4j specific API's? Or levels?
>or...
What if you're locked into log4j and need to use Velocity in an application
that uses jdk14 logging all over the place?
Of course c-l has levels. And you can use all the stuff like
categories, different log files, different appenders and so on. c-l is
basically the adapter that you propose.
[...]
>"Hey bob! it's wednesday! Lets switch to jdk1.4 logging! it's just
>like log4j, but different!"
If you're not interested in a real discussion but simply dictate "we
won't switch", then tell us. I won't waste my breath argueing if
you're not interested.
[...]
>1) You claimed the approach turbine uses is inefficient. How?
You're putting words in my mouth. The Turbine approach itself is quite
streamlined. However, we have to jump through hoops to make velocity
logging behave like the rest of Turbine. This is an aching wart, yes.
>2) if we made velocity's logger be discoverable via the c-l discovery
>mechanism, would that help? That way Turbine gets what it wants, and
>people who don't want to use c-l get what they want?
"Heh Bob, look: Adapters on adapters on adapters. This is exactly the
efficient programming for which Java is sooo famous."
Face it: Though noone really liked Mr. Revusky, he's was right in one
point: Velocity is a quite old code base which hasn't seen many
changes in the year or so. Technology and especially the commons stuff
of Jakarta really took off and has many really cool things like
commons-logging, commons-collections, commons-lang or
commons-configuration. Many of these are duplicated and badly in the
Velocity core. Some of the commons stuff was rooted in the velocity
code but got continuously developed while Velocity stood still. Why
simply use this and get a huge development boost for free.
Adding another adapter makes me seriously thinking about what you and
Jon did when you decided that Webmacro won't cut the cake: Take the
Velocity Code base and simply fork off. This would be the worst thing
for all of us.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
Re: DO NOT REPLY [Bug 19140] - RFE: switch to commons-logging
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Peter Ryan" <pe...@peterryan.net> writes:
>I think that Geir raises a valid point...By depending on c-l (or any
>logger for that matter) the dependency list for velocity increases and the
>barebones run of velocity now requires commons-logging.jar. In my mind the
>less 3rd party libraries "absolutely required" the better.
Along this way lies madness and reimplementing the wheel in a thousand
different classes in every single jar.
Reusage and especially the use of freely available and distributable
components is IMHO the way to go. jakarta commons is exactly intended for
this.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
Re: DO NOT REPLY [Bug 19140] - RFE: switch to commons-logging
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Jeff Schnitzer <je...@infohazard.org> writes:
>I see this debate in very simple terms:
>Is it worth the price of adding one dependency jar
>in order to replace the Velocity-proprietary logging
>abstraction API with a relatively standard and well-
>supported logging abstraction API?
>IMHO, yes. If you're going to have an abstraction,
>you might as well use a standard one.
+1
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
Re: DO NOT REPLY [Bug 19140] - RFE: switch to commons-logging
Posted by Jeff Schnitzer <je...@infohazard.org>.
I see this debate in very simple terms:
Is it worth the price of adding one dependency jar
in order to replace the Velocity-proprietary logging
abstraction API with a relatively standard and well-
supported logging abstraction API?
IMHO, yes. If you're going to have an abstraction,
you might as well use a standard one.
Jeff Schnitzer
jeff@infohazard.org
Re: DO NOT REPLY [Bug 19140] - RFE: switch to commons-logging
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Nathan Bubna" <na...@esha.com> writes:
>> YES - implement a velocity -> c-l bridge.
>this has been done in both Turbine and Velocity-Tools.
No. Turbine simply forces Velocity to use our underlying log4j system.
org.apache.turbine.services.velocity.TurbineVelocityService::initVelocity()
[...]
Configuration conf = getConfiguration();
conf.setProperty(Velocity.RUNTIME_LOG_LOGSYSTEM_CLASS,
SimpleLog4JLogSystem.class.getName());
conf.setProperty(Velocity.RUNTIME_LOG_LOGSYSTEM
+ ".log4j.category", "velocity");
Velocity.setExtendedProperties(createVelocityProperties(conf));
Velocity.init();
[...]
Retrofitting this onto c-l seemed absurd to me. :-)
Regards
Henning
>> YES - Still have have an internal logger that writes to c-l that can
>> default to a DefaultLogger
>c-l has a "default logger" too. (SimpleLog)
>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
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
Re: DO NOT REPLY [Bug 19140] - RFE: switch to commons-logging
Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr said:
> On Tuesday, August 26, 2003, at 09:14 PM, Nathan Bubna wrote:
> > Peter Ryan said:
> > ...
> > yeah, this is a fair point. but velocity has (at least as long as
> > i've been
> > around) provided a jar that includes the classes of it's 3rd party
> > dependencies (ORO, commons-collections, etc.). would it be so bad to
> > drop the
> > current log classes included therein (and i see quite a few in those
> > velocity-*-dep.jar files) in favor of the whopping 12 classes in
> > commons-logging?
>
> Well, providing that stuff in the vel.jar was and is a Bad Thing. Most
> people don't get nailed by it, but when you have version conflicts, we
> don't make friends when you have to de-jar vel.jar to see that we
> including a version of commons-collections. (and we only have
> commons-collections because we contributed some vel code to it in the
> spirit of getting things started there, and was good to eat our own dog
> food.)
agreed. keeping the dependencies in the same jar is not good practice.
however, when we're not distributing a velocity-*-dep.jar, i'm sure our binary
distributions (of the tar.gz and zip persuasions) will probably contain the
various dependency jars for convenience. is it really that big a PITA to
include commons-logging with commons-collections and ORO? it's just one more
file and it's probably smaller than all the current logging files that come
with velocity (haven't confirmed that though).
...
> > why carry the burden of
> > maintaining a logger agnostic system ourselves?
>
> No one has had to touch it for years now. The issue isn't a logging
> system that's a bear to work with and maintain, but it doesn't
> plug-n-play with c-l, right?
no one has touched it, but it does need touching! see bugs 9039, 9799, 9937,
18636, 19133, 19137, and 21720.
...
> >> So...
> >>
> >> YES - implement a velocity -> c-l bridge.
> >
> > this has been done in both Turbine and Velocity-Tools.
>
> So why not roll it into velocity, and then it's just a config setting
yeah, that's a step in the right direction, and it's the least that should be
done. but i still don't think it's the best solution (certainly not long
term, but maybe not short term either).
Nathan Bubna
nathan@esha.com
Re: DO NOT REPLY [Bug 19140] - RFE: switch to commons-logging
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On Tuesday, August 26, 2003, at 09:14 PM, Nathan Bubna wrote:
> Peter Ryan said:
> ...
>> I think that Geir raises a valid point...By depending on c-l (or any
>> logger for that matter) the dependency list for velocity increases
>> and the
>> barebones run of velocity now requires commons-logging.jar. In my
>> mind the
>> less 3rd party libraries "absolutely required" the better.
>
> ah. thanks, my confusion is lessened. so, it's having a new 3rd party
> dependency that is the issue. my brain didn't translate "force to use
> c-l" as
> "force to include Yet Another Library." i've caffeinated myself since
> my last
> email and feel much better, thank you. :)
>
Caffine is good.
> yeah, this is a fair point. but velocity has (at least as long as
> i've been
> around) provided a jar that includes the classes of it's 3rd party
> dependencies (ORO, commons-collections, etc.). would it be so bad to
> drop the
> current log classes included therein (and i see quite a few in those
> velocity-*-dep.jar files) in favor of the whopping 12 classes in
> commons-logging?
Well, providing that stuff in the vel.jar was and is a Bad Thing. Most
people don't get nailed by it, but when you have version conflicts, we
don't make friends when you have to de-jar vel.jar to see that we
including a version of commons-collections. (and we only have
commons-collections because we contributed some vel code to it in the
spirit of getting things started there, and was good to eat our own dog
food.)
While that solution would work, I don't think making the problem worse
is something we want to do.
>
>> In my mind a better mechanism would be to support c-l by specifying
>> it. If
>> there is some fun detection scheme for c-l, log4j, avalon, jdk1.4,
>> blah
>> blah then have one that makes sense and is properly documented. If a
>> logger is not specified or available the internal velocity LogSystem
>> gets
>> used. By sticking to an internal LogSystem that can be managed by
>> external
>> loggers through configuration flexibility is maximized. Defaulting to
>> c-l
>> (it is fashionable afterall) should be determined by the priority of
>> loggers.
>
> flexibility *may* be maximized (though i'm not entirely ready to
> concede
> that), but power (API richness) and speed (is<Priority>Enabled()
> functions)
> are not. also, c-l is far more actively maintained. why carry the
> burden of
> maintaining a logger agnostic system ourselves?
No one has had to touch it for years now. The issue isn't a logging
system that's a bear to work with and maintain, but it doesn't
plug-n-play with c-l, right?
>
>> By directly mapping to c-l without an internal LogSystem c-l becomes a
>> dependency, albeit an "ultra-thin" one.
>>
>> So...
>>
>> YES - implement a velocity -> c-l bridge.
>
> this has been done in both Turbine and Velocity-Tools.
So why not roll it into velocity, and then it's just a config setting
>
>> YES - Still have have an internal logger that writes to c-l that can
>> default to a DefaultLogger
>
> c-l has a "default logger" too. (SimpleLog)
>
> 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
>
>
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-434-2093(m)
geirm@adeptra.com 203-247-1713(m)
Re: DO NOT REPLY [Bug 19140] - RFE: switch to commons-logging
Posted by Nathan Bubna <na...@esha.com>.
Peter Ryan said:
...
> I think that Geir raises a valid point...By depending on c-l (or any
> logger for that matter) the dependency list for velocity increases and the
> barebones run of velocity now requires commons-logging.jar. In my mind the
> less 3rd party libraries "absolutely required" the better.
ah. thanks, my confusion is lessened. so, it's having a new 3rd party
dependency that is the issue. my brain didn't translate "force to use c-l" as
"force to include Yet Another Library." i've caffeinated myself since my last
email and feel much better, thank you. :)
yeah, this is a fair point. but velocity has (at least as long as i've been
around) provided a jar that includes the classes of it's 3rd party
dependencies (ORO, commons-collections, etc.). would it be so bad to drop the
current log classes included therein (and i see quite a few in those
velocity-*-dep.jar files) in favor of the whopping 12 classes in
commons-logging?
> In my mind a better mechanism would be to support c-l by specifying it. If
> there is some fun detection scheme for c-l, log4j, avalon, jdk1.4, blah
> blah then have one that makes sense and is properly documented. If a
> logger is not specified or available the internal velocity LogSystem gets
> used. By sticking to an internal LogSystem that can be managed by external
> loggers through configuration flexibility is maximized. Defaulting to c-l
> (it is fashionable afterall) should be determined by the priority of
> loggers.
flexibility *may* be maximized (though i'm not entirely ready to concede
that), but power (API richness) and speed (is<Priority>Enabled() functions)
are not. also, c-l is far more actively maintained. why carry the burden of
maintaining a logger agnostic system ourselves?
> By directly mapping to c-l without an internal LogSystem c-l becomes a
> dependency, albeit an "ultra-thin" one.
>
> So...
>
> YES - implement a velocity -> c-l bridge.
this has been done in both Turbine and Velocity-Tools.
> YES - Still have have an internal logger that writes to c-l that can
> default to a DefaultLogger
c-l has a "default logger" too. (SimpleLog)
Nathan Bubna
nathan@esha.com
Re: DO NOT REPLY [Bug 19140] - RFE: switch to commons-logging
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On Tuesday, August 26, 2003, at 07:42 PM, Peter Ryan wrote:
> Geir Magnusson Jr. said:
>>> i agree. c-l is pretty much the lowest common denominator. but it's
>>> API is
>>> still far richer than that of velocity's LogSystem! what we're
>>> lobbying for
>>> here is merely a switch from one logger agnostic system to a richer
>>> and more
>>> actively maintained logger agnostic system. what is there that
>>> velocity's
>>> LogSystem offers that c-l does not?
>>
>> What I'm suggesting is that we make velocity work with CL via an
>> adapter, so the the C-L crowd can use it if they want, but we don't
>> shove the requirement to use c-l down everyone else's throat.
>>
>> I'm not claiming that velocity's logsystem is grand. It's just that
>> the user has the freedom to do what they want.
>>
>
> Ooo a logging debate...can't stay out of this. You should see the
> proprietary log framework i get to use at my current client. :P
>
> I think that Geir raises a valid point...By depending on c-l (or any
> logger for that matter) the dependency list for velocity increases and
> the
> barebones run of velocity now requires commons-logging.jar. In my mind
> the
> less 3rd party libraries "absolutely required" the better.
>
> In my mind a better mechanism would be to support c-l by specifying
> it. If
> there is some fun detection scheme for c-l, log4j, avalon, jdk1.4, blah
> blah then have one that makes sense and is properly documented. If a
> logger is not specified or available the internal velocity LogSystem
> gets
> used. By sticking to an internal LogSystem that can be managed by
> external
> loggers through configuration flexibility is maximized. Defaulting to
> c-l
> (it is fashionable afterall) should be determined by the priority of
> loggers.
This is what I was trying to say, I think. Right now, we'll search for
logkit or log4j in the classpath, yet don't require that the user have
them both available and in the classpath. If we did the same for c-l,
thus supporting c-l users w/o requiring it of all users, then I think
we all win.
geir
>
> By directly mapping to c-l without an internal LogSystem c-l becomes a
> dependency, albeit an "ultra-thin" one.
>
> So...
>
> YES - implement a velocity -> c-l bridge.
> YES - Still have have an internal logger that writes to c-l that can
> default to a DefaultLogger
>
> Peter
>
>
>
>
>
>>
>>>
>>> ...
>>>>> Turbine uses c-l but configures it to actually log via log4j so we
>>>>> have a strong preference here for log4j. But there is no problem
>>>>> configuring it to use e.g. JDK1.4 logging.
>>>>
>>>> Serious question : Do you know anyone who switches?
>>>
>>> i don't think it's really about people being able to switch.
>>
>> I know. I just think the idea is funny.
>>
>>> it's *still*
>>> about letting Person A use velocity with log4j and Person B use
>>> velocity with
>>> JDK 1.4 logging, and Person C use.... c-l is just a better way of
>>> doing that
>>> than the current system we have.
>>
>> Right now, people can use whatever logger they want, or no logger. I
>> like the idea of a logger-free component. (For example, hasn't anyone
>> besides me jumped up and down wondering why HttpClient needs a
>> logger?)
>>
>> So lets boil it down to the requirement. Is it
>>
>> a) We want Velocity to use commons-logger
>> b) We want Velocity users that use commons-logger to easily use
>> velocity with that logging system.
>>
>> (And what if I want to use Vel w/o c-l? Then what?)
>>
>> geir
>>
>> --
>> Geir Magnusson Jr 203-956-2604(w)
>> Adeptra, Inc. 203-434-2093(m)
>> geirm@adeptra.com 203-247-1713(m)
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-434-2093(m)
geirm@adeptra.com 203-247-1713(m)
Re: DO NOT REPLY [Bug 19140] - RFE: switch to commons-logging
Posted by Peter Ryan <pe...@peterryan.net>.
Geir Magnusson Jr. said:
>> i agree. c-l is pretty much the lowest common denominator. but it's
>> API is
>> still far richer than that of velocity's LogSystem! what we're
>> lobbying for
>> here is merely a switch from one logger agnostic system to a richer
>> and more
>> actively maintained logger agnostic system. what is there that
>> velocity's
>> LogSystem offers that c-l does not?
>
> What I'm suggesting is that we make velocity work with CL via an
> adapter, so the the C-L crowd can use it if they want, but we don't
> shove the requirement to use c-l down everyone else's throat.
>
> I'm not claiming that velocity's logsystem is grand. It's just that
> the user has the freedom to do what they want.
>
Ooo a logging debate...can't stay out of this. You should see the
proprietary log framework i get to use at my current client. :P
I think that Geir raises a valid point...By depending on c-l (or any
logger for that matter) the dependency list for velocity increases and the
barebones run of velocity now requires commons-logging.jar. In my mind the
less 3rd party libraries "absolutely required" the better.
In my mind a better mechanism would be to support c-l by specifying it. If
there is some fun detection scheme for c-l, log4j, avalon, jdk1.4, blah
blah then have one that makes sense and is properly documented. If a
logger is not specified or available the internal velocity LogSystem gets
used. By sticking to an internal LogSystem that can be managed by external
loggers through configuration flexibility is maximized. Defaulting to c-l
(it is fashionable afterall) should be determined by the priority of
loggers.
By directly mapping to c-l without an internal LogSystem c-l becomes a
dependency, albeit an "ultra-thin" one.
So...
YES - implement a velocity -> c-l bridge.
YES - Still have have an internal logger that writes to c-l that can
default to a DefaultLogger
Peter
>
>>
>> ...
>>>> Turbine uses c-l but configures it to actually log via log4j so we
>>>> have a strong preference here for log4j. But there is no problem
>>>> configuring it to use e.g. JDK1.4 logging.
>>>
>>> Serious question : Do you know anyone who switches?
>>
>> i don't think it's really about people being able to switch.
>
> I know. I just think the idea is funny.
>
>> it's *still*
>> about letting Person A use velocity with log4j and Person B use
>> velocity with
>> JDK 1.4 logging, and Person C use.... c-l is just a better way of
>> doing that
>> than the current system we have.
>
> Right now, people can use whatever logger they want, or no logger. I
> like the idea of a logger-free component. (For example, hasn't anyone
> besides me jumped up and down wondering why HttpClient needs a logger?)
>
> So lets boil it down to the requirement. Is it
>
> a) We want Velocity to use commons-logger
> b) We want Velocity users that use commons-logger to easily use
> velocity with that logging system.
>
> (And what if I want to use Vel w/o c-l? Then what?)
>
> geir
>
> --
> Geir Magnusson Jr 203-956-2604(w)
> Adeptra, Inc. 203-434-2093(m)
> geirm@adeptra.com 203-247-1713(m)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
Re: DO NOT REPLY [Bug 19140] - RFE: switch to commons-logging
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Nathan Bubna" <na...@esha.com> writes:
>i agree. c-l is pretty much the lowest common denominator. but it's API is
>still far richer than that of velocity's LogSystem! what we're lobbying for
I disagree. It is not. :-) It is simply a way to add logging code to
an application without being locked into a logging package. You can
use e.g. all of the log4j features like appenders, categories, levels
and stuff with c-l.
If you're interested, look at the Turbine code base. In a nutshell,
the approach is:
- decide which logging system you want to use (this can be design
time, compile time or run time. Turbine currently does a compile
time decision for log4j in org.apache.turbine.Turbine::configure()
- Configure this logging system just as you would do with your specific
logging system
- Configure commons-logging to _use_ this logging system. This is as simple
as doing
import org.apache.commons.logging.LogFactory;
import org.apache.commons.logging.impl.Log4jFactory;
[...]
System.getProperties().setProperty(LogFactory.class.getName(),
Log4jFactory.class.getName());
[...]
for Log4j
- After this, Turbine uses one of the following mnemonics for Logging:
private static final Log log = LogFactory.getLog(Myclass.class);
or
protected Log log = LogFactory.getLog(this.getClass());
(first one if the logging should always contain the category of the actual
class, second one if you want logging show up under the category of derived
classes).
Then you do
log.debug("")
log.info("")
log.error("")
log.fatal("")
and so on. For complex stuff you can do
if (log.isDebugEnabled())
{
log.debug("Complex stuff");
}
That's it. But you get all the features of e.g. log4j with commons-logging.
Regards
Henning
>here is merely a switch from one logger agnostic system to a richer and more
>actively maintained logger agnostic system. what is there that velocity's
>LogSystem offers that c-l does not?
>...
>> > Turbine uses c-l but configures it to actually log via log4j so we
>> > have a strong preference here for log4j. But there is no problem
>> > configuring it to use e.g. JDK1.4 logging.
>>
>> Serious question : Do you know anyone who switches?
>i don't think it's really about people being able to switch. it's *still*
>about letting Person A use velocity with log4j and Person B use velocity with
>JDK 1.4 logging, and Person C use.... c-l is just a better way of doing that
>than the current system we have.
>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
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
Re: DO NOT REPLY [Bug 19140] - RFE: switch to commons-logging
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Nathan Bubna" <na...@esha.com> writes:
>and no, throwing away the LogSystem and switching to commons-logging is not
>the only solution. but i do think it will be the best one by enough of a
>margin to justify the effort.
100% agreement from me here. Doing this for Turbine (when starting
2.3-dev) wasn't actually that bad. Took me a long afternoon to replace
all our old "Log.<something> stuff with c-l. After starting with it,
it really took hold in our codebase and it still makes me shiver to
think back to the old 2.1/2.2 LogService based logging. :-)
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
RE: DO NOT REPLY [Bug 19140] - RFE: switch to commons-logging
Posted by "Marinó A. Jónsson" <ma...@centrum.is>.
well put Nathan :)
cheers,
Marinó
> -----Original Message-----
> From: Nathan Bubna [mailto:nathan@esha.com]
> Sent: 27. ágúst 2003 05:38
> To: Velocity Developers List
> Subject: Re: DO NOT REPLY [Bug 19140] - RFE: switch to commons-logging
>
>
> Geir Magnusson Jr. said:
> ...
> > What I'm trying to suggest is if we make it easy for c-l
> users to use
> > velocity, will that solve the problem? or is the only solution
> > throwing away what we have and just use c-l?
>
> i don't think there really are c-l "users" out there.
> commons-logging is--as Jeff put it--a "logging abstraction
> API." it is designed for middleware. users (those developing
> applications with the middleware libraries) will generally
> use a "concrete logging solution" like jdk1.4 logging, log4j,
> logkit, or a proprietary system. the point of logging
> abstractions like velocity's logsystem and commons-logging is
> to avoid tying users into any of those "concrete" logging systems.
>
> in other words, the commons-logging "users" will be other
> middleware libraries or application components or whatever
> you want to call them. i don't see this issue as a matter of
> individual "commons-logging users" clamoring for velocity to
> support their logging solution. i can't speak well for
> others, but i consider myself to be an application developer
> clamoring for velocity to use a more powerful and better
> supported "logging abstraction" so that velocity can perform
> better for me and better integrate its log output with that
> of the other middleware libraries i am using.
>
> and no, throwing away the LogSystem and switching to
> commons-logging is not the only solution. but i do think it
> will be the best one by enough of a margin to justify the effort.
>
> 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: DO NOT REPLY [Bug 19140] - RFE: switch to commons-logging
Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr. said:
...
> What I'm trying to suggest is if we make it easy for c-l users to use
> velocity, will that solve the problem? or is the only solution
> throwing away what we have and just use c-l?
i don't think there really are c-l "users" out there. commons-logging is--as
Jeff put it--a "logging abstraction API." it is designed for middleware.
users (those developing applications with the middleware libraries) will
generally use a "concrete logging solution" like jdk1.4 logging, log4j,
logkit, or a proprietary system. the point of logging abstractions like
velocity's logsystem and commons-logging is to avoid tying users into any of
those "concrete" logging systems.
in other words, the commons-logging "users" will be other middleware libraries
or application components or whatever you want to call them. i don't see this
issue as a matter of individual "commons-logging users" clamoring for velocity
to support their logging solution. i can't speak well for others, but i
consider myself to be an application developer clamoring for velocity to use a
more powerful and better supported "logging abstraction" so that velocity can
perform better for me and better integrate its log output with that of the
other middleware libraries i am using.
and no, throwing away the LogSystem and switching to commons-logging is not
the only solution. but i do think it will be the best one by enough of a
margin to justify the effort.
Nathan Bubna
nathan@esha.com
Re: DO NOT REPLY [Bug 19140] - RFE: switch to commons-logging
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On Tuesday, August 26, 2003, at 07:36 PM, Nathan Bubna wrote:
> Geir Magnusson Jr said
> ...
>> What I'm suggesting is that we make velocity work with CL via an
>> adapter, so the the C-L crowd can use it if they want, but we don't
>> shove the requirement to use c-l down everyone else's throat.
>
> huh? i'm getting confused. commons-logging *is* an adapter. i'm
> struggling
> to understand how having velocity use commons-logging instead of the
> current
> system is shoving anything down anyone's throat. users can still use
> the
> logging system of their choice.
What I'm trying to suggest is if we make it easy for c-l users to use
velocity, will that solve the problem? or is the only solution
throwing away what we have and just use c-l?
>
>> So lets boil it down to the requirement. Is it
>>
>> a) We want Velocity to use commons-logger
>> b) We want Velocity users that use commons-logger to easily use
>> velocity with that logging system.
>>
>> (And what if I want to use Vel w/o c-l? Then what?)
>
> first, the library is called "commons-logging" not "commons-logger."
Thank you. I stand corrected.
> second,
> most users don't "use commons-logg[ing]." they use log4j or jdk1.4 or
> what-have-you.
>
> commons-logging is "an ultra-thin bridge between different logging
> libraries.
> Commons components may use the Logging API to remove compile-time and
> run-time
> dependencies on any particular logging package, and contributors may
> write Log
> implementations for the library of their choice."
I was pretty familiar with it when it started (I was trying to get them
to support a marker interface so some of the vel-tools stuff could
expose if they needed logging... thought it would be useful there...).
geir
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-434-2093(m)
geirm@adeptra.com 203-247-1713(m)
Re: DO NOT REPLY [Bug 19140] - RFE: switch to commons-logging
Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr said
...
> What I'm suggesting is that we make velocity work with CL via an
> adapter, so the the C-L crowd can use it if they want, but we don't
> shove the requirement to use c-l down everyone else's throat.
huh? i'm getting confused. commons-logging *is* an adapter. i'm struggling
to understand how having velocity use commons-logging instead of the current
system is shoving anything down anyone's throat. users can still use the
logging system of their choice.
> I'm not claiming that velocity's logsystem is grand. It's just that
> the user has the freedom to do what they want.
they'd have that freedom with commons-logging too.
...
> Right now, people can use whatever logger they want, or no logger. I
> like the idea of a logger-free component. (For example, hasn't anyone
> besides me jumped up and down wondering why HttpClient needs a logger?)
eh, have you looked at the first sentence in the first paragraph on the
commons-logging site? :)
and i think it'd be a bad idea for velocity to not have a logger. if you
really don't want the log output, just make commons-logging use its NoOpLog or
else configure the log system you told c-l to use not to output any velocity
log messages.
> So lets boil it down to the requirement. Is it
>
> a) We want Velocity to use commons-logger
> b) We want Velocity users that use commons-logger to easily use
> velocity with that logging system.
>
> (And what if I want to use Vel w/o c-l? Then what?)
first, the library is called "commons-logging" not "commons-logger." second,
most users don't "use commons-logg[ing]." they use log4j or jdk1.4 or
what-have-you.
commons-logging is "an ultra-thin bridge between different logging libraries.
Commons components may use the Logging API to remove compile-time and run-time
dependencies on any particular logging package, and contributors may write Log
implementations for the library of their choice."
Nathan Bubna
nathan@esha.com
Re: switch to commons-logging
Posted by Nathan Bubna <na...@esha.com>.
Tim Colson said:
...
> But then, I see Geirs 'least common denominator' perspective. For
> example, I don't know if C-L can even handle log4j NDC's (nested
> diagnostic contexts) or all of JDK 1.4's silly logging levels (fine,
> finer, finest, supa-fine, ultra-fine, yo-mama-is-fine, etc.).
i don't think Velocity does anything that requires NDC's. remember, we're
talking about what log system velocity passes *its* log messages to. as long
as we stick to a "logger agnostic" system like the current one or
commons-logging, you are free to use log4j or whatever feature-happy log
system your application needs.
that said, i don't actually think the current velocity log system is all that
great. it mostly works and that's good. but i think it would work better if
we used commons-logging, even were it only for the performance benefits of the
is<Priority>Enabled() checks that the commons-logging API supports and the
velocity logging API does not.
Nathan Bubna
nathan@esha.com
Re: switch to commons-logging
Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr.
> On Tuesday, August 26, 2003, at 10:23 PM, Tim Colson wrote:
> > But in the end, I just want simple configuration and logging - however
> > you blokes care to do it. <grin>
>
> This is the core as I see it. The best solution, given that the
> existing code has been really easy to maintain and use so far, would be
> one that puts the least burden on users, while providing the
> functionality people want.
>
> Right?
in that case:
1. Velocity's log system does not have all the functionality i want (i doubt
i'm alone there).
2. commons-logging is no more difficult to set up than velocity's LogSystem.
it too searches the classpath for log4j and logkit and adds to that the
jdk1.4. and just like velocity, it also has a simple default logger.
3. the only real added "burden" is one small dependency that can be
distributed with velocity and is already something of a "standard" for
middleware libraries (used by the likes tomcat, struts, and many of its fellow
commons libraries).
is that really so much?
Nathan Bubna
nathan@esha.com
Re: switch to commons-logging
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On Tuesday, August 26, 2003, at 10:23 PM, Tim Colson wrote:
>
> But in the end, I just want simple configuration and logging - however
> you blokes care to do it. <grin>
>
This is the core as I see it. The best solution, given that the
existing code has been really easy to maintain and use so far, would be
one that puts the least burden on users, while providing the
functionality people want.
Right?
geir
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-434-2093(m)
geirm@adeptra.com 203-247-1713(m)
RE: switch to commons-logging
Posted by Tim Colson <tc...@cisco.com>.
> >> Serious question : Do you know anyone who switches?
> > i don't think it's really about people being able to switch.
> I know. I just think the idea is funny.
I may be forced to switch to JDK 1.4 logging if it is deemed the group
'standard'. Yikes. Next thing you know, they'll be saying we must use
'standard' JSP. <grin>
I wish I had already started using commons-logging so the log4j switch
would be painless, but I wasn't that bright at the time. ;-)
Regarding the Velocity angle... personally, I want logging, but I don't
want to care and feed it all that much. Heck - I'm apparently not bright
enough to hand VelocityViewServlet, Hibernate, My Toolbox Tools, and
Struts a logger I've already created and so I wind up with a lot of ugly
console mesgs. From this point of view, a consistent and simple commons
logging soln for all tools sounds like a Good Thing(tm).
But then, I see Geirs 'least common denominator' perspective. For
example, I don't know if C-L can even handle log4j NDC's (nested
diagnostic contexts) or all of JDK 1.4's silly logging levels (fine,
finer, finest, supa-fine, ultra-fine, yo-mama-is-fine, etc.).
Switching sides again... Velocity core probably only uses basic log
stuff - so I tend to agree with Nathan that the LCD functionality of CL
might be suitable, and I for one don't mind another jar.
But in the end, I just want simple configuration and logging - however
you blokes care to do it. <grin>
Cheers,
Timo
Re: DO NOT REPLY [Bug 19140] - RFE: switch to commons-logging
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On Tuesday, August 26, 2003, at 06:29 PM, Nathan Bubna wrote:
> Geir Magnusson Jr. said:
>> On Tuesday, August 26, 2003, at 05:10 PM, Henning P. Schmiedehausen
>> wrote:
>>
>>> "Geir Magnusson Jr." <ge...@adeptra.com> writes:
>>>
>>>> fashion is commons-logging. Are you saying that c-l is it, and the
>>>> logger-agnostic approach, while right for the first two popular
>>>> logging
>>>> approach, is wrong now?
>>>
>>> c-l _is_ the logger agnostic approach. :-) It is simply a thin glue
>>> layer over log4j, jdk14 logging, simple logging, you name it. It
>>> basically is what you did in Velocity but in a packaged, maintained
>>> component.
>>
>> What if I want to take advantage of log4j specific API's? Or levels?
>> or...
>>
>> I realize the utility of c-l, but I also see a tradeoff. it seems
>> like
>> lowest common denominator logging for the benefit of flexibility that
>> I
>> can't imagine people seriously use in production.
>
> i agree. c-l is pretty much the lowest common denominator. but it's
> API is
> still far richer than that of velocity's LogSystem! what we're
> lobbying for
> here is merely a switch from one logger agnostic system to a richer
> and more
> actively maintained logger agnostic system. what is there that
> velocity's
> LogSystem offers that c-l does not?
What I'm suggesting is that we make velocity work with CL via an
adapter, so the the C-L crowd can use it if they want, but we don't
shove the requirement to use c-l down everyone else's throat.
I'm not claiming that velocity's logsystem is grand. It's just that
the user has the freedom to do what they want.
>
> ...
>>> Turbine uses c-l but configures it to actually log via log4j so we
>>> have a strong preference here for log4j. But there is no problem
>>> configuring it to use e.g. JDK1.4 logging.
>>
>> Serious question : Do you know anyone who switches?
>
> i don't think it's really about people being able to switch.
I know. I just think the idea is funny.
> it's *still*
> about letting Person A use velocity with log4j and Person B use
> velocity with
> JDK 1.4 logging, and Person C use.... c-l is just a better way of
> doing that
> than the current system we have.
Right now, people can use whatever logger they want, or no logger. I
like the idea of a logger-free component. (For example, hasn't anyone
besides me jumped up and down wondering why HttpClient needs a logger?)
So lets boil it down to the requirement. Is it
a) We want Velocity to use commons-logger
b) We want Velocity users that use commons-logger to easily use
velocity with that logging system.
(And what if I want to use Vel w/o c-l? Then what?)
geir
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-434-2093(m)
geirm@adeptra.com 203-247-1713(m)
Re: DO NOT REPLY [Bug 19140] - RFE: switch to commons-logging
Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr. said:
> On Tuesday, August 26, 2003, at 05:10 PM, Henning P. Schmiedehausen
> wrote:
>
> > "Geir Magnusson Jr." <ge...@adeptra.com> writes:
> >
> >> fashion is commons-logging. Are you saying that c-l is it, and the
> >> logger-agnostic approach, while right for the first two popular
> >> logging
> >> approach, is wrong now?
> >
> > c-l _is_ the logger agnostic approach. :-) It is simply a thin glue
> > layer over log4j, jdk14 logging, simple logging, you name it. It
> > basically is what you did in Velocity but in a packaged, maintained
> > component.
>
> What if I want to take advantage of log4j specific API's? Or levels?
> or...
>
> I realize the utility of c-l, but I also see a tradeoff. it seems like
> lowest common denominator logging for the benefit of flexibility that I
> can't imagine people seriously use in production.
i agree. c-l is pretty much the lowest common denominator. but it's API is
still far richer than that of velocity's LogSystem! what we're lobbying for
here is merely a switch from one logger agnostic system to a richer and more
actively maintained logger agnostic system. what is there that velocity's
LogSystem offers that c-l does not?
...
> > Turbine uses c-l but configures it to actually log via log4j so we
> > have a strong preference here for log4j. But there is no problem
> > configuring it to use e.g. JDK1.4 logging.
>
> Serious question : Do you know anyone who switches?
i don't think it's really about people being able to switch. it's *still*
about letting Person A use velocity with log4j and Person B use velocity with
JDK 1.4 logging, and Person C use.... c-l is just a better way of doing that
than the current system we have.
Nathan Bubna
nathan@esha.com
Re: DO NOT REPLY [Bug 19140] - RFE: switch to commons-logging
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On Tuesday, August 26, 2003, at 05:10 PM, Henning P. Schmiedehausen
wrote:
> "Geir Magnusson Jr." <ge...@adeptra.com> writes:
>
>> fashion is commons-logging. Are you saying that c-l is it, and the
>> logger-agnostic approach, while right for the first two popular
>> logging
>> approach, is wrong now?
>
> c-l _is_ the logger agnostic approach. :-) It is simply a thin glue
> layer over log4j, jdk14 logging, simple logging, you name it. It
> basically is what you did in Velocity but in a packaged, maintained
> component.
What if I want to take advantage of log4j specific API's? Or levels?
or...
I realize the utility of c-l, but I also see a tradeoff. it seems like
lowest common denominator logging for the benefit of flexibility that I
can't imagine people seriously use in production.
"Hey bob! it's wednesday! Lets switch to jdk1.4 logging! it's just
like log4j, but different!"
;)
>
> Turbine uses c-l but configures it to actually log via log4j so we
> have a strong preference here for log4j. But there is no problem
> configuring it to use e.g. JDK1.4 logging.
Serious question : Do you know anyone who switches?
Unrelated serious question : Do you know anyone using JDK 1.4 in
serious heavy production?
That said -
1) You claimed the approach turbine uses is inefficient. How?
2) if we made velocity's logger be discoverable via the c-l discovery
mechanism, would that help? That way Turbine gets what it wants, and
people who don't want to use c-l get what they want?
geir
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-434-2093(m)
geirm@adeptra.com 203-247-1713(m)
Re: DO NOT REPLY [Bug 19140] - RFE: switch to commons-logging
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Geir Magnusson Jr." <ge...@adeptra.com> writes:
>fashion is commons-logging. Are you saying that c-l is it, and the
>logger-agnostic approach, while right for the first two popular logging
>approach, is wrong now?
c-l _is_ the logger agnostic approach. :-) It is simply a thin glue
layer over log4j, jdk14 logging, simple logging, you name it. It
basically is what you did in Velocity but in a packaged, maintained
component.
Turbine uses c-l but configures it to actually log via log4j so we
have a strong preference here for log4j. But there is no problem
configuring it to use e.g. JDK1.4 logging.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
Re: DO NOT REPLY [Bug 19140] - RFE: switch to commons-logging
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On Tuesday, August 26, 2003, at 04:18 PM, Henning P. Schmiedehausen
wrote:
> "Geir Magnusson Jr." <ge...@adeptra.com> writes:
>
>> I have to confess that I just don't grok c-l for things that aren't
>> large-ish frameworks or container-ish things. I would hate forcing a
>> logging solution onto anyone that uses Velocity. It makes sense, for
>> example, that Turbine (or any large system...) might employ a system
>> like that, but if we want to keep velocity small with as few
>> dependencies, then I think we should do what we can to keep it simple.
>
> Actually it's exactly the other way around. Commons-Logging is a very
> simple and small package and allows your users maximum flexibility how
> to log. The current logging code in Velocity is less flexible, dated
> and not as well maintained as c-l. IMHO, reusage is the name of the
> game and with c-l there is a really decent component.
I have no doubt that c-l is really a fine, well-maintained piece of
software.
>
> [...]
>> -> there are times where I just don't give a flying rat's patootie
>> about logging and don't feel the need to go get some external logging
>> deps.
>
> Much of the current velocity core code (especially the ant task) make
> this very clear.
Remember, there was no c-l when Velocity was first done. All we had
was the logger from Avalon, and even then we didn't want to tie the
thing to one logger. Back then, that was the logging solution du jour.
After that, log4j became 'it', and I resisted betting the farm on that
too (although I really like it and use it exclusively myself). Now,
fashion is commons-logging. Are you saying that c-l is it, and the
logger-agnostic approach, while right for the first two popular logging
approach, is wrong now?
>
>> Re the last bit about c-l support to better integrate with Turbine,
>> why
>> not just make a logger that does work with c-l, and hand that to Vel
>> to
>> use? Or we make one here and offer it as an option?
>
> This is exactly what we do ATM. It's inefficient and basically
> considered a wart.
Why? I'm happy to discuss if there are some details about why it's so
inefficient. The balance is inefficiency vs inconvenience, forcing yet
another dependency and forcing a specific logging solution.
geir
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-434-2093(m)
geirm@adeptra.com 203-247-1713(m)
Re: DO NOT REPLY [Bug 19140] - RFE: switch to commons-logging
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Geir Magnusson Jr." <ge...@adeptra.com> writes:
>I have to confess that I just don't grok c-l for things that aren't
>large-ish frameworks or container-ish things. I would hate forcing a
>logging solution onto anyone that uses Velocity. It makes sense, for
>example, that Turbine (or any large system...) might employ a system
>like that, but if we want to keep velocity small with as few
>dependencies, then I think we should do what we can to keep it simple.
Actually it's exactly the other way around. Commons-Logging is a very
simple and small package and allows your users maximum flexibility how
to log. The current logging code in Velocity is less flexible, dated
and not as well maintained as c-l. IMHO, reusage is the name of the
game and with c-l there is a really decent component.
[...]
>-> there are times where I just don't give a flying rat's patootie
>about logging and don't feel the need to go get some external logging
>deps.
Much of the current velocity core code (especially the ant task) make
this very clear.
>Re the last bit about c-l support to better integrate with Turbine, why
>not just make a logger that does work with c-l, and hand that to Vel to
>use? Or we make one here and offer it as an option?
This is exactly what we do ATM. It's inefficient and basically
considered a wart.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
Re: DO NOT REPLY [Bug 19140] - RFE: switch to commons-logging
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Nathan Bubna" <na...@esha.com> writes:
>Geir Magnusson Jr said:
>...
>> I have to confess that I just don't grok c-l for things that aren't
>> large-ish frameworks or container-ish things. I would hate forcing a
>> logging solution onto anyone that uses Velocity. It makes sense, for
>> example, that Turbine (or any large system...) might employ a system
>> like that, but if we want to keep velocity small with as few
>> dependencies, then I think we should do what we can to keep it simple.
>IMHO, commons-logging is the simpler way to go. i don't use velocity alone.
>for me (and many others), it's always one piece of a larger app, and the
>larger apps always require logging of their own. configuring many logging
>systems can be a pain. the more "pieces" out there that switch to c-l, the
>less i have to configure.
+1
I completely agree with you here.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
Re: DO NOT REPLY [Bug 19140] - RFE: switch to commons-logging
Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr said:
...
> I have to confess that I just don't grok c-l for things that aren't
> large-ish frameworks or container-ish things. I would hate forcing a
> logging solution onto anyone that uses Velocity. It makes sense, for
> example, that Turbine (or any large system...) might employ a system
> like that, but if we want to keep velocity small with as few
> dependencies, then I think we should do what we can to keep it simple.
IMHO, commons-logging is the simpler way to go. i don't use velocity alone.
for me (and many others), it's always one piece of a larger app, and the
larger apps always require logging of their own. configuring many logging
systems can be a pain. the more "pieces" out there that switch to c-l, the
less i have to configure.
> Right now, Velocity has it's own basic logging interface that allows
> custom logging. We use some old Avalon logging code for simple file
> logging so it works out of the box, support being handed a log4j
> category, etc. I think this is really great, because of the simplicity
> -> there are times where I just don't give a flying rat's patootie
> about logging and don't feel the need to go get some external logging
> deps.
yes, there is a certain simplicity of use to the current state of things (at
least for the standalone velocity case), but there's a big tradeoff in
flexibility and control of logging (also in speed potentially).
> Re the last bit about c-l support to better integrate with Turbine, why
> not just make a logger that does work with c-l, and hand that to Vel to
> use? Or we make one here and offer it as an option?
i checked two "bridges" between c-l and Velocity's log system (one 'bridge'
each direction) into velocity-tools. they're in the generic package. :)
Nathan Bubna
nathan@esha.com
Re: DO NOT REPLY [Bug 19140] - RFE: switch to commons-logging
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On Friday, August 22, 2003, at 07:39 PM, Daniel Rall wrote:
> "Henning P. Schmiedehausen" <hp...@intermeta.de> writes:
>
>> Kasper Nielsen <ne...@kav.dk> writes:
>> [...]
>>
>> Ceki tried to pull off the same thing when we converted Turbine to
>> commons-logging and IMHO the only real alternative to this step
>> would've been converting to avalon logging.
>>
>> By not pulling in a middle layer we would have locked ourselves into
>> an (open-source) product which is underdocumented and the only real
>> docs available are for money. So our alternative for Turbine would've
>> been either Avalon or "JDK 1.4 logging and no log4j at all".
>>
>> In the end, most of the points in the paper you've cited are moot, if
>> you look at the links that he gives, you'll see that these people
>> simply didn't understand the role of c-l and log4j or were not able to
>> set up a root logger which you will have to do with pure log4j
>> too. And "where to put the log4j jar?" is simply pathetic with todays
>> servlet containers which are able to separate out the class pathes.
>>
>> We've converted Turbine to commons-logging in the currently running
>> 2.3-dev cycle and as far as I can see, all of the early adopters are
>> really happy that we have a consistent and working logging all over
>> the application for the first time since Turbine inception. ATM we
>> spawn off Velocity with a preset logger so that it integrates into our
>> logging framework and at last I (I can't, won't and don't speak for
>> the whole Turbine team) would wholeheartedly welcome the conversion of
>> Velocity to commons-logging. It would fit even better together with
>> Turbine.
>
> I pretty much agree with Henning's summary here.
I have to confess that I just don't grok c-l for things that aren't
large-ish frameworks or container-ish things. I would hate forcing a
logging solution onto anyone that uses Velocity. It makes sense, for
example, that Turbine (or any large system...) might employ a system
like that, but if we want to keep velocity small with as few
dependencies, then I think we should do what we can to keep it simple.
Right now, Velocity has it's own basic logging interface that allows
custom logging. We use some old Avalon logging code for simple file
logging so it works out of the box, support being handed a log4j
category, etc. I think this is really great, because of the simplicity
-> there are times where I just don't give a flying rat's patootie
about logging and don't feel the need to go get some external logging
deps.
Re the last bit about c-l support to better integrate with Turbine, why
not just make a logger that does work with c-l, and hand that to Vel to
use? Or we make one here and offer it as an option?
geir
> --
>
> Daniel Rall
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-434-2093(m)
geirm@adeptra.com 203-247-1713(m)