You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Rob Harrop <ro...@robharrop.com> on 2004/02/07 17:02:53 UTC
Hello All
Hi,
First off I would like to give a big thanks for bring us such a great
project! My name is Rob Harrop and I am currently working on a Velocity book
and I plan to get a bit more involved on the development front during and
especially after writing the book.
Initially I want to know what the plans are regarding Commons Logging. As
part of the book I plan to implement a custom logger for Commons Logging,
which I will be happy to give to the project. Longer term I would be happy
to get involved and move the project over to Commons Logging if this is part
of the overall strategy.
Regards,
Rob Harrop
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: logging again
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Feb 11, 2004, at 7:07 AM, Neeme Praks wrote:
> I've been reading this thread for a while now and I figured to drop a
> note now as things start to be a bit confusing (in my mind at least).
>
> Geir Magnusson Jr wrote:
>
> [..snip..]
>
>> This is not what I mean by injection, and I'm sorry I wasn't clearer.
>> I see the whole problem now.
>> There are two aspects to logging that we have to think about, the
>> internal aspect, how things inside the core of Vel and around it
>> (like tools) get loggers. There also is the the external aspect, how
>> Velocity as a single component behaves wrt the environment it's used
>> it.
>> When I talk about injection, I am thinking of the latter - the
>> external aspect - in that I mean that the user of velocity gets to
>> dictate what logger the whole of the log flow will go into. It's how
>> it works now. IOW, I don't care how Velocity will log internally,
>> just that I get a say on where the stuff goes. I know it's actually
>> properties, but for the sake of this discussion, it's equivalent to :
>> VelEngine ve = new VelEngine();
>> ve.setLogger( somethingThatImplementsLogsystem);
>> vs.init();
>> with the default being the search for logkit and log4j automatically
>> if I don't specify something.
>> You are correct that *internally*, we have the model of having to set
>> the logger in classes, 'injecting' the logger into things, and we can
>> improve that by switching to a static factory model. But that's not
>> what I mean when I say I want to keep injection. I mean I want the
>> 'external' configuration injection. Internally, there is nothing
>> wrong with using a static factory to grab a logger for any class
>> inside that wants one. Doing that has no effect on the external
>> behavior of velocity, I will argue, as long as we don't use c-l
>> directly, because then we lose control over the static factory,
>> control of which is critical for keeping the external injection.
>> So that's the key to this misunderstanding -> there is an internal
>> aspect (i.e. w/in velocity, we have the pattern of static factory to
>> pull a logger, what you might call the "c-l pattern"), but what I am
>> defending so rigidly is the external aspect.
>> I've explained that I always (almost) use the static factory approach
>> myself, and think it's generally just peachy. It will be very
>> convenient for programmers developing *inside* Velocity.
>> But externally, I like having the ability to set the logging adapter
>> from the outside. This is very convenient for programmers developing
>> *with* Velocity.
>
> Maybe it's me but I don't get it how can you have injection pattern
> externally and static factory pattern internally?
>
> Example:
> (We are in a container that has a common classloader for all
> applications and components)
>
> We inject the logger in application A:
>
> VelocityEngine ve = new VelocityEngine();
> ve.setLogger(somethingThatImplementsLogsystemForApplicationA);
> vs.init();
>
> And, we inject the logger in application B:
>
> VelocityEngine ve = new VelocityEngine();
> ve.setLogger(somethingThatImplementsLogsystemForApplicationB);
> vs.init();
>
> If I understand correctly then (internally) classes in Velocity would
> be using something like this to get a logger:
>
> private Logger logger = LogSystem.getLogger("my.log.category");
>
> In order to make this work, there has to be something like this
> somewhere in VelocityEngine initialization code:
>
> LogSystem.setRootLogger(somethingThatImplementsLogsystemForApplicationA
> orB);
>
> and then getLogger() implementation would be something like this:
>
> public static Logger getLogger(String categoryName) {
> return rootLogger.getChildLogger(categoryName);
> }
>
> So... if we have the application A initalization and then application
> B initialization, the end result is that all logging goes to the
> logger from application B (as the logger is set on a static level and
> we have a common classloader)...
Yes, that is a wrinkle that occurred to me, but I thought the solution
would be a context classloader. Though as I think about it, we could
be screwed. Yet another example of why singletons suck.
Have I ever emphasized how much I think the whole subject of logging
really sucks?
>
> To conclude, my point is that if you are going to take the injection
> route then you cannot really use static factory pattern internally.
> Then you have to use injection all the way, otherwise it doesn't
> really work.
Hopefully we can figure this out. Right now we have injection all the
way, but there is darn good reason to augment or replace it w/ the
static factory.
>
> And I would support the injection pattern 100% as it would make it
> much-much easier to use more than one instance of Velocity as a
> component in managed environments like Avalon containers or
> PicoContainer or any other out there.
That was my motivation, to ensure that container models like that will
be supported. They are still yet not mainstream but are getting there,
and will be much more prevalent in the future, I am sure.
>
> Finally, if you take the injection route, you can just as well use the
> commons-logging interfaces for injecting the logger (as nobody, not
> even Geir :-), really had anything against the interface, it
> opposition was just for the discovery mechanism and that really is a
> PITA in managed environments).
That's right, and thanks for the support! Now there's two of us!
Here is where I get to invoke the dependency argument - I will argue
that for something so simple, the interface, there is no reason to bind
ourselves to the machinations of an external project, no matter how
good the project and its participants.
I really take and took this issue seriously - I was chatting about it
as a sanity check w/ someone I greatly respect (a J2EE container
author) who said the following [and who's identity will remain secret
for his protection from the c-l cabal :) ] :
[22:26] <xxxxx> geir: if it is just for your consumption, I'd vote for
writing a simple custom interface
[22:27] <xxxxx> everything out their has too much baggage and you can
write something that makes you internal code easy
Not that an appeal to authority by an unnamed source should be
considered a reason to do anything, but I least had comforting
confirmation that I wasn't totally nuts...
:)
geir
>
> Rgds,
> Neeme
>
>
> ---------------------------------------------------------------------
> 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-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: logging again
Posted by Neeme Praks <ne...@apache.org>.
I've been reading this thread for a while now and I figured to drop a
note now as things start to be a bit confusing (in my mind at least).
Geir Magnusson Jr wrote:
[..snip..]
> This is not what I mean by injection, and I'm sorry I wasn't clearer. I
> see the whole problem now.
>
> There are two aspects to logging that we have to think about, the
> internal aspect, how things inside the core of Vel and around it (like
> tools) get loggers. There also is the the external aspect, how Velocity
> as a single component behaves wrt the environment it's used it.
>
> When I talk about injection, I am thinking of the latter - the external
> aspect - in that I mean that the user of velocity gets to dictate what
> logger the whole of the log flow will go into. It's how it works now.
> IOW, I don't care how Velocity will log internally, just that I get a
> say on where the stuff goes. I know it's actually properties, but for
> the sake of this discussion, it's equivalent to :
>
> VelEngine ve = new VelEngine();
>
> ve.setLogger( somethingThatImplementsLogsystem);
>
> vs.init();
>
> with the default being the search for logkit and log4j automatically if
> I don't specify something.
>
> You are correct that *internally*, we have the model of having to set
> the logger in classes, 'injecting' the logger into things, and we can
> improve that by switching to a static factory model. But that's not
> what I mean when I say I want to keep injection. I mean I want the
> 'external' configuration injection. Internally, there is nothing wrong
> with using a static factory to grab a logger for any class inside that
> wants one. Doing that has no effect on the external behavior of
> velocity, I will argue, as long as we don't use c-l directly, because
> then we lose control over the static factory, control of which is
> critical for keeping the external injection.
>
> So that's the key to this misunderstanding -> there is an internal
> aspect (i.e. w/in velocity, we have the pattern of static factory to
> pull a logger, what you might call the "c-l pattern"), but what I am
> defending so rigidly is the external aspect.
>
> I've explained that I always (almost) use the static factory approach
> myself, and think it's generally just peachy. It will be very
> convenient for programmers developing *inside* Velocity.
>
> But externally, I like having the ability to set the logging adapter
> from the outside. This is very convenient for programmers developing
> *with* Velocity.
Maybe it's me but I don't get it how can you have injection pattern
externally and static factory pattern internally?
Example:
(We are in a container that has a common classloader for all
applications and components)
We inject the logger in application A:
VelocityEngine ve = new VelocityEngine();
ve.setLogger(somethingThatImplementsLogsystemForApplicationA);
vs.init();
And, we inject the logger in application B:
VelocityEngine ve = new VelocityEngine();
ve.setLogger(somethingThatImplementsLogsystemForApplicationB);
vs.init();
If I understand correctly then (internally) classes in Velocity would be
using something like this to get a logger:
private Logger logger = LogSystem.getLogger("my.log.category");
In order to make this work, there has to be something like this
somewhere in VelocityEngine initialization code:
LogSystem.setRootLogger(somethingThatImplementsLogsystemForApplicationAorB);
and then getLogger() implementation would be something like this:
public static Logger getLogger(String categoryName) {
return rootLogger.getChildLogger(categoryName);
}
So... if we have the application A initalization and then application B
initialization, the end result is that all logging goes to the logger
from application B (as the logger is set on a static level and we have a
common classloader)...
To conclude, my point is that if you are going to take the injection
route then you cannot really use static factory pattern internally. Then
you have to use injection all the way, otherwise it doesn't really work.
And I would support the injection pattern 100% as it would make it
much-much easier to use more than one instance of Velocity as a
component in managed environments like Avalon containers or
PicoContainer or any other out there.
Finally, if you take the injection route, you can just as well use the
commons-logging interfaces for injecting the logger (as nobody, not even
Geir :-), really had anything against the interface, it opposition was
just for the discovery mechanism and that really is a PITA in managed
environments).
Rgds,
Neeme
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: injection vs. static factory approach to logging
Posted by Nathan Bubna <na...@esha.com>.
Neeme Praks said:
> Nathan Bubna wrote:
...
> > i was talking about filtering log messages
> > based on *class* source, not component source.
> >
> > if i want to see messages from the tool classes
(org.apache.velocity.tools.*)
> > but not from the rest of Velocity, i have no way to single those out.
...
> don't get stuck with the notion that you are handed a logger and that is
> the logger that you have to use for logging everywhere.
...
i'll try not to.
> I found out that there is no getChildLog(String categoryName) method
> in that interface. I had assumed that the commons logging abstraction
> is more or less the same as the avalon logging abstraction
>
(http://avalon.apache.org/framework/api/org/apache/avalon/framework/logger/Log
ger.html)...
>
> Ok, now I know better. Commons logging has no getChildLog(String
> categoryName) method. So, you would be stuck with just a single logger
> as you suggest and that is no good.
child logger, eh? interesting. yeah, that would help.
> So, in order to support the injection pattern and still have different
> logging categories for different parts of Velocity, you have three options:
> 1. update your "homebrewn" logging abstraction to support
> getChildLogger() method
probably the best i'll get around here :) should we take this route, it'll
probably still be rather a pain to work with in VelocityTools's tools, but
assuming i can get support for tool pooling added, i can live with it. :)
> 2. use avalon logging abstraction (will introduce a dependency on avalon
> framework which is not too good)
ugh.
> 3. get the commons-logging guys to add support for getChildLog() method
> in the o.a.c.l.Log interface.
>
> I guess the first is the easiest route to take... but anyhow, we should
> also raise this issue in commons list, so the commons-logging guys would
> be aware of this drawback in commons logging interface.
hmm. i'd be surprised if they don't already know this, but it might not hurt
to make sure.
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: injection vs. static factory approach to logging
Posted by Neeme Praks <ne...@apache.org>.
Nathan Bubna wrote:
>>"Injection way" of getting/providing a logger is always more flexible,
>>from external point-of-view.
>
> "always"? that's a dangerous word. :)
maybe, but in this case I sincerely believe this to be true :-)
> no. you entirely missed my point. i was talking about filtering log messages
> based on *class* source, not component source.
>
> if i want to see messages from the tool classes (org.apache.velocity.tools.*)
> but not from the rest of Velocity, i have no way to single those out.
well, I guess you missed my point :-)
don't get stuck with the notion that you are handed a logger and that is
the logger that you have to use for logging everywhere.
Oops... Being an "avaloner", I had made wrong assumption about the
commons logging interface...
Now I looked up the org.apache.commons.logging.Log interface @
http://jakarta.apache.org/commons/logging/api/org/apache/commons/logging/Log.html
and I found out that there is no getChildLog(String categoryName) method
in that interface. I had assumed that the commons logging abstraction
is more or less the same as the avalon logging abstraction
(http://avalon.apache.org/framework/api/org/apache/avalon/framework/logger/Logger.html)...
Ok, now I know better. Commons logging has no getChildLog(String
categoryName) method. So, you would be stuck with just a single logger
as you suggest and that is no good.
So, in order to support the injection pattern and still have different
logging categories for different parts of Velocity, you have three options:
1. update your "homebrewn" logging abstraction to support
getChildLogger() method
2. use avalon logging abstraction (will introduce a dependency on avalon
framework which is not too good)
3. get the commons-logging guys to add support for getChildLog() method
in the o.a.c.l.Log interface.
I guess the first is the easiest route to take... but anyhow, we should
also raise this issue in commons list, so the commons-logging guys would
be aware of this drawback in commons logging interface.
Rgds,
Neeme
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: injection vs. static factory approach to logging
Posted by Nathan Bubna <na...@esha.com>.
Neeme Praks said:
> Nathan Bubna wrote:
...
> > you mean for developers developing with multiple VelocityEngine's
> > who want their log output to go in different directions.
> >
> > for the rest of app developers using Velocity--who may want to filter VE
log
> > output by class/source--this is less convenient.
> >
> > i support the static logger pattern because i think the second group
> > outnumbers the first.
>
> "Injection way" of getting/providing a logger is always more flexible,
> from external point-of-view.
"always"? that's a dangerous word. :)
> The usual code sample:
>
> VelocityEngine ve = new VelocityEngine();
> ve.setLogger(somethingThatImplementsLogsystem);
> vs.init();
>
> So, how would the app developer filter VE log output [by class/source]
> in this case? He/she has two options:
he/she has no options, because all the output will be to one logger/name.
> * 1st approach would be to provide no logger and let Velocity grab a
> root logger itself, most probably with category name
> "org.apache.velocity" or something similar.
>
> VelocityEngine ve = new VelocityEngine();
> //logger not provided externally
> vs.init();
>
> Note: with this default behaviour Velocity needs to use the static
> factory approach, but only ONCE for VelocityEngine instance.
>
> So, inside the init() there would be something like:
> public void init() {
> if (this.logger == null)
> this.logger = LoggerFactory.getLogger("org.apache.velocity");
> ...
> }
>
> The important part is that the static method is used ONLY IF the logger
> was not provided externally.
>
> * 2nd approach would be to provide a logger. However, as the application
> developer is probably very static factory approach friendly (as you
> suggest), he/she can just do the following:
>
> VelocityEngine ve = new VelocityEngine();
> ve.setLogger(LoggerFactory.getLogger("org.apache.velocity"));
> vs.init();
>
> or, if the application already has a logger (which is true in most cases):
>
> VelocityEngine ve = new VelocityEngine();
> ve.setLogger(this.logger.getChildLogger("velocity"));
> vs.init();
>
> See, lots of choice that would otherwise be limited to only static
> factory approach of redirecting the logging output.
> (and no issue with multiple velocity instances all logging to same
> appender where it is VERY difficult afterwards to figure out what was
> going on where...)
no. you entirely missed my point. i was talking about filtering log messages
based on *class* source, not component source.
if i want to see messages from the tool classes (org.apache.velocity.tools.*)
but not from the rest of Velocity, i have no way to single those out.
yes, it's true that the tradeoff is that i can't distinguish output from one
VelocityEngine from that of another, but i think that the case where that is
desired is less common. unless you can somehow combine the per-class logger
with the injection method (like you, i doubt this can happen), then i don't
see a way to get the best of both worlds.
given the choice between static factory or injection, i'll take the former.
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: injection vs. static factory approach to logging
Posted by Neeme Praks <ne...@apache.org>.
Nathan Bubna wrote:
[..snip..]
> you mean for developers developing with multiple VelocityEngine's who want
> their log output to go in different directions.
>
> for the rest of app developers using Velocity--who may want to filter VE log
> output by class/source--this is less convenient.
>
> i support the static logger pattern because i think the second group
> outnumbers the first.
"Injection way" of getting/providing a logger is always more flexible,
from external point-of-view.
The usual code sample:
VelocityEngine ve = new VelocityEngine();
ve.setLogger(somethingThatImplementsLogsystem);
vs.init();
So, how would the app developer filter VE log output in this case?
He/she has two options:
* 1st approach would be to provide no logger and let Velocity grab a
root logger itself, most probably with category name
"org.apache.velocity" or something similar.
VelocityEngine ve = new VelocityEngine();
//logger not provided externally
vs.init();
Note: with this default behaviour Velocity needs to use the static
factory approach, but only ONCE for VelocityEngine instance.
So, inside the init() there would be something like:
public void init() {
if (this.logger == null)
this.logger = LoggerFactory.getLogger("org.apache.velocity");
...
}
The important part is that the static method is used ONLY IF the logger
was not provided externally.
* 2nd approach would be to provide a logger. However, as the application
developer is probably very static factory approach friendly (as you
suggest), he/she can just do the following:
VelocityEngine ve = new VelocityEngine();
ve.setLogger(LoggerFactory.getLogger("org.apache.velocity"));
vs.init();
or, if the application already has a logger (which is true in most cases):
VelocityEngine ve = new VelocityEngine();
ve.setLogger(this.logger.getChildLogger("velocity"));
vs.init();
See, lots of choice that would otherwise be limited to only static
factory approach of redirecting the logging output.
(and no issue with multiple velocity instances all logging to same
appender where it is VERY difficult afterwards to figure out what was
going on where...)
Rgds,
Neeme
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: logging again Was: Hello All
Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr said:
> The originator of this thread hopefully learned his lesson!
>
> :D
which lesson is that? that we're a bunch of opinionated blowhards? or that
something as banal as logging can become the stuff of "religious" wars? ;)
> On Feb 10, 2004, at 3:41 PM, Nathan Bubna wrote:
...
> > blah blah SimpleLog blah blah adaptor vs. system
>
> In the big picture, it doesn't really matter.
true, but i think it has significantly influenced this debate nonetheless.
...
> > with regards to the third issue, i understand that Velocity has so far
> > used the "injection" pattern. this allows app developers (or
> > uber-component developers) to give Velocity a logger that it will
> > then use for every log message from every internal class. this allows
> > for simple, programmatic control without needing to employ configuration
> > options for specific logging solutions. on the other hand, this model
> > can be more difficult for the component developers to use (the
> > logger must be passed around for distantly related classes to use)
> > and does not give app developers using that component
> > fine-tuned control over the component's log output (because it all
> > flows through the same logger).
>
> This is not what I mean by injection, and I'm sorry I wasn't clearer.
> I see the whole problem now.
>
> There are two aspects to logging that we have to think about, the
> internal aspect, how things inside the core of Vel and around it (like
> tools) get loggers. There also is the the external aspect, how
> Velocity as a single component behaves wrt the environment it's used
> it.
>
> When I talk about injection, I am thinking of the latter - the external
> aspect - in that I mean that the user of velocity gets to dictate what
> logger the whole of the log flow will go into. It's how it works now.
> IOW, I don't care how Velocity will log internally, just that I get a
> say on where the stuff goes. I know it's actually properties, but for
> the sake of this discussion, it's equivalent to :
>
> VelEngine ve = new VelEngine();
> ve.setLogger( somethingThatImplementsLogsystem);
> vs.init();
>
> with the default being the search for logkit and log4j automatically if
> I don't specify something.
this is what i was talking about too. apparently *i* was unclear. :) really,
what i was trying to demonstrate was that we don't have notable
misunderstanding left at this point, just disagreement.
> You are correct that *internally*, we have the model of having to set
> the logger in classes, 'injecting' the logger into things, and we can
> improve that by switching to a static factory model. But that's not
> what I mean when I say I want to keep injection. I mean I want the
> 'external' configuration injection. Internally, there is nothing wrong
> with using a static factory to grab a logger for any class inside that
> wants one. Doing that has no effect on the external behavior of
> velocity, I will argue, as long as we don't use c-l directly, because
> then we lose control over the static factory, control of which is
> critical for keeping the external injection.
>
> So that's the key to this misunderstanding -> there is an internal
> aspect (i.e. w/in velocity, we have the pattern of static factory to
> pull a logger, what you might call the "c-l pattern"), but what I am
> defending so rigidly is the external aspect.
it's not misunderstanding at this point. it's doubt that this is possible.
that's why i've been asking for code.
> I've explained that I always (almost) use the static factory approach
> myself, and think it's generally just peachy. It will be very
> convenient for programmers developing *inside* Velocity.
>
> But externally, I like having the ability to set the logging adapter
> from the outside. This is very convenient for programmers developing
> *with* Velocity.
you mean for developers developing with multiple VelocityEngine's who want
their log output to go in different directions.
for the rest of app developers using Velocity--who may want to filter VE log
output by class/source--this is less convenient.
i support the static logger pattern because i think the second group
outnumbers the first.
> > the static-logger-per-class model, on the other hand, uses many
> > loggers and is not (so far as i can see) amenable to "injection."
> > it offers a great deal more output control to application
> > developers and provides easy access to loggers for those
> > developing the component. thus, gives lots of
> > control to app guys and is easy for comp. guys to use.
>
> right. agreed.
>
> >
> > personally, i prefer the latter model. i see that the former can have
> > it's
> > uses, but i think they are few and that the benefits of the latter far
> > outweigh its drawbacks. also, if we move to this pattern, we can just
> > use c-l
> > and avoid the need to develop/support our own logging adapter. that
> > is a significant benefit, IMO.
> >
>
> I won't say anything here until you read the big explanation above. I
> think it clears up the misunderstanding in that I believe that you are
> looking at only one aspect, the internal aspect, which I agree with.
>
> I'm not going to respond to the rest below now until I hear from you on
> the above.
done.
> > anyway, what does pique my curiousity are what seem to be claims below
> > that you can integrate/support both logging patterns in Velocity. i'm
> > skeptical, but very curious to hear more or see a proposal with some
> > code or psuedo-code.
> >
> > now, on to other stuff inline...
> >
> > Geir Magnusson Jr said:
> >> On Feb 9, 2004, at 1:40 AM, Nathan Bubna wrote:
> >>> Geir Magnusson Jr said:
> >>>> On Feb 8, 2004, at 6:21 PM, Nathan Bubna wrote:
...
> >>> we're having semantic problems. "users" is too vague at this point.
> >>> let's talk in terms of middleware developers and application
> >>> developers. c-l is entirely appropriate for the former to "use",
> >>> and not very appropriate for the latter to "use."
> >>
> >> When I say user, [i mean] anyone who has
> >> VelocityEngine ve = new VelocityEngine();
> >> ....
> >> ve.init();
> >> in their code.
> > ...
> >
> > i understand, but i think that's still too vague. this definition
> > could refer
> > to either application use of Velocity or the use of Velocity in an
> > uber-component (e.g. VelocityTools). and given my view that c-l is
> > not for
> > app development, this makes a difference.
> >
> > ...
> >> I think we can do a few things here that I believe
> >> satisfies everyone.
> >>
> >> 1) Enhance the LogSystem to add the log4j-inspired features of a
> >> static
> >> factory to let you get a logger at any time or make it class static.
> >
> > if i understand you, this sounds like a best of both worlds, but i
> > still have
> > concerns over feasibility. at a glance, it seems to me that the
> > static-logger-per-class pattern would be irreconcilable with a pattern
> > that
> > would let you set different log output destinations (trying to use your
> > input/output distinction here :) on a per instance basis.
> >
> >> 2) Rework the interface to get the canonical
> >> fatal/error/warn/info/debug/trace levels [the same set of methods of
> >> log4j + trace() i.e.. c-l :) ]
> >
> > add is<Level>Enabled() to this part and you have everyone's agreement
> > on this
> > point and something we could get started on right away.
> >
> >> 3) Add automatic discovery of c-l for simple usage.
> >
> > the only benefit of this being that c-l essentially auto-discovers the
> > stderr
> > "logging system" and Velocity's log system does not. so i'm still not
> > convinced this is worthwhile, but i guess i won't fight it.
> >
> >> I think this solves all the problems :
> >>
> >> 1) We get the features/services you need for VelTools
> >
> > i'm not sure of that.
> >
> >> 2) Marino gets to just use c-l
> >
> > if i may put words in his mouth, he doesn't "just use" it in
> > application
> > development. what he (or at least i) wants is to use it in component
> > development (e.g. VelocityTools). i don't see how your proposal would
> > make
> > that any more or less of a possibility than it is now.
> >
> >> 3) I get to avoid it
> >
> > yep.
> >
> > ...
> >>> if it can elegantly solve the logging problem i described concerning
> >>> moving VelocityTools away from the Velocity singleton model, then
> >>> you will have gone far towards appeasing my complaints.
> >>
> >> Point me to a tool that needs it and I'll help with the solution. I'd
> >> like everyone to be satisfied.
> >
> > most of the Struts tools and several of the View tools use logging.
> > all of
> > these are affected.
> >
> > ...
> >>>>> now, we could hack up some way to pass
> >>>>> them the VelocityEngine the servlet is using, but the thought of it
> >>>>> just makes me cringe.
> >>>>
> >>>> Me too.
> >>>
> >>> well, got any better suggestions given Velocity's current logging
> >>> pattern?
> >>
> >> We're discussing it. I see no problem providing a way to grab a
> >> logger:
> >> VelocityEngine.getLogger(....);
> >> or
> >> ve.getLogger(...);
> >
> > by the first do you mean Velocity.getLogger()? i'm assuming so.
> >
> > and yeah, something like this would certainly ease the pain. but it
> > would
> > still not be as simple as if we were to switch to a
> > static-logger-per-class
> > pattern.
> >
> > ...
> >>> eh, adding c-l to the automatic discovery is disturbing to me. i
> >>> suppose it
> >>> wouldn't hurt, but one adapter automatically adapting itself to
> >>> another
> >>> adapter is unsettling and seems pointless.
> >>
> >> come on. layering to adapt is a common thing. it's effectively what
> >> c-l does, right? Takes the lcd of log4j, jdk1.4 and stderr... and
> >> provides an adaptor layer to work with all three.
> >
> > ha! even you see stderr as a logging system and c-l as an adaptor
> > thereto.
> > this gives me hope that some part of you does understand what i'm
> > saying. ;)
> >
> > ...
> >> I'm more than happy for us to start sketching in code.
> > ...
> >
> > ok.
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: logging again Was: Hello All
Posted by "Marinó A. Jónsson" <ma...@centrum.is>.
Could it be?! ... are we witnessing the resolution of The Great Logging
Debate(tm)?! :)
I appreciate that there is a trade-off here - on the one hand we could
switch to c-l, which is widely accepted and actively developed, and would
mean one less component to worry about in Vel ... but we'd lose the support
for the injection pattern. On the other hand, we could improve LogSystem so
that it also supports the static pattern and offers the acclaimed
log4j+trace interface ... but it would mean more work and continued
development of a logging adapter (largely re-inventing the wheel).
I, for my part, have no problems with an improved LogSystem (if the
injection pattern is deemed essential) ... that is if the improvements are
implemented any time soon.
cheers,
Marinó
> -----Original Message-----
> From: Geir Magnusson Jr [mailto:geir@4quarters.com]
> Sent: 10. febrúar 2004 21:08
> To: Velocity Developers List
> Subject: Re: logging again Was: Hello All
>
>
> The originator of this thread hopefully learned his lesson!
>
> :D
>
> BTW, I think I understand completely the problem in communication.
> Read on...
>
> On Feb 10, 2004, at 3:41 PM, Nathan Bubna wrote:
>
> > first, a few key things, and then some heavily trimmed inline stuff:
> >
> > i see several main points of contention emerging in this
> thread. one
> > is the
> > nature of c-l (adapter or system?). this seems to center on the
> > presence and
> > function of SimpleLog in the library. the other is "control" of
> > logging.
> > i.e. whether the components figure out how to log on their
> own or are
> > silent
> > unless told otherwise. this, of course, is related to the issue of
> > logging
> > "patterns" in general, where we find a third point of
> contention: the
> > "injection" pattern vs. the "static class logger" pattern.
>
> It's not a "vs." as it can be both. Read on.
>
> >
> > as for the first issue, i view SimpleLog as an adapter to to stderr,
> > with
> > stderr being the logging system. i recognize that the line between
> > logging
> > adapter and logging system gets pretty blurry there, but given the
> > stated goal
> > of the package, i think that is the proper perspective. on
> the other
> > hand,
> > you see SimpleLog's presence as an indication that c-l is,
> in fact, a
> > "logging
> > system." i can see how that's arguable, but ultimately, i disagree
> > with that
> > assessment.
>
> In the big picture, it doesn't really matter.
>
> >
> > (and because of the view above, i do not see c-l as a legitimate
> > logging system for an application. well, at least not any
> application
> > of significance. i suppose you can do it if you really
> want, but that
> > is not its
> > intended purpose. so it seems like a pretty bad idea to me.)
> >
> > on the second point, i personally appreciate the fact that
> i need not
> > tell
> > individual components where to log. with c-l, i either let
> it figure
> > it out
> > on its own, or else i tell them via a single
> > commons-logging.properties per
> > application. you may call this a "loss of control," but i
> call it an
> > "easing
> > of burden." as i understand it, you don't mind the "loss
> of control"
> > as long
> > as you can prevent it programmatically. i presume this is why
> > Velocity's log
> > manager does it's own automatic discovery and you don't
> complain about
> > that.
>
> right - I'm happy to make others happy. Choice is good.
>
> >
> > with regards to the third issue, i understand that Velocity
> has so far
> > used
> > the "injection" pattern. this allows app developers (or
> uber-component
> > developers) to give Velocity a logger that it will then use
> for every
> > log
> > message from every internal class. this allows for simple,
> > programmatic
> > control without needing to employ configuration options for
> specific
> > logging
> > solutions. on the other hand, this model can be more
> difficult for the
> > component developers to use (the logger must be passed around for
> > distantly
> > related classes to use) and does not give app developers using that
> > component
> > fine-tuned control over the component's log output (because it all
> > flows
> > through the same logger).
>
> This is not what I mean by injection, and I'm sorry I wasn't
> clearer.
> I see the whole problem now.
>
> There are two aspects to logging that we have to think about, the
> internal aspect, how things inside the core of Vel and around
> it (like
> tools) get loggers. There also is the the external aspect, how
> Velocity as a single component behaves wrt the environment it's used
> it.
>
> When I talk about injection, I am thinking of the latter -
> the external
> aspect - in that I mean that the user of velocity gets to
> dictate what
> logger the whole of the log flow will go into. It's how it
> works now.
> IOW, I don't care how Velocity will log internally, just
> that I get a
> say on where the stuff goes. I know it's actually
> properties, but for
> the sake of this discussion, it's equivalent to :
>
> VelEngine ve = new VelEngine();
>
> ve.setLogger( somethingThatImplementsLogsystem);
>
> vs.init();
>
> with the default being the search for logkit and log4j
> automatically if
> I don't specify something.
>
> You are correct that *internally*, we have the model of having to set
> the logger in classes, 'injecting' the logger into things, and we can
> improve that by switching to a static factory model. But that's not
> what I mean when I say I want to keep injection. I mean I want the
> 'external' configuration injection. Internally, there is
> nothing wrong
> with using a static factory to grab a logger for any class
> inside that
> wants one. Doing that has no effect on the external behavior of
> velocity, I will argue, as long as we don't use c-l directly, because
> then we lose control over the static factory, control of which is
> critical for keeping the external injection.
>
> So that's the key to this misunderstanding -> there is an internal
> aspect (i.e. w/in velocity, we have the pattern of static factory to
> pull a logger, what you might call the "c-l pattern"), but what I am
> defending so rigidly is the external aspect.
>
> I've explained that I always (almost) use the static factory approach
> myself, and think it's generally just peachy. It will be very
> convenient for programmers developing *inside* Velocity.
>
> But externally, I like having the ability to set the logging adapter
> from the outside. This is very convenient for programmers developing
> *with* Velocity.
>
> >
> > the static-logger-per-class model, on the other hand, uses many
> > loggers and is
> > not (so far as i can see) amenable to "injection." it
> offers a great
> > deal
> > more output control to application developers and provides
> easy access
> > to
> > loggers for those developing the component. thus, gives lots of
> > control to
> > app guys and is easy for comp. guys to use.
>
> right. agreed.
>
> >
> > personally, i prefer the latter model. i see that the
> former can have
> > it's
> > uses, but i think they are few and that the benefits of the
> latter far
> > outweigh its drawbacks. also, if we move to this pattern,
> we can just
> > use c-l
> > and avoid the need to develop/support our own logging
> adapter. that
> > is a
> > significant benefit, IMO.
> >
>
> I won't say anything here until you read the big explanation
> above. I
> think it clears up the misunderstanding in that I believe
> that you are
> looking at only one aspect, the internal aspect, which I agree with.
>
> I'm not going to respond to the rest below now until I hear
> from you on
> the above.
>
> geir
>
>
> > anyway, what does pique my curiousity are what seem to be
> claims below
> > that
> > you can integrate/support both logging patterns in Velocity. i'm
> > skeptical,
> > but very curious to hear more or see a proposal with some code or
> > psuedo-code.
> >
> > now, on to other stuff inline...
> >
> > Geir Magnusson Jr said:
> >> On Feb 9, 2004, at 1:40 AM, Nathan Bubna wrote:
> >>> Geir Magnusson Jr said:
> >>>> On Feb 8, 2004, at 6:21 PM, Nathan Bubna wrote:
> > ...
> >> What bugs me about c-l is that you can't, as the programmer using a
> >> component, stop it without having to address it's requirements
> >> directly. This means you have to do something specific in
> your log4j
> >> or jdk logger config, or worse, put in a logging impl that
> satisfies
> >> the discovery mechanism, IIRC. You lose control.
> >
> > actually, you can tell c-l to log to the NoOpLogger (or
> whatever it's
> > called)
> > via a system property or commons-logging.properties file. granted,
> > this is
> > not a programmatic solution, but it does avoid the need to "do
> > something
> > specific in your log4j or jdk logger config."
>
> ok :)
>
> >
> > ...
> >>> i completely agree with Marino here. the LCD support for logging
> >>> that c-l provides is more than enough for components like
> Velocity.
> >>
> >> Wait until there new log4j features are released.
> >
> > put down the crack-pipe. :)
>
> Hey! Thats the line I stole from Jon!
>
> > seriously, components should not be internally
> > using "latest and greatest" features that are particular to
> one logging
> > system. if you think i think otherwise, you're quite wrong. the
> > newer and
> > more non-standard a feature is, the less interested i am in
> using it in
> > component development.
>
> We'll see :)
>
> >
> > ...
> >>> we're having semantic problems. "users" is too vague at
> this point.
> >>> let's talk in terms of middleware developers and application
> >>> developers. c-l is entirely appropriate for the former to "use",
> >>> and not very appropriate for the latter to "use."
> >>
> >> When I say user, [i mean] anyone who has
> >> VelocityEngine ve = new VelocityEngine();
> >> ....
> >> ve.init();
> >> in their code.
> > ...
> >
> > i understand, but i think that's still too vague. this definition
> > could refer
> > to either application use of Velocity or the use of Velocity in an
> > uber-component (e.g. VelocityTools). and given my view that c-l is
> > not for
> > app development, this makes a difference.
> >
> > ...
> >> I think we can do a few things here that I believe
> >> satisfies everyone.
> >>
> >> 1) Enhance the LogSystem to add the log4j-inspired features of a
> >> static
> >> factory to let you get a logger at any time or make it
> class static.
> >
> > if i understand you, this sounds like a best of both worlds, but i
> > still have
> > concerns over feasibility. at a glance, it seems to me that the
> > static-logger-per-class pattern would be irreconcilable
> with a pattern
> > that
> > would let you set different log output destinations (trying
> to use your
> > input/output distinction here :) on a per instance basis.
> >
> >> 2) Rework the interface to get the canonical
> >> fatal/error/warn/info/debug/trace levels [the same set of
> methods of
> >> log4j + trace() i.e.. c-l :) ]
> >
> > add is<Level>Enabled() to this part and you have everyone's
> agreement
> > on this
> > point and something we could get started on right away.
> >
> >> 3) Add automatic discovery of c-l for simple usage.
> >
> > the only benefit of this being that c-l essentially
> auto-discovers the
> > stderr
> > "logging system" and Velocity's log system does not. so
> i'm still not
> > convinced this is worthwhile, but i guess i won't fight it.
> >
> >> I think this solves all the problems :
> >>
> >> 1) We get the features/services you need for VelTools
> >
> > i'm not sure of that.
> >
> >> 2) Marino gets to just use c-l
> >
> > if i may put words in his mouth, he doesn't "just use" it in
> > application
> > development. what he (or at least i) wants is to use it in
> component
> > development (e.g. VelocityTools). i don't see how your
> proposal would
> > make
> > that any more or less of a possibility than it is now.
> >
> >> 3) I get to avoid it
> >
> > yep.
> >
> > ...
> >>> if it can elegantly solve the logging problem i described
> concerning
> >>> moving VelocityTools away from the Velocity singleton model, then
> >>> you will have gone far towards appeasing my complaints.
> >>
> >> Point me to a tool that needs it and I'll help with the
> solution. I'd
> >> like everyone to be satisfied.
> >
> > most of the Struts tools and several of the View tools use
> logging.
> > all of
> > these are affected.
> >
> > ...
> >>>>> now, we could hack up some way to pass
> >>>>> them the VelocityEngine the servlet is using, but the
> thought of it
> >>>>> just makes me cringe.
> >>>>
> >>>> Me too.
> >>>
> >>> well, got any better suggestions given Velocity's current logging
> >>> pattern?
> >>
> >> We're discussing it. I see no problem providing a way to grab a
> >> logger:
> >> VelocityEngine.getLogger(....);
> >> or
> >> ve.getLogger(...);
> >
> > by the first do you mean Velocity.getLogger()? i'm assuming so.
> >
> > and yeah, something like this would certainly ease the
> pain. but it
> > would
> > still not be as simple as if we were to switch to a
> > static-logger-per-class
> > pattern.
> >
> > ...
> >>> eh, adding c-l to the automatic discovery is disturbing to me. i
> >>> suppose it
> >>> wouldn't hurt, but one adapter automatically adapting itself to
> >>> another
> >>> adapter is unsettling and seems pointless.
> >>
> >> come on. layering to adapt is a common thing. it's
> effectively what
> >> c-l does, right? Takes the lcd of log4j, jdk1.4 and stderr... and
> >> provides an adaptor layer to work with all three.
> >
> > ha! even you see stderr as a logging system and c-l as an adaptor
> > thereto.
> > this gives me hope that some part of you does understand what i'm
> > saying. ;)
> >
> > ...
> >> I'm more than happy for us to start sketching in code.
> > ...
> >
> > ok.
> >
> > 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-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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: logging again Was: Hello All
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
The originator of this thread hopefully learned his lesson!
:D
BTW, I think I understand completely the problem in communication.
Read on...
On Feb 10, 2004, at 3:41 PM, Nathan Bubna wrote:
> first, a few key things, and then some heavily trimmed inline stuff:
>
> i see several main points of contention emerging in this thread. one
> is the
> nature of c-l (adapter or system?). this seems to center on the
> presence and
> function of SimpleLog in the library. the other is "control" of
> logging.
> i.e. whether the components figure out how to log on their own or are
> silent
> unless told otherwise. this, of course, is related to the issue of
> logging
> "patterns" in general, where we find a third point of contention: the
> "injection" pattern vs. the "static class logger" pattern.
It's not a "vs." as it can be both. Read on.
>
> as for the first issue, i view SimpleLog as an adapter to to stderr,
> with
> stderr being the logging system. i recognize that the line between
> logging
> adapter and logging system gets pretty blurry there, but given the
> stated goal
> of the package, i think that is the proper perspective. on the other
> hand,
> you see SimpleLog's presence as an indication that c-l is, in fact, a
> "logging
> system." i can see how that's arguable, but ultimately, i disagree
> with that
> assessment.
In the big picture, it doesn't really matter.
>
> (and because of the view above, i do not see c-l as a legitimate
> logging system for an application. well, at least not any application
> of
> significance. i suppose you can do it if you really want, but that is
> not its
> intended purpose. so it seems like a pretty bad idea to me.)
>
> on the second point, i personally appreciate the fact that i need not
> tell
> individual components where to log. with c-l, i either let it figure
> it out
> on its own, or else i tell them via a single
> commons-logging.properties per
> application. you may call this a "loss of control," but i call it an
> "easing
> of burden." as i understand it, you don't mind the "loss of control"
> as long
> as you can prevent it programmatically. i presume this is why
> Velocity's log
> manager does it's own automatic discovery and you don't complain about
> that.
right - I'm happy to make others happy. Choice is good.
>
> with regards to the third issue, i understand that Velocity has so far
> used
> the "injection" pattern. this allows app developers (or uber-component
> developers) to give Velocity a logger that it will then use for every
> log
> message from every internal class. this allows for simple,
> programmatic
> control without needing to employ configuration options for specific
> logging
> solutions. on the other hand, this model can be more difficult for the
> component developers to use (the logger must be passed around for
> distantly
> related classes to use) and does not give app developers using that
> component
> fine-tuned control over the component's log output (because it all
> flows
> through the same logger).
This is not what I mean by injection, and I'm sorry I wasn't clearer.
I see the whole problem now.
There are two aspects to logging that we have to think about, the
internal aspect, how things inside the core of Vel and around it (like
tools) get loggers. There also is the the external aspect, how
Velocity as a single component behaves wrt the environment it's used
it.
When I talk about injection, I am thinking of the latter - the external
aspect - in that I mean that the user of velocity gets to dictate what
logger the whole of the log flow will go into. It's how it works now.
IOW, I don't care how Velocity will log internally, just that I get a
say on where the stuff goes. I know it's actually properties, but for
the sake of this discussion, it's equivalent to :
VelEngine ve = new VelEngine();
ve.setLogger( somethingThatImplementsLogsystem);
vs.init();
with the default being the search for logkit and log4j automatically if
I don't specify something.
You are correct that *internally*, we have the model of having to set
the logger in classes, 'injecting' the logger into things, and we can
improve that by switching to a static factory model. But that's not
what I mean when I say I want to keep injection. I mean I want the
'external' configuration injection. Internally, there is nothing wrong
with using a static factory to grab a logger for any class inside that
wants one. Doing that has no effect on the external behavior of
velocity, I will argue, as long as we don't use c-l directly, because
then we lose control over the static factory, control of which is
critical for keeping the external injection.
So that's the key to this misunderstanding -> there is an internal
aspect (i.e. w/in velocity, we have the pattern of static factory to
pull a logger, what you might call the "c-l pattern"), but what I am
defending so rigidly is the external aspect.
I've explained that I always (almost) use the static factory approach
myself, and think it's generally just peachy. It will be very
convenient for programmers developing *inside* Velocity.
But externally, I like having the ability to set the logging adapter
from the outside. This is very convenient for programmers developing
*with* Velocity.
>
> the static-logger-per-class model, on the other hand, uses many
> loggers and is
> not (so far as i can see) amenable to "injection." it offers a great
> deal
> more output control to application developers and provides easy access
> to
> loggers for those developing the component. thus, gives lots of
> control to
> app guys and is easy for comp. guys to use.
right. agreed.
>
> personally, i prefer the latter model. i see that the former can have
> it's
> uses, but i think they are few and that the benefits of the latter far
> outweigh its drawbacks. also, if we move to this pattern, we can just
> use c-l
> and avoid the need to develop/support our own logging adapter. that
> is a
> significant benefit, IMO.
>
I won't say anything here until you read the big explanation above. I
think it clears up the misunderstanding in that I believe that you are
looking at only one aspect, the internal aspect, which I agree with.
I'm not going to respond to the rest below now until I hear from you on
the above.
geir
> anyway, what does pique my curiousity are what seem to be claims below
> that
> you can integrate/support both logging patterns in Velocity. i'm
> skeptical,
> but very curious to hear more or see a proposal with some code or
> psuedo-code.
>
> now, on to other stuff inline...
>
> Geir Magnusson Jr said:
>> On Feb 9, 2004, at 1:40 AM, Nathan Bubna wrote:
>>> Geir Magnusson Jr said:
>>>> On Feb 8, 2004, at 6:21 PM, Nathan Bubna wrote:
> ...
>> What bugs me about c-l is that you can't, as the programmer using a
>> component, stop it without having to address it's requirements
>> directly. This means you have to do something specific in your log4j
>> or jdk logger config, or worse, put in a logging impl that satisfies
>> the discovery mechanism, IIRC. You lose control.
>
> actually, you can tell c-l to log to the NoOpLogger (or whatever it's
> called)
> via a system property or commons-logging.properties file. granted,
> this is
> not a programmatic solution, but it does avoid the need to "do
> something
> specific in your log4j or jdk logger config."
ok :)
>
> ...
>>> i completely agree with Marino here. the LCD support for logging
>>> that c-l provides is more than enough for components like Velocity.
>>
>> Wait until there new log4j features are released.
>
> put down the crack-pipe. :)
Hey! Thats the line I stole from Jon!
> seriously, components should not be internally
> using "latest and greatest" features that are particular to one logging
> system. if you think i think otherwise, you're quite wrong. the
> newer and
> more non-standard a feature is, the less interested i am in using it in
> component development.
We'll see :)
>
> ...
>>> we're having semantic problems. "users" is too vague at this point.
>>> let's talk in terms of middleware developers and application
>>> developers. c-l is entirely appropriate for the former to "use",
>>> and not very appropriate for the latter to "use."
>>
>> When I say user, [i mean] anyone who has
>> VelocityEngine ve = new VelocityEngine();
>> ....
>> ve.init();
>> in their code.
> ...
>
> i understand, but i think that's still too vague. this definition
> could refer
> to either application use of Velocity or the use of Velocity in an
> uber-component (e.g. VelocityTools). and given my view that c-l is
> not for
> app development, this makes a difference.
>
> ...
>> I think we can do a few things here that I believe
>> satisfies everyone.
>>
>> 1) Enhance the LogSystem to add the log4j-inspired features of a
>> static
>> factory to let you get a logger at any time or make it class static.
>
> if i understand you, this sounds like a best of both worlds, but i
> still have
> concerns over feasibility. at a glance, it seems to me that the
> static-logger-per-class pattern would be irreconcilable with a pattern
> that
> would let you set different log output destinations (trying to use your
> input/output distinction here :) on a per instance basis.
>
>> 2) Rework the interface to get the canonical
>> fatal/error/warn/info/debug/trace levels [the same set of methods of
>> log4j + trace() i.e.. c-l :) ]
>
> add is<Level>Enabled() to this part and you have everyone's agreement
> on this
> point and something we could get started on right away.
>
>> 3) Add automatic discovery of c-l for simple usage.
>
> the only benefit of this being that c-l essentially auto-discovers the
> stderr
> "logging system" and Velocity's log system does not. so i'm still not
> convinced this is worthwhile, but i guess i won't fight it.
>
>> I think this solves all the problems :
>>
>> 1) We get the features/services you need for VelTools
>
> i'm not sure of that.
>
>> 2) Marino gets to just use c-l
>
> if i may put words in his mouth, he doesn't "just use" it in
> application
> development. what he (or at least i) wants is to use it in component
> development (e.g. VelocityTools). i don't see how your proposal would
> make
> that any more or less of a possibility than it is now.
>
>> 3) I get to avoid it
>
> yep.
>
> ...
>>> if it can elegantly solve the logging problem i described concerning
>>> moving VelocityTools away from the Velocity singleton model, then
>>> you will have gone far towards appeasing my complaints.
>>
>> Point me to a tool that needs it and I'll help with the solution. I'd
>> like everyone to be satisfied.
>
> most of the Struts tools and several of the View tools use logging.
> all of
> these are affected.
>
> ...
>>>>> now, we could hack up some way to pass
>>>>> them the VelocityEngine the servlet is using, but the thought of it
>>>>> just makes me cringe.
>>>>
>>>> Me too.
>>>
>>> well, got any better suggestions given Velocity's current logging
>>> pattern?
>>
>> We're discussing it. I see no problem providing a way to grab a
>> logger:
>> VelocityEngine.getLogger(....);
>> or
>> ve.getLogger(...);
>
> by the first do you mean Velocity.getLogger()? i'm assuming so.
>
> and yeah, something like this would certainly ease the pain. but it
> would
> still not be as simple as if we were to switch to a
> static-logger-per-class
> pattern.
>
> ...
>>> eh, adding c-l to the automatic discovery is disturbing to me. i
>>> suppose it
>>> wouldn't hurt, but one adapter automatically adapting itself to
>>> another
>>> adapter is unsettling and seems pointless.
>>
>> come on. layering to adapt is a common thing. it's effectively what
>> c-l does, right? Takes the lcd of log4j, jdk1.4 and stderr... and
>> provides an adaptor layer to work with all three.
>
> ha! even you see stderr as a logging system and c-l as an adaptor
> thereto.
> this gives me hope that some part of you does understand what i'm
> saying. ;)
>
> ...
>> I'm more than happy for us to start sketching in code.
> ...
>
> ok.
>
> 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-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: logging again Was: Hello All
Posted by Nathan Bubna <na...@esha.com>.
first, a few key things, and then some heavily trimmed inline stuff:
i see several main points of contention emerging in this thread. one is the
nature of c-l (adapter or system?). this seems to center on the presence and
function of SimpleLog in the library. the other is "control" of logging.
i.e. whether the components figure out how to log on their own or are silent
unless told otherwise. this, of course, is related to the issue of logging
"patterns" in general, where we find a third point of contention: the
"injection" pattern vs. the "static class logger" pattern.
as for the first issue, i view SimpleLog as an adapter to to stderr, with
stderr being the logging system. i recognize that the line between logging
adapter and logging system gets pretty blurry there, but given the stated goal
of the package, i think that is the proper perspective. on the other hand,
you see SimpleLog's presence as an indication that c-l is, in fact, a "logging
system." i can see how that's arguable, but ultimately, i disagree with that
assessment.
(and because of the view above, i do not see c-l as a legitimate
logging system for an application. well, at least not any application of
significance. i suppose you can do it if you really want, but that is not its
intended purpose. so it seems like a pretty bad idea to me.)
on the second point, i personally appreciate the fact that i need not tell
individual components where to log. with c-l, i either let it figure it out
on its own, or else i tell them via a single commons-logging.properties per
application. you may call this a "loss of control," but i call it an "easing
of burden." as i understand it, you don't mind the "loss of control" as long
as you can prevent it programmatically. i presume this is why Velocity's log
manager does it's own automatic discovery and you don't complain about that.
with regards to the third issue, i understand that Velocity has so far used
the "injection" pattern. this allows app developers (or uber-component
developers) to give Velocity a logger that it will then use for every log
message from every internal class. this allows for simple, programmatic
control without needing to employ configuration options for specific logging
solutions. on the other hand, this model can be more difficult for the
component developers to use (the logger must be passed around for distantly
related classes to use) and does not give app developers using that component
fine-tuned control over the component's log output (because it all flows
through the same logger).
the static-logger-per-class model, on the other hand, uses many loggers and is
not (so far as i can see) amenable to "injection." it offers a great deal
more output control to application developers and provides easy access to
loggers for those developing the component. thus, gives lots of control to
app guys and is easy for comp. guys to use.
personally, i prefer the latter model. i see that the former can have it's
uses, but i think they are few and that the benefits of the latter far
outweigh its drawbacks. also, if we move to this pattern, we can just use c-l
and avoid the need to develop/support our own logging adapter. that is a
significant benefit, IMO.
anyway, what does pique my curiousity are what seem to be claims below that
you can integrate/support both logging patterns in Velocity. i'm skeptical,
but very curious to hear more or see a proposal with some code or psuedo-code.
now, on to other stuff inline...
Geir Magnusson Jr said:
> On Feb 9, 2004, at 1:40 AM, Nathan Bubna wrote:
> > Geir Magnusson Jr said:
> >> On Feb 8, 2004, at 6:21 PM, Nathan Bubna wrote:
...
> What bugs me about c-l is that you can't, as the programmer using a
> component, stop it without having to address it's requirements
> directly. This means you have to do something specific in your log4j
> or jdk logger config, or worse, put in a logging impl that satisfies
> the discovery mechanism, IIRC. You lose control.
actually, you can tell c-l to log to the NoOpLogger (or whatever it's called)
via a system property or commons-logging.properties file. granted, this is
not a programmatic solution, but it does avoid the need to "do something
specific in your log4j or jdk logger config."
...
> > i completely agree with Marino here. the LCD support for logging
> > that c-l provides is more than enough for components like Velocity.
>
> Wait until there new log4j features are released.
put down the crack-pipe. :) seriously, components should not be internally
using "latest and greatest" features that are particular to one logging
system. if you think i think otherwise, you're quite wrong. the newer and
more non-standard a feature is, the less interested i am in using it in
component development.
...
> > we're having semantic problems. "users" is too vague at this point.
> > let's talk in terms of middleware developers and application
> > developers. c-l is entirely appropriate for the former to "use",
> > and not very appropriate for the latter to "use."
>
> When I say user, [i mean] anyone who has
> VelocityEngine ve = new VelocityEngine();
> ....
> ve.init();
> in their code.
...
i understand, but i think that's still too vague. this definition could refer
to either application use of Velocity or the use of Velocity in an
uber-component (e.g. VelocityTools). and given my view that c-l is not for
app development, this makes a difference.
...
> I think we can do a few things here that I believe
> satisfies everyone.
>
> 1) Enhance the LogSystem to add the log4j-inspired features of a static
> factory to let you get a logger at any time or make it class static.
if i understand you, this sounds like a best of both worlds, but i still have
concerns over feasibility. at a glance, it seems to me that the
static-logger-per-class pattern would be irreconcilable with a pattern that
would let you set different log output destinations (trying to use your
input/output distinction here :) on a per instance basis.
> 2) Rework the interface to get the canonical
> fatal/error/warn/info/debug/trace levels [the same set of methods of
> log4j + trace() i.e.. c-l :) ]
add is<Level>Enabled() to this part and you have everyone's agreement on this
point and something we could get started on right away.
> 3) Add automatic discovery of c-l for simple usage.
the only benefit of this being that c-l essentially auto-discovers the stderr
"logging system" and Velocity's log system does not. so i'm still not
convinced this is worthwhile, but i guess i won't fight it.
> I think this solves all the problems :
>
> 1) We get the features/services you need for VelTools
i'm not sure of that.
> 2) Marino gets to just use c-l
if i may put words in his mouth, he doesn't "just use" it in application
development. what he (or at least i) wants is to use it in component
development (e.g. VelocityTools). i don't see how your proposal would make
that any more or less of a possibility than it is now.
> 3) I get to avoid it
yep.
...
> > if it can elegantly solve the logging problem i described concerning
> > moving VelocityTools away from the Velocity singleton model, then
> > you will have gone far towards appeasing my complaints.
>
> Point me to a tool that needs it and I'll help with the solution. I'd
> like everyone to be satisfied.
most of the Struts tools and several of the View tools use logging. all of
these are affected.
...
> >>> now, we could hack up some way to pass
> >>> them the VelocityEngine the servlet is using, but the thought of it
> >>> just makes me cringe.
> >>
> >> Me too.
> >
> > well, got any better suggestions given Velocity's current logging
> > pattern?
>
> We're discussing it. I see no problem providing a way to grab a logger:
> VelocityEngine.getLogger(....);
> or
> ve.getLogger(...);
by the first do you mean Velocity.getLogger()? i'm assuming so.
and yeah, something like this would certainly ease the pain. but it would
still not be as simple as if we were to switch to a static-logger-per-class
pattern.
...
> > eh, adding c-l to the automatic discovery is disturbing to me. i
> > suppose it
> > wouldn't hurt, but one adapter automatically adapting itself to another
> > adapter is unsettling and seems pointless.
>
> come on. layering to adapt is a common thing. it's effectively what
> c-l does, right? Takes the lcd of log4j, jdk1.4 and stderr... and
> provides an adaptor layer to work with all three.
ha! even you see stderr as a logging system and c-l as an adaptor thereto.
this gives me hope that some part of you does understand what i'm saying. ;)
...
> I'm more than happy for us to start sketching in code.
...
ok.
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: logging again Was: Hello All
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Feb 9, 2004, at 1:40 AM, Nathan Bubna wrote:
> i trimmed some things out, but it's another long one.
me too. Sorry about the delay, but it's been a day of too many
interrupts.
>
> Geir Magnusson Jr said:
>> On Feb 8, 2004, at 6:21 PM, Nathan Bubna wrote:
>>> Geir Magnusson Jr said:
>>>> On Feb 8, 2004, at 1:49 PM, Marinó A. Jónsson wrote:
>>
>> Remember, my opposition to just switching lock, stock and barrel to
>> c-l
>> isn't just about a dependency. It's actually the weakest of my
>> arguments against it. The biggest reason is that I don't think we
>> should force users to only use it and give up the injection pattern.
>> From the beginning of this thread, I've been in full support of a c-l
>> adapter that people could choose to use.
>
> i'll never understand this "force users to use c-l" rhetoric. it just
> doesn't
> compute in my brain. c-l is an adapter, just like LogSystem. and
> it's a far
> more powerful adapter than LogSystem. though admittedly, they are
> adapter
> implementations created with different use patterns in mind.
It's more than an adapter, because it rummages around on it's own to
find something to log to. I can't tell it to do something different
w/o what to some, me included, is convolution.
What bugs me about c-l is that you can't, as the programmer using a
component, stop it without having to address it's requirements
directly. This means you have to do something specific in your log4j
or jdk logger config, or worse, put in a logging impl that satisfies
the discovery mechanism, IIRC. You lose control.
I don't mind making the choice to give up control - it's very
convenient for a large number of situations - but not always.
>
>>> and since when do people dislike having "standard" (aka common)
>>> runtime
>>> configuration options? especially for logging!
>>
>> Well, apparently there was a huge dislike. :)
>>
>> There was log4j for the longest time which seemed to satisfy everyone
>> for everything. Except people at Sun, who decided to roll their own
>> for jdk 1.4 rather than turn log4j into a JSR and roll into the 1.4
>> umbrella JSR. And the the people in commons, who added to the
>> insanity
>> with ensuring the lowest common denominator support for logging
>> through
>> a common interface (although I do appreciate c-l's 'trace()' as it's
>> part of my jihad to get log4j to add it...)
>
> i completely agree with Marino here. the LCD support for logging that
> c-l
> provides is more than enough for middleware/components like Velocity.
Wait until there new log4j features are released.
> and if
> c-l is an LCD adapter, than LogSystem is a LTLCD adapter ("lower than
> lowest
> common denominator")!
Remember, keep the two issues separate - tying them together is a
convenient Straw Man, but we all agree that we can improve LogSystem
which I think is the important part. We all like, for the most part,
the interface in c-l (that comes from log4j), etc. We all like the
log4j usage patterns adopted by c-l.
None of those should be in debate as we agree.
What I am contesting is that slavish need to use c-l is the right way
to go, removing the ability to programmatically set a different log
output 'vector'.
I think of c-l as two parts :
1) the 'input', which is the interface that people use to log into,
inspired by log4j and very nice, actually.
2) the 'output', which is then how that input is sent to a logger.
I think the first part is what we all agree would be a nice step
forward for LogSystem. It's the second part of c-l which I don't like,
because as I've said before, it limits control.
>
> c-l is an attempt to provide a standard logging adapter for
> middleware/components to use that will allow application developers the
> freedom to use the logging solution/framework/implementation of their
> choice
> (e.g. log4j, jdk 1.4, avalon, etc.). and really, you still haven't
> convinced
> me that you appreciate the distinction.
To repeat, the first part of what c-l does is fine. It's basically
log4j anyway with 'trace' added as a standard level. I beat on Ceki
every chance I get for that to be added as
fatal/error/warn/info/debug/trace
make 100% sense to me, and I use them myself.
It's the second part, automatic discovery of an 'output' logger that
bugs me, and wish to avoid as the sole choice in velocity. That's
*really* what c-l does. The first part, the part that you two appear
to be enamored with 1) came from log4j and 2) is what we agree is good.
Am I being clearer?
>
>> I'm not against us making it easy that users can use vel w/ c-l, but I
>> don't want it to be the only option. But we've been through this.
>
> we're having semantic problems. "users" is too vague at this point.
> let's
> talk in terms of middleware developers and application developers.
> c-l is
> entirely appropriate for the former to "use", and not very appropriate
> for the
> latter to "use."
When I say user, anyone who has
VelocityEngine ve = new VelocityEngine();
....
ve.init();
in their code.
And I think c-l has an appropriate audience in both middleware as well
as app development, as does velocity.
>
> ...
>>>> But you can programmatically not have Vel do it if you give it a
>>>> logger
>>>> before init(). How do you keep that level of control w/ c-l? I
>>>> don't
>>>> need a detailed example here - just a handwaving description will
>>>> suffice.
>>>
>>> sure, you can make Velocity use c-l in such a way that you just pass
>>> in/around log instances. they're objects after all. it's just a
>>> matter
> of
>>> how you use them. you could replace LogSystem with c-l and have
>>> Velocity classes log to that one c-l instance that they access
>>> through
>>> the Velocity/VelocityEngine
>>> methods (warn, info, error, etc), and any app developers using
>>> Velocity could do the same. but then i don't really see much point
>>> in using c-l either.
>>> it's not just LogSystem i don't like, it's that whole approach to
>>> logging. IMHO, it's a PITA.
>>
>> Interesting. This is different from my perception of your position.
>> Can you elaborate?
>
> not sure what you want me to elaborate on. if it's the "using c-l
> like we do
> LogSystem", then i think you've got the idea when you talk below about
> there
> being two issues: pattern and implementation. basically what i'm
> saying above
> is that i think you *could* use c-l like we do LogSystem, but that's
> not
> really the pattern it was designed for.
>
> if you're asking about my PITA position on the current logging pattern
> in
> Velocity, my elaboration is pretty much what i said in describing the
> challenges Velocity's current logging pattern provides for
> VelocityTools. i
> foresee annoying, PITA-type problems there, that would disappear if
> Velocity
> were using (or at least supported) the pattern c-l is designed for.
I agree with the assessment of the current LogSystem patterns, and will
repeat that just using c-l isn't the only answer. It's one answer, but
not the only one, and any IoC proponent should agree.
I'll repeat that I think we can do a few things here that I believe
satisfies everyone.
1) Enhance the LogSystem to add the log4j-inspired features of a static
factory to let you get a logger at any time or make it class static.
2) Rework the interface to get the canonical
fatal/error/warn/info/debug/trace levels [the same set of methods of
log4j + trace() i.e.. c-l :) ]
3) Add automatic discovery of c-l for simple usage.
I think this solves all the problems :
1) We get the features/services you need for VelTools
2) Marino gets to just use c-l
3) I get to avoid it
>
> ...
>>> meanwhile, the current LogSystem is still pretty skimpy on features
>>> and useability. i believe everyone agrees could use a lot of
>>> improvement regardless of how.
>>
>> The issue of improving the log system is utterly unrelated to c-l, and
>> something we about which we are in violent agreement. The kneejerk
>> reaction to "just use c-l cuz it's a 'standard'" is what I'm against.
>
> "violent agreement", eh? that's a great description. i'll remember
> that. :)
I really do think we agree :)
>
>> Every time I implement a framework or -ish, I always use one level of
>> indirection for my logging, building a simple Logger interface, a
>> factory, and then an implementation that uses an existing, established
>> logging framework, or c-l. It takes about 20 minutes, and then I
>> reuse
>> it if I legally can.
>
> this is what i don't get. you build your own simple logging adapter,
> then
> speak of creating an implementation of it that "uses [a] logging
> framework or
> c-l." that is so bizarre to me. a logging framework or c-l are two
> very
> different things in my mind.
Yes - but c-l is in itself a lightweight framework, as it's a logger in
its own right. It's quite a weird beastie in that sense, in that :
1) it's a logging interface. This part I like. Anything to twist
Ceki's arm about trace()....
2) it's a logger. It should spooge to stdout if nothing else is around
3) it's a logger adapter. it will go find other logging systems in the
classpath and use them via it's discovery mechanism.
>
>> This is what c-l does for you, but allows me the
>> freedom of the pattern (which came from log4j) w/o the binding to the
>> implementation.
>
> sorry, i couldn't grok this part, and it seems like the key part where
> you
> explain why you think reinventing the wheel (c-l/logging adapter) is
> worthwhile. so, could you clarify?
That would be reinventing the reinvented wheel, actually, since c-l
just works on top of log4j and jdk 1.4, which is also a wheel
reinvention. So maybe c-l is a reinvention reinvention....? To me,
the only think that I found interesting and different w/ c-l is the
discovery mechanism, which I really wished they just asked to get into
log4j.
To clarify :
To me, what c-l does that I don't like is that it allows code that I'm
using to 'reach around me' and grab a logger. I then have to deal with
this elsewhere in my code or configuration. (It's what log4j does to
me also - I'm a log4j fan, but I use the "one-step-removed" approach in
all my frameworks and -ish to dodge that as well.)
What I do like that c-l does is what it took from log4j, and what I
implement anyway, which is the interface and sometimes the static
factory pattern.
>
>> As I said, I generally follow the log4j pattern (which is what c-l
>> copies) of having the ability to pull a logger out of the aether :
>>
>> Logger l = MyLogSystem.getLogger( <whatever > );
>>
>> Sometimes it's static for the class when appropriate, as you seem to
>> like, although in situations where you have multiple, concurrent
>> instances of the same class with a reasonable lifetime and output that
>> needs to be differentiated for whatever reason (think something like a
>> servlet container - different concurrent app execution - w/o the
>> classloader boundaries to separate static class instances), I choose
>> instance loggers rather than static class logger. I also generally
>> have MyLogSystem implement the Logger interface methods statically, so
>> I can
>>
>> MyLogSystem.error("Yikes...")
>>
>> when I want to in something lightweight like a small tool that would
>> be
>> used in an environment where failure of something (like sending email)
>> is of interest to operations. I wouldn't require the user of that
>> tool
>> to think about logging via the CTOR....
>
> makes sense.
>
>> So, I think that you are mistaken in your assessment of how I use
>> logging, and how I think it should be.
>
> probably. but i was going for a characterization more than an accurate
> assessment. :)
Shotgun versus sniper? :D
>
>> I do the same thing everyone else does, and what sounds like a
>> superset
>> of what you do. I suspect others also do what I do, keeping a loose
>> binding of that internal logging system to an external system like
>> log4j or c-l, but I've never discussed it w/ anyone.
>
> there you go calling c-l a logging system again... and in comparison
> to log4j
> no less! please tell me you see that they are notably different in
> purpose
> and not just power.
I think this is more philosophy than relevant to our discussion, but
interesting to both of us none-the-less. C-l is a logging system
itself - it will output to stdout (stderr?) if it can't find anything
else. So to say it isn't a logging system isn't true. For other
"appenders", to use log4j parlance, it uses log4j or jdk1.4 or
whatever, but to be precise and fair, it is a logging system as well as
an adapter.
Actually, I believe that would be no point to c-l at all, if log4j
would do the following :
1) create a lightweight jar with the Logger interface and boostrap
config
2) let that bootstrap config spit to stdout rather than drop all
messages
3) include a jdk 1.4 appender
That would be that.
>
>> I have no problem doing this in velocity, as it's what we do already
>> re
>> the pattern of decoupling, and agree we could improve via the static
>> factory pattern. But I'll still push back against just using c-l as
>> I
>> still believe there is great power to continue to offer our current
>> configuration pattern, giving the velocity user programmatic control
>> of
>> what's going on, explicitly setting the logger to which the internal
>> logging happens.
>
> i'd love to see some code for this. if it can elegantly solve the
> logging
> problem i described concerning moving VelocityTools away from the
> Velocity
> singleton model, then you will have gone far towards appeasing my
> complaints.
Point me to a tool that needs it and I'll help with the solution. I'd
like everyone to be satisfied.
>
>> We can continue to keep the user experience as easy
>> as possible for the uninterested by adding c-l to our automatic
>> discovery.
>
> eh, adding c-l to the automatic discovery is disturbing to me. i
> suppose it
> wouldn't hurt, but one adapter automatically adapting itself to another
> adapter is unsettling and seems pointless.
come on. layering to adapt is a common thing. it's effectively what
c-l does, right? Takes the lcd of log4j, jdk1.4 and stderr... and
provides an adaptor layer to work with all three.
> presumably c-l would be the last
> thing LogSystem looked for, and it would do the looking at runtime of
> an
> application. applications should be using a real logging framework
> (not just
> a bunch of logging adapters), which should be picked up first, right?
>
> ...
>>>>> Seems like a small price to pay IMO. I can sympathize
>>>>> with your view on dependencies in general - but I think it needs to
>>>>> be addressed on a case-by-case basis ... and in this case I think
>>>>> the
>>>>> pros weigh much heavier than the cons.
>>>>
>>>> No, because if you want to use c-l, just make the 10 line adapter
>>>> and
>>>> use it. If not, use vel as is... you get both, and I don't have to
>>>> deal with it...
>>>
>>> but as VelocityTools developers, we do have to deal with it. right
>>> now, we are using the singleton model. this lets the standard tools
>>> perform logging
>>> via the static Velocity.* logging methods. this is not ideal, but is
>>> tolerable for the moment. however, we need to switch the
>>> VelocityViewServlet
>>> (and VelocityTools in general) from using the Velocity class to using
>>> VelocityEngine. once we do this, the tools no longer have easy
>>> access
>>> to Velocity's logsystem. now, we could hack up some way to pass
>>> them the VelocityEngine the servlet is using, but the thought of it
>>> just
>>> makes me cringe.
>>
>> Me too.
>
> well, got any better suggestions given Velocity's current logging
> pattern?
We're discussing it. I see no problem providing a way to grab a logger
:
VelocitEngine.getLogger(....);
or
ve.getLogger(...);
>
>>> as a user, i would rather need only to configure logging for each app
>>> i work on once and in one place. yes, i can pump Velocity log
>>> messages through c-l and vice-versa, but that's a dumb suggestion
>>> that seems to indicate misunderstanding of the issues. it would just
>>> be pushing log messages through one more adapter (performance
>>> hit) before going to the actual logging system i
>>> am using for my application. that may be the most "reasonable"
>>> solution for anyone developing another *component* that uses
>>> Velocity (i fear this will be the fate of VelocityTools), but
>>> application
>>> developers have to configure the logging adapter of each component
>>> (e.g. Velocity) separately in order to point them to their one actual
>>> logging solution (Avalon, log4j, jdk1.4, etc.). the more components
>>> that develop their own logging adapters, the more of a
>>> pain this becomes.
>>
>> Not at all. Given automatic discovery, Velocity would find c-l if
>> that's what you were using...
>
> again, with this vague "using c-l" language... :) but seriously,
> application
> developers don't (or shouldn't) "use c-l" when developing their
> applications.
> c-l is for middleware/components.
That's not true. This is rich - I'm defending c-l now - c-l is
perfectly useful for apps as well. What's wrong w/ using it in apps?
>
>>> also, switching to c-l (with the each-class-has-its-own-static-logger
>>> paradigm)
>>
>> or log4j...
>
> don't want to do that, because *that* would lock users into a
> particular
> logging framework.
I've lost the context, but I certainly wasn't advocating switching to
one specific logging framework.
> i suspect Ceki doesn't mind advocating log4j as an
> alternative to c-l because he just wants everyone to use log4j. given
> the
> existence of a competing logging framework in the jdk these days, i
> don't
> think it is wise for middleware developers to use log4j in the
> components they
> develop. it's still fantastic for application development, though.
I don't why. All you need to be equivalent is an appender for jdk1.4
and stderr. Then you are done...
>
>>> would give me the power to filter/silence/redirect log messages
>>> according to source as well as severity. this would be nice since it
>>> often happens that i care about INFO (and WARN, DEBUG,
>>> etc) messages from one class, but not another.
>>>
>>> Geir, if you can't see where we're coming from on this by now, then i
>>> don't expect you ever will. and if you really do see it and just
>>> flat out
>>> disagree, just say so. you have the veto power of a committer and
>>> the influence of the project lead, so i don't want to waste time
>>> pushing
>>> on a brick wall that won't budge.
>>
>> read above. There are two issues here. One is the patterns, and the
>> other is the implementation. C-l is the implementation. Re the
>> patterns, I think that you can have what you want :
>>
>> - the convenience of pulling the logger via the static factory
>> - making static class loggers via the same where you want to
>
> you've got my attention. i'm curious how this would work in
> conjunction with
> your "injection pattern" or whatever. it seems to me that the two
> patterns
> would conflict in places. i'd have to know more and think on it to
> come up
> with an example. but if this can be done, that would be a great
> improvement!
I'm more than happy for us to start sketching in code.
>
>> - the "light and get away" simplicity of it finding and using c-l w/o
>> you having to think about it
>
> read above.
>
>> We both get
>> - improvement in internal logging w/in velocity
>>
>> I get
>> - keeping the programmatic control pattern for configuration freedom
>>
>> The only thing I believe I don't have a satisfactory answer for you is
>> performance, as it's true we'd have to delegate through methods in the
>> internal façade.
>
> i'm not too worried about performance. a far bigger issue with that is
> LogSystem's lack of "is<Level>Enabled()" functionality.
agree 100%
>
>> However, I'm not sure that's really a big enough deal
>> to worry about, as c-l does the same thing anyway, and I've never
>> heard
>> that as an arg for not using c-l ;)
>
> not quite right. if we just used c-l, we would be using just one
> adapter/indirection. if LogSystem is configured (automagically or
> otherwise)
> to "use c-l", then that's two adapters/levels-of-indirection before
> you get to
> the actual logging framework.
>
two method calls!
>> I bet the original poster had no clue what he was getting into...
>>
>> :D
>
> yeah, i hope we haven't scared him off. as soon as i read his email i
> thought, "oh no! here we go again." i tried to avoid it by simply
> pointing
> out there was a debate and not actually putting forth anything
> arguable, but
> apparently somebody else just couldn't help themselves. :)
Dance with the one what brung ya :)
>
> 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-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: logging again Was: Hello All
Posted by Nathan Bubna <na...@esha.com>.
i trimmed some things out, but it's another long one.
Geir Magnusson Jr said:
> On Feb 8, 2004, at 6:21 PM, Nathan Bubna wrote:
> > Geir Magnusson Jr said:
> >> On Feb 8, 2004, at 1:49 PM, Marinó A. Jónsson wrote:
...
["double standard" discussion]
...
thanks for the history. yeah, that was before my time. :) so i stand
corrected, it's not really a double standard.
> Remember, my opposition to just switching lock, stock and barrel to c-l
> isn't just about a dependency. It's actually the weakest of my
> arguments against it. The biggest reason is that I don't think we
> should force users to only use it and give up the injection pattern.
> From the beginning of this thread, I've been in full support of a c-l
> adapter that people could choose to use.
i'll never understand this "force users to use c-l" rhetoric. it just doesn't
compute in my brain. c-l is an adapter, just like LogSystem. and it's a far
more powerful adapter than LogSystem. though admittedly, they are adapter
implementations created with different use patterns in mind.
> > and since when do people dislike having "standard" (aka common) runtime
> > configuration options? especially for logging!
>
> Well, apparently there was a huge dislike. :)
>
> There was log4j for the longest time which seemed to satisfy everyone
> for everything. Except people at Sun, who decided to roll their own
> for jdk 1.4 rather than turn log4j into a JSR and roll into the 1.4
> umbrella JSR. And the the people in commons, who added to the insanity
> with ensuring the lowest common denominator support for logging through
> a common interface (although I do appreciate c-l's 'trace()' as it's
> part of my jihad to get log4j to add it...)
i completely agree with Marino here. the LCD support for logging that c-l
provides is more than enough for middleware/components like Velocity. and if
c-l is an LCD adapter, than LogSystem is a LTLCD adapter ("lower than lowest
common denominator")!
c-l is an attempt to provide a standard logging adapter for
middleware/components to use that will allow application developers the
freedom to use the logging solution/framework/implementation of their choice
(e.g. log4j, jdk 1.4, avalon, etc.). and really, you still haven't convinced
me that you appreciate the distinction.
> I'm not against us making it easy that users can use vel w/ c-l, but I
> don't want it to be the only option. But we've been through this.
we're having semantic problems. "users" is too vague at this point. let's
talk in terms of middleware developers and application developers. c-l is
entirely appropriate for the former to "use", and not very appropriate for the
latter to "use."
...
> >> But you can programmatically not have Vel do it if you give it a
> >> logger
> >> before init(). How do you keep that level of control w/ c-l? I don't
> >> need a detailed example here - just a handwaving description will
> >> suffice.
> >
> > sure, you can make Velocity use c-l in such a way that you just pass
> > in/around log instances. they're objects after all. it's just a matter
of
> > how you use them. you could replace LogSystem with c-l and have
> > Velocity classes log to that one c-l instance that they access through
> > the Velocity/VelocityEngine
> > methods (warn, info, error, etc), and any app developers using
> > Velocity could do the same. but then i don't really see much point
> > in using c-l either.
> > it's not just LogSystem i don't like, it's that whole approach to
> > logging. IMHO, it's a PITA.
>
> Interesting. This is different from my perception of your position.
> Can you elaborate?
not sure what you want me to elaborate on. if it's the "using c-l like we do
LogSystem", then i think you've got the idea when you talk below about there
being two issues: pattern and implementation. basically what i'm saying above
is that i think you *could* use c-l like we do LogSystem, but that's not
really the pattern it was designed for.
if you're asking about my PITA position on the current logging pattern in
Velocity, my elaboration is pretty much what i said in describing the
challenges Velocity's current logging pattern provides for VelocityTools. i
foresee annoying, PITA-type problems there, that would disappear if Velocity
were using (or at least supported) the pattern c-l is designed for.
...
> > meanwhile, the current LogSystem is still pretty skimpy on features
> > and useability. i believe everyone agrees could use a lot of
> > improvement regardless of how.
>
> The issue of improving the log system is utterly unrelated to c-l, and
> something we about which we are in violent agreement. The kneejerk
> reaction to "just use c-l cuz it's a 'standard'" is what I'm against.
"violent agreement", eh? that's a great description. i'll remember that. :)
> Every time I implement a framework or -ish, I always use one level of
> indirection for my logging, building a simple Logger interface, a
> factory, and then an implementation that uses an existing, established
> logging framework, or c-l. It takes about 20 minutes, and then I reuse
> it if I legally can.
this is what i don't get. you build your own simple logging adapter, then
speak of creating an implementation of it that "uses [a] logging framework or
c-l." that is so bizarre to me. a logging framework or c-l are two very
different things in my mind.
> This is what c-l does for you, but allows me the
> freedom of the pattern (which came from log4j) w/o the binding to the
> implementation.
sorry, i couldn't grok this part, and it seems like the key part where you
explain why you think reinventing the wheel (c-l/logging adapter) is
worthwhile. so, could you clarify?
> As I said, I generally follow the log4j pattern (which is what c-l
> copies) of having the ability to pull a logger out of the aether :
>
> Logger l = MyLogSystem.getLogger( <whatever > );
>
> Sometimes it's static for the class when appropriate, as you seem to
> like, although in situations where you have multiple, concurrent
> instances of the same class with a reasonable lifetime and output that
> needs to be differentiated for whatever reason (think something like a
> servlet container - different concurrent app execution - w/o the
> classloader boundaries to separate static class instances), I choose
> instance loggers rather than static class logger. I also generally
> have MyLogSystem implement the Logger interface methods statically, so
> I can
>
> MyLogSystem.error("Yikes...")
>
> when I want to in something lightweight like a small tool that would be
> used in an environment where failure of something (like sending email)
> is of interest to operations. I wouldn't require the user of that tool
> to think about logging via the CTOR....
makes sense.
> So, I think that you are mistaken in your assessment of how I use
> logging, and how I think it should be.
probably. but i was going for a characterization more than an accurate
assessment. :)
> I do the same thing everyone else does, and what sounds like a superset
> of what you do. I suspect others also do what I do, keeping a loose
> binding of that internal logging system to an external system like
> log4j or c-l, but I've never discussed it w/ anyone.
there you go calling c-l a logging system again... and in comparison to log4j
no less! please tell me you see that they are notably different in purpose
and not just power.
> I have no problem doing this in velocity, as it's what we do already re
> the pattern of decoupling, and agree we could improve via the static
> factory pattern. But I'll still push back against just using c-l as I
> still believe there is great power to continue to offer our current
> configuration pattern, giving the velocity user programmatic control of
> what's going on, explicitly setting the logger to which the internal
> logging happens.
i'd love to see some code for this. if it can elegantly solve the logging
problem i described concerning moving VelocityTools away from the Velocity
singleton model, then you will have gone far towards appeasing my complaints.
> We can continue to keep the user experience as easy
> as possible for the uninterested by adding c-l to our automatic
> discovery.
eh, adding c-l to the automatic discovery is disturbing to me. i suppose it
wouldn't hurt, but one adapter automatically adapting itself to another
adapter is unsettling and seems pointless. presumably c-l would be the last
thing LogSystem looked for, and it would do the looking at runtime of an
application. applications should be using a real logging framework (not just
a bunch of logging adapters), which should be picked up first, right?
...
> >>> Seems like a small price to pay IMO. I can sympathize
> >>> with your view on dependencies in general - but I think it needs to
> >>> be addressed on a case-by-case basis ... and in this case I think the
> >>> pros weigh much heavier than the cons.
> >>
> >> No, because if you want to use c-l, just make the 10 line adapter and
> >> use it. If not, use vel as is... you get both, and I don't have to
> >> deal with it...
> >
> > but as VelocityTools developers, we do have to deal with it. right
> > now, we are using the singleton model. this lets the standard tools
> > perform logging
> > via the static Velocity.* logging methods. this is not ideal, but is
> > tolerable for the moment. however, we need to switch the
> > VelocityViewServlet
> > (and VelocityTools in general) from using the Velocity class to using
> > VelocityEngine. once we do this, the tools no longer have easy access
> > to Velocity's logsystem. now, we could hack up some way to pass
> > them the VelocityEngine the servlet is using, but the thought of it just
> > makes me cringe.
>
> Me too.
well, got any better suggestions given Velocity's current logging pattern?
> > as a user, i would rather need only to configure logging for each app
> > i work on once and in one place. yes, i can pump Velocity log
> > messages through c-l and vice-versa, but that's a dumb suggestion
> > that seems to indicate misunderstanding of the issues. it would just
> > be pushing log messages through one more adapter (performance
> > hit) before going to the actual logging system i
> > am using for my application. that may be the most "reasonable"
> > solution for anyone developing another *component* that uses
> > Velocity (i fear this will be the fate of VelocityTools), but application
> > developers have to configure the logging adapter of each component
> > (e.g. Velocity) separately in order to point them to their one actual
> > logging solution (Avalon, log4j, jdk1.4, etc.). the more components
> > that develop their own logging adapters, the more of a
> > pain this becomes.
>
> Not at all. Given automatic discovery, Velocity would find c-l if
> that's what you were using...
again, with this vague "using c-l" language... :) but seriously, application
developers don't (or shouldn't) "use c-l" when developing their applications.
c-l is for middleware/components.
> > also, switching to c-l (with the each-class-has-its-own-static-logger
> > paradigm)
>
> or log4j...
don't want to do that, because *that* would lock users into a particular
logging framework. i suspect Ceki doesn't mind advocating log4j as an
alternative to c-l because he just wants everyone to use log4j. given the
existence of a competing logging framework in the jdk these days, i don't
think it is wise for middleware developers to use log4j in the components they
develop. it's still fantastic for application development, though.
> > would give me the power to filter/silence/redirect log messages
> > according to source as well as severity. this would be nice since it
> > often happens that i care about INFO (and WARN, DEBUG,
> > etc) messages from one class, but not another.
> >
> > Geir, if you can't see where we're coming from on this by now, then i
> > don't expect you ever will. and if you really do see it and just flat out
> > disagree, just say so. you have the veto power of a committer and
> > the influence of the project lead, so i don't want to waste time pushing
> > on a brick wall that won't budge.
>
> read above. There are two issues here. One is the patterns, and the
> other is the implementation. C-l is the implementation. Re the
> patterns, I think that you can have what you want :
>
> - the convenience of pulling the logger via the static factory
> - making static class loggers via the same where you want to
you've got my attention. i'm curious how this would work in conjunction with
your "injection pattern" or whatever. it seems to me that the two patterns
would conflict in places. i'd have to know more and think on it to come up
with an example. but if this can be done, that would be a great improvement!
> - the "light and get away" simplicity of it finding and using c-l w/o
> you having to think about it
read above.
> We both get
> - improvement in internal logging w/in velocity
>
> I get
> - keeping the programmatic control pattern for configuration freedom
>
> The only thing I believe I don't have a satisfactory answer for you is
> performance, as it's true we'd have to delegate through methods in the
> internal façade.
i'm not too worried about performance. a far bigger issue with that is
LogSystem's lack of "is<Level>Enabled()" functionality.
> However, I'm not sure that's really a big enough deal
> to worry about, as c-l does the same thing anyway, and I've never heard
> that as an arg for not using c-l ;)
not quite right. if we just used c-l, we would be using just one
adapter/indirection. if LogSystem is configured (automagically or otherwise)
to "use c-l", then that's two adapters/levels-of-indirection before you get to
the actual logging framework.
> I bet the original poster had no clue what he was getting into...
>
> :D
yeah, i hope we haven't scared him off. as soon as i read his email i
thought, "oh no! here we go again." i tried to avoid it by simply pointing
out there was a debate and not actually putting forth anything arguable, but
apparently somebody else just couldn't help themselves. :)
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: Hello All
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Feb 8, 2004, at 9:07 PM, Will Glass-Husain wrote:
> Hmm... interesting exchange, and not entirely a repeat of the previous
> one.
> Three quick thoughts. Maybe this is an opportunity for consensus?
I actually think you'll find we have consensus. I'm hoping anyway....
I'm interested to hear what Nathan has to say.
>
> (1) Seems to me that automatic discovery of C-L would be a good
> compromise.
Only if we added C-L like we do w/ log4j or logkit - not required in
the classpath to use velocity.
> (2) It'd be nice if the docs had a clear recipe for setting up a log
> for
> those users who really don't care which of the 3 default solutions are
> used
> (or is it 4).
Right now, you don't have to do anything. Just use it.
> (3) Regardless, it'd be nice to improve the log capability. There's a
> few
> open bugs in Bugzilla, for example (selected list follows)
>
> SimpleLog4JLogSystem closes appenders
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9039
Still waiting for an answer on that, I thought, from the original
poster.
>
> LogSystem NPE s
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19137
>
Yep
> Memory/logger leak with multiple VelocityEngine instances
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21720
Well, this is more complicated - the example given, the code is
creating multiple simultaneous VelEngines. There's no reason to
believe any are being garbage collected, so there is no release of
resources. Re the 'too many open files', that's not a huge surprise
depending on the OS, but the log4j example indicates a real problem
somewhere.
>
> SimpleLog4JLogSystem property lookup should come from RuntimeConstants
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23676
IIRC, not really a bug but a change.
>
> WILL
>
> ----- Original Message -----
> From: "Geir Magnusson Jr" <ge...@4quarters.com>
> To: "Velocity Developers List" <ve...@jakarta.apache.org>
> Sent: Sunday, February 08, 2004 5:37 PM
> Subject: Re: Hello All
>
>
> Warning - long one, but if you are interested in the topic, read
> through. Nathan spent time on his post, and I did also.
>
> If you don't care, don't bother.
>
> On Feb 8, 2004, at 6:21 PM, Nathan Bubna wrote:
>
>> Geir Magnusson Jr said:
>>> On Feb 8, 2004, at 1:49 PM, Marinó A. Jónsson wrote:
>>>>>> for the record - c-l in Vel (or any middleware) does NOT force the
>>>>>> userbase
>>>>>> to use c-l.
>>>>>
>>>>> That's not true. You must have c-l around in your cp for any
>>>>> component
>>>>> that uses it.
>>>>
>>>> true, but I think it's misleading to say that it is "forcing the
>>>> userbase to
>>>> have to use c-l exclusively" if Vel depends on it - but the user is
>>>> free to
>>>> use any logging solution he desires.
>>>
>>> I'm not sure I said 'exclusively'.
>>>
>>> it forces c-l to be around, and generally speaking adds a runtime
>>> configuration requirement to deal with the logging.
>>
>> i call double-standard. we already require or include
>> commons-collections.
>
> It would be a double standard if we were advocating getting another
> dependency at the same time which rejecting c-l for getting a
> dependency.
>
> This was before your time I think, but commons collections was seeded
> by us, with the ExtendedProperties that we contributed (after stealing
> from Turbine...), IIRC. Then we decided to support the effort by using
> it. We had a big fight once when the c-c committers wanted to change
> things out from underneath us. If we were smart we would have let them
> and just dropped the dependency. One class, that was in our codebase
> in the first place. Others might call it a 'mistake' rather than a
> 'double-standard'.
>
> Remember, my opposition to just switching lock, stock and barrel to c-l
> isn't just about a dependency. It's actually the weakest of my
> arguments against it. The biggest reason is that I don't think we
> should force users to only use it and give up the injection pattern.
> From the beginning of this thread, I've been in full support of a c-l
> adapter that people could choose to use.
>
>>
>> and since when do people dislike having "standard" (aka common)
>> runtime
>> configuration options? especially for logging!
>
> Well, apparently there was a huge dislike. :)
>
> There was log4j for the longest time which seemed to satisfy everyone
> for everything. Except people at Sun, who decided to roll their own
> for jdk 1.4 rather than turn log4j into a JSR and roll into the 1.4
> umbrella JSR. And the the people in commons, who added to the insanity
> with ensuring the lowest common denominator support for logging through
> a common interface (although I do appreciate c-l's 'trace()' as it's
> part of my jihad to get log4j to add it...)
>
> I'm not against us making it easy that users can use vel w/ c-l, but I
> don't want it to be the only option. But we've been through this.
>
>>
>>>>> The model I like better is an 'early binding' discovery
>>>>> (like we have in Vel already) that find the logger to use based on
>>>>> what's in the CP. For example, if you don't use the -dep
>>>>> version, vel
>>>>> will search for logkit or log4j and use them if no other logging is
>>>>> specified.
>>>>
>>>> that's exactly what c-l does :)
>>>
>>> But you can programmatically not have Vel do it if you give it a
>>> logger
>>> before init(). How do you keep that level of control w/ c-l? I
>>> don't
>>> need a detailed example here - just a handwaving description will
>>> suffice.
>>
>> sure, you can make Velocity use c-l in such a way that you just pass
>> in/around
>> log instances. they're objects after all. it's just a matter of how
>> you use
>> them. you could replace LogSystem with c-l and have Velocity classes
>> log to
>> that one c-l instance that they access through the
>> Velocity/VelocityEngine
>> methods (warn, info, error, etc), and any app developers using
>> Velocity could
>> do the same. but then i don't really see much point in using c-l
>> either.
>> it's not just LogSystem i don't like, it's that whole approach to
>> logging.
>> IMHO, it's a PITA.
>
> Interesting. This is different from my perception of your position.
> Can you elaborate?
>
>>
>> personally, i prefer the static logger per class approach. you
>> clearly don't,
>> but in my experience, most people do. you have the commit power, but
>> you
>> generally appear to be in the minority around here. so i'd say we're
>> still
>> pretty much at a standstill since no one is changing their minds.
>> meanwhile,
>> the current LogSystem is still pretty skimpy on features and
>> useability. i
>> believe everyone agrees could use a lot of improvement regardless of
>> how.
>
> The issue of improving the log system is utterly unrelated to c-l, and
> something we about which we are in violent agreement. The kneejerk
> reaction to "just use c-l cuz it's a 'standard'" is what I'm against.
>
> Every time I implement a framework or -ish, I always use one level of
> indirection for my logging, building a simple Logger interface, a
> factory, and then an implementation that uses an existing, established
> logging framework, or c-l. It takes about 20 minutes, and then I reuse
> it if I legally can. This is what c-l does for you, but allows me the
> freedom of the pattern (which came from log4j) w/o the binding to the
> implementation.
>
> As I said, I generally follow the log4j pattern (which is what c-l
> copies) of having the ability to pull a logger out of the aether :
>
> Logger l = MyLogSystem.getLogger( <whatever > );
>
> Sometimes it's static for the class when appropriate, as you seem to
> like, although in situations where you have multiple, concurrent
> instances of the same class with a reasonable lifetime and output that
> needs to be differentiated for whatever reason (think something like a
> servlet container - different concurrent app execution - w/o the
> classloader boundaries to separate static class instances), I choose
> instance loggers rather than static class logger. I also generally
> have MyLogSystem implement the Logger interface methods statically, so
> I can
>
> MyLogSystem.error("Yikes...")
>
> when I want to in something lightweight like a small tool that would be
> used in an environment where failure of something (like sending email)
> is of interest to operations. I wouldn't require the user of that tool
> to think about logging via the CTOR....
>
> So, I think that you are mistaken in your assessment of how I use
> logging, and how I think it should be.
>
> I do the same thing everyone else does, and what sounds like a superset
> of what you do. I suspect others also do what I do, keeping a loose
> binding of that internal logging system to an external system like
> log4j or c-l, but I've never discussed it w/ anyone.
>
> I have no problem doing this in velocity, as it's what we do already re
> the pattern of decoupling, and agree we could improve via the static
> factory pattern. But I'll still push back against just using c-l as I
> still believe there is great power to continue to offer our current
> configuration pattern, giving the velocity user programmatic control of
> what's going on, explicitly setting the logger to which the internal
> logging happens. We can continue to keep the user experience as easy
> as possible for the uninterested by adding c-l to our automatic
> discovery.
>
>> really, we've been over all these things before.
>>
>>>>>> c-l "adapts" to the preferred logger so it's pretty transparent
>>>>>> to
>>>>>> the user :)
>>>>>
>>>>> Uh huh :) I'd like to keep velocity out of the commons-* fray.
>>>>> This
>>>>> POV, which I've held for a while, was recently confirmed when I
>>>>> upgraded to hibernate 2.1, which has what feels like a gazillion
>>>>> dependencies, all w/o any version numbers. To upgrade, I just had
>>>>> to
>>>>> shut my eyes and cp *.jar foo/lib and hope for the best.
>>>>>
>>>>> To be fair, it worked out ok, but I think that was more luck than
>>>>> design. If we can keep things as simple as possible, w/ minimalist
>>>>> dependencies, then I think that over the long run, we'll reduce the
>>>>> potential for problems.
>>>>
>>>> so it all comes down to dependency aversion - IOW using c-l puts
>>>> virtually
>>>> no restraints on users, but the c-l jar needs to be present in the
>>>> CL
>>>> so
>>>> it's a bad thing :)
>>>
>>> that's not what I'm saying. I do have dependency aversion, but read
>>> the bit above.
>>
>> agreed. you do have a dependency aversion, but you also have
>> significantly
>> different notions of the best way to do logging. in particular, it
>> seems you
>> think all components should develop their own simple adapters which
>> will all
>> need to be individually configured by the application developer,
>> instead of
>> having a pwerful common adapter that the developer need only configure
>> once.
>> :)
>
> Read above.
>
>>
>>>> Seems like a small price to pay IMO. I can sympathize
>>>> with your view on dependencies in general - but I think it needs to
>>>> be
>>>> addressed on a case-by-case basis ... and in this case I think the
>>>> pros
>>>> weigh much heavier than the cons.
>>>
>>> No, because if you want to use c-l, just make the 10 line adapter and
>>> use it. If not, use vel as is... you get both, and I don't have to
>>> deal with it...
>>
>> but as VelocityTools developers, we do have to deal with it. right
>> now, we
>> are using the singleton model. this lets the standard tools perform
>> logging
>> via the static Velocity.* logging methods. this is not ideal, but is
>> tolerable for the moment. however, we need to switch the
>> VelocityViewServlet
>> (and VelocityTools in general) from using the Velocity class to using
>> VelocityEngine. once we do this, the tools no longer have easy access
>> to
>> Velocity's logsystem. now, we could hack up some way to pass them the
>> VelocityEngine the servlet is using, but the thought of it just makes
>> me
>> cringe.
>
> Me too.
>
>>
>> as a user, i would rather need only to configure logging for each app
>> i work
>> on once and in one place. yes, i can pump Velocity log messages
>> through c-l
>> and vice-versa, but that's a dumb suggestion that seems to indicate
>> misunderstanding of the issues. it would just be pushing log messages
>> through
>> one more adapter (performance hit) before going to the actual logging
>> system i
>> am using for my application. that may be the most "reasonable"
>> solution for
>> anyone developing another *component* that uses Velocity (i fear this
>> will be
>> the fate of VelocityTools), but application developers have to
>> configure the
>> logging adapter of each component (e.g. Velocity) separately in order
>> to point
>> them to their one actual logging solution (Avalon, log4j, jdk1.4,
>> etc.). the
>> more components that develop their own logging adapters, the more of a
>> pain
>> this becomes.
>
> Not at all. Given automatic discovery, Velocity would find c-l if
> that's what you were using...
>
>>
>> also, switching to c-l (with the each-class-has-its-own-static-logger
>> paradigm)
>
> or log4j...
>
>> would give me the power to filter/silence/redirect log messages
>> according to source as well as severity. this would be nice since it
>> often
>> happens that i care about INFO (and WARN, DEBUG, etc) messages from
>> one class,
>> but not another.
>>
>> Geir, if you can't see where we're coming from on this by now, then i
>> don't
>> expect you ever will. and if you really do see it and just flat out
>> disagree,
>> just say so. you have the veto power of a committer and the influence
>> of the
>> project lead, so i don't want to waste time pushing on a brick wall
>> that won't
>> budge.
>
> read above. There are two issues here. One is the patterns, and the
> other is the implementation. C-l is the implementation. Re the
> patterns, I think that you can have what you want :
>
> - the convenience of pulling the logger via the static factory
> - making static class loggers via the same where you want to
> - the "light and get away" simplicity of it finding and using c-l w/o
> you having to think about it
>
> We both get
>
> - improvement in internal logging w/in velocity
>
> I get
>
> - keeping the programmatic control pattern for configuration freedom
>
> The only thing I believe I don't have a satisfactory answer for you is
> performance, as it's true we'd have to delegate through methods in the
> internal façade. However, I'm not sure that's really a big enough deal
> to worry about, as c-l does the same thing anyway, and I've never heard
> that as an arg for not using c-l ;)
>
> I bet the original poster had no clue what he was getting into...
>
> :D
>
> geir
>
>
>>
>> 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-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
>
>
> ---------------------------------------------------------------------
> 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-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: Hello All
Posted by Will Glass-Husain <wg...@forio.com>.
Hmm... interesting exchange, and not entirely a repeat of the previous one.
Three quick thoughts. Maybe this is an opportunity for consensus?
(1) Seems to me that automatic discovery of C-L would be a good compromise.
(2) It'd be nice if the docs had a clear recipe for setting up a log for
those users who really don't care which of the 3 default solutions are used
(or is it 4).
(3) Regardless, it'd be nice to improve the log capability. There's a few
open bugs in Bugzilla, for example (selected list follows)
SimpleLog4JLogSystem closes appenders
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9039
LogSystem NPE s
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19137
Memory/logger leak with multiple VelocityEngine instances
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21720
SimpleLog4JLogSystem property lookup should come from RuntimeConstants
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23676
WILL
----- Original Message -----
From: "Geir Magnusson Jr" <ge...@4quarters.com>
To: "Velocity Developers List" <ve...@jakarta.apache.org>
Sent: Sunday, February 08, 2004 5:37 PM
Subject: Re: Hello All
Warning - long one, but if you are interested in the topic, read
through. Nathan spent time on his post, and I did also.
If you don't care, don't bother.
On Feb 8, 2004, at 6:21 PM, Nathan Bubna wrote:
> Geir Magnusson Jr said:
>> On Feb 8, 2004, at 1:49 PM, Marinó A. Jónsson wrote:
>>>>> for the record - c-l in Vel (or any middleware) does NOT force the
>>>>> userbase
>>>>> to use c-l.
>>>>
>>>> That's not true. You must have c-l around in your cp for any
>>>> component
>>>> that uses it.
>>>
>>> true, but I think it's misleading to say that it is "forcing the
>>> userbase to
>>> have to use c-l exclusively" if Vel depends on it - but the user is
>>> free to
>>> use any logging solution he desires.
>>
>> I'm not sure I said 'exclusively'.
>>
>> it forces c-l to be around, and generally speaking adds a runtime
>> configuration requirement to deal with the logging.
>
> i call double-standard. we already require or include
> commons-collections.
It would be a double standard if we were advocating getting another
dependency at the same time which rejecting c-l for getting a
dependency.
This was before your time I think, but commons collections was seeded
by us, with the ExtendedProperties that we contributed (after stealing
from Turbine...), IIRC. Then we decided to support the effort by using
it. We had a big fight once when the c-c committers wanted to change
things out from underneath us. If we were smart we would have let them
and just dropped the dependency. One class, that was in our codebase
in the first place. Others might call it a 'mistake' rather than a
'double-standard'.
Remember, my opposition to just switching lock, stock and barrel to c-l
isn't just about a dependency. It's actually the weakest of my
arguments against it. The biggest reason is that I don't think we
should force users to only use it and give up the injection pattern.
From the beginning of this thread, I've been in full support of a c-l
adapter that people could choose to use.
>
> and since when do people dislike having "standard" (aka common) runtime
> configuration options? especially for logging!
Well, apparently there was a huge dislike. :)
There was log4j for the longest time which seemed to satisfy everyone
for everything. Except people at Sun, who decided to roll their own
for jdk 1.4 rather than turn log4j into a JSR and roll into the 1.4
umbrella JSR. And the the people in commons, who added to the insanity
with ensuring the lowest common denominator support for logging through
a common interface (although I do appreciate c-l's 'trace()' as it's
part of my jihad to get log4j to add it...)
I'm not against us making it easy that users can use vel w/ c-l, but I
don't want it to be the only option. But we've been through this.
>
>>>> The model I like better is an 'early binding' discovery
>>>> (like we have in Vel already) that find the logger to use based on
>>>> what's in the CP. For example, if you don't use the -dep
>>>> version, vel
>>>> will search for logkit or log4j and use them if no other logging is
>>>> specified.
>>>
>>> that's exactly what c-l does :)
>>
>> But you can programmatically not have Vel do it if you give it a
>> logger
>> before init(). How do you keep that level of control w/ c-l? I don't
>> need a detailed example here - just a handwaving description will
>> suffice.
>
> sure, you can make Velocity use c-l in such a way that you just pass
> in/around
> log instances. they're objects after all. it's just a matter of how
> you use
> them. you could replace LogSystem with c-l and have Velocity classes
> log to
> that one c-l instance that they access through the
> Velocity/VelocityEngine
> methods (warn, info, error, etc), and any app developers using
> Velocity could
> do the same. but then i don't really see much point in using c-l
> either.
> it's not just LogSystem i don't like, it's that whole approach to
> logging.
> IMHO, it's a PITA.
Interesting. This is different from my perception of your position.
Can you elaborate?
>
> personally, i prefer the static logger per class approach. you
> clearly don't,
> but in my experience, most people do. you have the commit power, but
> you
> generally appear to be in the minority around here. so i'd say we're
> still
> pretty much at a standstill since no one is changing their minds.
> meanwhile,
> the current LogSystem is still pretty skimpy on features and
> useability. i
> believe everyone agrees could use a lot of improvement regardless of
> how.
The issue of improving the log system is utterly unrelated to c-l, and
something we about which we are in violent agreement. The kneejerk
reaction to "just use c-l cuz it's a 'standard'" is what I'm against.
Every time I implement a framework or -ish, I always use one level of
indirection for my logging, building a simple Logger interface, a
factory, and then an implementation that uses an existing, established
logging framework, or c-l. It takes about 20 minutes, and then I reuse
it if I legally can. This is what c-l does for you, but allows me the
freedom of the pattern (which came from log4j) w/o the binding to the
implementation.
As I said, I generally follow the log4j pattern (which is what c-l
copies) of having the ability to pull a logger out of the aether :
Logger l = MyLogSystem.getLogger( <whatever > );
Sometimes it's static for the class when appropriate, as you seem to
like, although in situations where you have multiple, concurrent
instances of the same class with a reasonable lifetime and output that
needs to be differentiated for whatever reason (think something like a
servlet container - different concurrent app execution - w/o the
classloader boundaries to separate static class instances), I choose
instance loggers rather than static class logger. I also generally
have MyLogSystem implement the Logger interface methods statically, so
I can
MyLogSystem.error("Yikes...")
when I want to in something lightweight like a small tool that would be
used in an environment where failure of something (like sending email)
is of interest to operations. I wouldn't require the user of that tool
to think about logging via the CTOR....
So, I think that you are mistaken in your assessment of how I use
logging, and how I think it should be.
I do the same thing everyone else does, and what sounds like a superset
of what you do. I suspect others also do what I do, keeping a loose
binding of that internal logging system to an external system like
log4j or c-l, but I've never discussed it w/ anyone.
I have no problem doing this in velocity, as it's what we do already re
the pattern of decoupling, and agree we could improve via the static
factory pattern. But I'll still push back against just using c-l as I
still believe there is great power to continue to offer our current
configuration pattern, giving the velocity user programmatic control of
what's going on, explicitly setting the logger to which the internal
logging happens. We can continue to keep the user experience as easy
as possible for the uninterested by adding c-l to our automatic
discovery.
> really, we've been over all these things before.
>
>>>>> c-l "adapts" to the preferred logger so it's pretty transparent to
>>>>> the user :)
>>>>
>>>> Uh huh :) I'd like to keep velocity out of the commons-* fray.
>>>> This
>>>> POV, which I've held for a while, was recently confirmed when I
>>>> upgraded to hibernate 2.1, which has what feels like a gazillion
>>>> dependencies, all w/o any version numbers. To upgrade, I just had
>>>> to
>>>> shut my eyes and cp *.jar foo/lib and hope for the best.
>>>>
>>>> To be fair, it worked out ok, but I think that was more luck than
>>>> design. If we can keep things as simple as possible, w/ minimalist
>>>> dependencies, then I think that over the long run, we'll reduce the
>>>> potential for problems.
>>>
>>> so it all comes down to dependency aversion - IOW using c-l puts
>>> virtually
>>> no restraints on users, but the c-l jar needs to be present in the CL
>>> so
>>> it's a bad thing :)
>>
>> that's not what I'm saying. I do have dependency aversion, but read
>> the bit above.
>
> agreed. you do have a dependency aversion, but you also have
> significantly
> different notions of the best way to do logging. in particular, it
> seems you
> think all components should develop their own simple adapters which
> will all
> need to be individually configured by the application developer,
> instead of
> having a pwerful common adapter that the developer need only configure
> once.
> :)
Read above.
>
>>> Seems like a small price to pay IMO. I can sympathize
>>> with your view on dependencies in general - but I think it needs to
>>> be
>>> addressed on a case-by-case basis ... and in this case I think the
>>> pros
>>> weigh much heavier than the cons.
>>
>> No, because if you want to use c-l, just make the 10 line adapter and
>> use it. If not, use vel as is... you get both, and I don't have to
>> deal with it...
>
> but as VelocityTools developers, we do have to deal with it. right
> now, we
> are using the singleton model. this lets the standard tools perform
> logging
> via the static Velocity.* logging methods. this is not ideal, but is
> tolerable for the moment. however, we need to switch the
> VelocityViewServlet
> (and VelocityTools in general) from using the Velocity class to using
> VelocityEngine. once we do this, the tools no longer have easy access
> to
> Velocity's logsystem. now, we could hack up some way to pass them the
> VelocityEngine the servlet is using, but the thought of it just makes
> me
> cringe.
Me too.
>
> as a user, i would rather need only to configure logging for each app
> i work
> on once and in one place. yes, i can pump Velocity log messages
> through c-l
> and vice-versa, but that's a dumb suggestion that seems to indicate
> misunderstanding of the issues. it would just be pushing log messages
> through
> one more adapter (performance hit) before going to the actual logging
> system i
> am using for my application. that may be the most "reasonable"
> solution for
> anyone developing another *component* that uses Velocity (i fear this
> will be
> the fate of VelocityTools), but application developers have to
> configure the
> logging adapter of each component (e.g. Velocity) separately in order
> to point
> them to their one actual logging solution (Avalon, log4j, jdk1.4,
> etc.). the
> more components that develop their own logging adapters, the more of a
> pain
> this becomes.
Not at all. Given automatic discovery, Velocity would find c-l if
that's what you were using...
>
> also, switching to c-l (with the each-class-has-its-own-static-logger
> paradigm)
or log4j...
> would give me the power to filter/silence/redirect log messages
> according to source as well as severity. this would be nice since it
> often
> happens that i care about INFO (and WARN, DEBUG, etc) messages from
> one class,
> but not another.
>
> Geir, if you can't see where we're coming from on this by now, then i
> don't
> expect you ever will. and if you really do see it and just flat out
> disagree,
> just say so. you have the veto power of a committer and the influence
> of the
> project lead, so i don't want to waste time pushing on a brick wall
> that won't
> budge.
read above. There are two issues here. One is the patterns, and the
other is the implementation. C-l is the implementation. Re the
patterns, I think that you can have what you want :
- the convenience of pulling the logger via the static factory
- making static class loggers via the same where you want to
- the "light and get away" simplicity of it finding and using c-l w/o
you having to think about it
We both get
- improvement in internal logging w/in velocity
I get
- keeping the programmatic control pattern for configuration freedom
The only thing I believe I don't have a satisfactory answer for you is
performance, as it's true we'd have to delegate through methods in the
internal façade. However, I'm not sure that's really a big enough deal
to worry about, as c-l does the same thing anyway, and I've never heard
that as an arg for not using c-l ;)
I bet the original poster had no clue what he was getting into...
:D
geir
>
> 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-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
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Hello All
Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr said:
> On Feb 9, 2004, at 7:30 PM, Nathan Bubna wrote:
> > Geir Magnusson Jr said:
> >> On Feb 9, 2004, at 12:56 PM, Marinó A. Jónsson wrote:
...
> >>>> How do you access features of log4j that aren't in the logger
> >>>> interface?
> > ...
> >> Oh, just answer the question.... You were arguing that c-l's lcd
> >> approach to logging is quite sufficient.
> >
> > you left off two very key words. you should've said "...quite
> > sufficient
> > <em>for middleware</em>" that distinction is absolutely critical here
> > and it
> > is frustrating that you frequently ignore it.
> >
>
> It's actually a new meme in the last two messages, trying now to
> distinguish between middleware and application software.
no. the language i'm using is new, but i've been trying to set out the
distinction from ages past. so, it's not a new meme, so much as it is that i
may finally be having success in propogating it. :)
> And I don't get the point. Define middleware... I think of things
> like message brokers, containers, and such to be middleware, and quite
> frankly, I think adding containers is a stretch.
yeah, sorry, i'm still not settled on the language. (i.e. "components" vs.
"middleware"). personally, i prefer "components", but since someone (Marino?)
brought in the "middleware" term, i thought i'd try paralleling the two words.
my thinking was along the lines of "middleware could arguably be everything
between the jdk and the end application because those are the 'ends'." but
really, application components (e.g. Velocity, Struts, commons-*, etc.) are
what i deal with in my job and are what i'm concerned about. you're right
that "middleware" is generally not used to refer to these. i'll stick to
"components" unless someone's got a better term.
...
> > i can and do take advantage of new, non-commons-logging features
> > in log4j in my applications that use components that depend on c-l.
> > Struts and all of it's commons cohorts use c-l, and i know that both
> > myself and others who use Struts simply point c-l to log4j for our
> > applications and are able to use NDC and all those other wonderful
> > log4j toys in our applications without problem.
>
> So you skip c-l and just use log4j? I've must have just plain missed
> the c-l API's that allow you to safely use a specific logging system
> like that.
yeah, that's the point. c-l is for components. it gives them all the power
that they typically need, while allowing the application developer the freedom
to use whatever logging system they want for their application, and point the
components using c-l either to that system or any other of their choice.
really, c-l is about giving the application developer the freedom to use any
logging system of their choice and all of it's features. i see this as the
same basic purpose of Velocity's LogSystem.
...
> >> But I'd also be happy to do something like
> >>
> >> Middleware m = new Middleware(middlewareLogger);
> >>
> >> This sort if insertion of dependencies is a PERFECTLY VALID if I want
> >> to do it that way (see recent rage of lightweight IoC containers, for
> >> example).
> >>
> >> I'd also like to be able to do things like :
> >>
> >> Middleware m1 = new Middleware(middlewareLogger1);
> >> Middleware m2 = new Middleware(middlewareLogger2);
> >
> > yeah, while it may be possible with c-l, it would probably be sketchy.
> > so, i
> > agree, c-l is not designed for this pattern. of course, neither is
> > log4j (i'm
> > less sure about LogKit or jdk1.4 since i don't use them). so, all
> > question of
> > technical merit aside, as far as i can see, this is a less common
> > pattern.
>
> It's a less common pattern, but still an important and valid one. I
> think as we see people moving from heavyweight to lightweight
> containers, you'll start to see this sort of injection pattern more and
> more.
>
> For example, you could have a container (there are some that do this,
> like pico) that will look at the CTORs and available component classes,
> and construct what it can from what's it's been given.
>
> So you could have
>
> public class Foo {
>
> public Foo(MyLogger logger) {
> ...
> }
> }
>
> and a class
>
> public class DevNullLogger implements MyLogger {
> ...
> }
>
> and then tell the container that it has a Foo, a DevNullLogger, and to
> go to town and figure things out....
>
> IMO, this is a good pattern.
i haven't worked with this pattern, but i can see that it has its place. my
question is whether or not a logging adapter can be created-for/used-in a
component in such a way that both patterns are possible? or would that just
be ridiculous?
> >> Or
> >>
> >> Middleware m = new Middleware(null);
> >>
> >> to shut off the logging when i don't care.
> >>
> >> How do I do that w/ c-l?
> > ...
> >
> > while this is not _how_ you would shut off logging with the c-l/log4j
> > pattern,
> > it is still quite easy to silence logging with them as well.
>
> A code sample would be wonderful. (Not a configuration sample, please)
the "how" for log4j is configuration. afaik, you can configure by code, but
most don't do this.
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: Hello All
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Feb 9, 2004, at 7:30 PM, Nathan Bubna wrote:
> Geir Magnusson Jr said:
>> On Feb 9, 2004, at 12:56 PM, Marinó A. Jónsson wrote:
> ...
>>> Sorry if I have been vague :) I'm arguing for dropping LogSystem in
>>> favour of c-l. What you are proposing is an adapter to the adapter -
>>> and that, IMO, is silly.
>>
>> it would be entirely silly if c-l was just an adapter, in the sense of
>> a common interface. But it isn't. It's a logging system in itself,
>> as
>> well as a logging implementation finder, which is more than an
>> adapter.
>
> i must disagree. my understanding and experience is that c-l is
> designed and
> intended to be an adapter. from the c-l site itself, "The Logging
> package is
> an ultra-thin bridge between different logging libraries." how do you
> read
> that?
Like you read it. But it's not the whole story. It's also a logger
too, as it includes one, o.a.c.impl.SimpleLog
This really is besides the point, btw :)
>
> ...
>>>> How do you access features of log4j that aren't in the logger
>>>> interface?
> ...
>> Oh, just answer the question.... You were arguing that c-l's lcd
>> approach to logging is quite sufficient.
>
> you left off two very key words. you should've said "...quite
> sufficient
> <em>for middleware</em>" that distinction is absolutely critical here
> and it
> is frustrating that you frequently ignore it.
>
It's actually a new meme in the last two messages, trying now to
distinguish between middleware and application software.
And I don't get the point. Define middleware... I think of things
like message brokers, containers, and such to be middleware, and quite
frankly, I think adding containers is a stretch.
>> I ask you, how do you take
>> advantage of new features in logging systems? The answer is you
>> can't.
>
> that's not true at all!
>
> i can and do take advantage of new, non-commons-logging features in
> log4j in
> my applications that use components that depend on c-l. Struts and
> all of
> it's commons cohorts use c-l, and i know that both myself and others
> who use
> Struts simply point c-l to log4j for our applications and are able to
> use NDC
> and all those other wonderful log4j toys in our applications without
> problem.
So you skip c-l and just use log4j? I've must have just plain missed
the c-l API's that allow you to safely use a specific logging system
like that.
>
> ...
>> I think you need to be clear here. I prefer when my middleware is
>> logs
>> to it's own logging. I don't want middleware logging into my logs. I
>> experience nothing but annoyance when things like JMS client libraries
>> (a true middleware) barf into my logs of high level app info. (and
>> yes, I know that w/ log4j, I just configure to put middleware spew
>> into
>> a separate log...)
>
> ah ha! here we have a genuine disagreement. you want components to
> log
> separately by default (without having to tell log4j to do it), and
> i/we do
> not. i want my components' log output to stay together unless i tell
> them to
> be separate. i see no recourse for us here but to agree to disagree.
If you want to phrase it that way, sure. I see that we just have
different preferences, and both should be easily supported in anything
we do.
I prefer components to just shut up and do their job, and thow an
exception or indicate problems w/ a return value.
(And note that you changed subject, from middleware to components. I
don't consider my JMS broker a component, in the sense that httpclient
is a component.)
>
> ...
>> But I'd also be happy to do something like
>>
>> Middleware m = new Middleware(middlewareLogger);
>>
>> This sort if insertion of dependencies is a PERFECTLY VALID if I want
>> to do it that way (see recent rage of lightweight IoC containers, for
>> example).
>>
>> I'd also like to be able to do things like :
>>
>> Middleware m1 = new Middleware(middlewareLogger1);
>> Middleware m2 = new Middleware(middlewareLogger2);
>
> yeah, while it may be possible with c-l, it would probably be sketchy.
> so, i
> agree, c-l is not designed for this pattern. of course, neither is
> log4j (i'm
> less sure about LogKit or jdk1.4 since i don't use them). so, all
> question of
> technical merit aside, as far as i can see, this is a less common
> pattern.
It's a less common pattern, but still an important and valid one. I
think as we see people moving from heavyweight to lightweight
containers, you'll start to see this sort of injection pattern more and
more.
For example, you could have a container (there are some that do this,
like pico) that will look at the CTORs and available component classes,
and construct what it can from what's it's been given.
So you could have
public class Foo {
public Foo(MyLogger logger) {
...
}
}
and a class
public class DevNullLogger implements MyLogger {
...
}
and then tell the container that it has a Foo, a DevNullLogger, and to
go to town and figure things out....
IMO, this is a good pattern.
>
>> Or
>>
>> Middleware m = new Middleware(null);
>>
>> to shut off the logging when i don't care.
>>
>> How do I do that w/ c-l?
> ...
>
> while this is not _how_ you would shut off logging with the c-l/log4j
> pattern,
> it is still quite easy to silence logging with them as well.
A code sample would be wonderful. (Not a configuration sample, please)
geir
>
> 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-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: Hello All
Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr said:
> On Feb 9, 2004, at 12:56 PM, Marinó A. Jónsson wrote:
...
> > Sorry if I have been vague :) I'm arguing for dropping LogSystem in
> > favour of c-l. What you are proposing is an adapter to the adapter -
> > and that, IMO, is silly.
>
> it would be entirely silly if c-l was just an adapter, in the sense of
> a common interface. But it isn't. It's a logging system in itself, as
> well as a logging implementation finder, which is more than an adapter.
i must disagree. my understanding and experience is that c-l is designed and
intended to be an adapter. from the c-l site itself, "The Logging package is
an ultra-thin bridge between different logging libraries." how do you read
that?
...
> >> How do you access features of log4j that aren't in the logger
> >> interface?
...
> Oh, just answer the question.... You were arguing that c-l's lcd
> approach to logging is quite sufficient.
you left off two very key words. you should've said "...quite sufficient
<em>for middleware</em>" that distinction is absolutely critical here and it
is frustrating that you frequently ignore it.
> I ask you, how do you take
> advantage of new features in logging systems? The answer is you can't.
that's not true at all!
i can and do take advantage of new, non-commons-logging features in log4j in
my applications that use components that depend on c-l. Struts and all of
it's commons cohorts use c-l, and i know that both myself and others who use
Struts simply point c-l to log4j for our applications and are able to use NDC
and all those other wonderful log4j toys in our applications without problem.
...
> I think you need to be clear here. I prefer when my middleware is logs
> to it's own logging. I don't want middleware logging into my logs. I
> experience nothing but annoyance when things like JMS client libraries
> (a true middleware) barf into my logs of high level app info. (and
> yes, I know that w/ log4j, I just configure to put middleware spew into
> a separate log...)
ah ha! here we have a genuine disagreement. you want components to log
separately by default (without having to tell log4j to do it), and i/we do
not. i want my components' log output to stay together unless i tell them to
be separate. i see no recourse for us here but to agree to disagree.
...
> But I'd also be happy to do something like
>
> Middleware m = new Middleware(middlewareLogger);
>
> This sort if insertion of dependencies is a PERFECTLY VALID if I want
> to do it that way (see recent rage of lightweight IoC containers, for
> example).
>
> I'd also like to be able to do things like :
>
> Middleware m1 = new Middleware(middlewareLogger1);
> Middleware m2 = new Middleware(middlewareLogger2);
yeah, while it may be possible with c-l, it would probably be sketchy. so, i
agree, c-l is not designed for this pattern. of course, neither is log4j (i'm
less sure about LogKit or jdk1.4 since i don't use them). so, all question of
technical merit aside, as far as i can see, this is a less common pattern.
> Or
>
> Middleware m = new Middleware(null);
>
> to shut off the logging when i don't care.
>
> How do I do that w/ c-l?
...
while this is not _how_ you would shut off logging with the c-l/log4j pattern,
it is still quite easy to silence logging with them as well.
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: Hello All
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Feb 9, 2004, at 4:12 PM, Rob Harrop wrote:
> First off all I am new so I may be well out of order here I just have
> a few
> points to make that may be slightly different.
>
> 1. Despite the fact that Commons Logging comes with a provider, it
> acheives
> the same goal as LogSystem, in that is decouples the applications that
> wants
> to write log messages from the tool performing the actual logging.
A similar goal. The problem that I've always had with it is that you
can't simply hand it a 'thingy' (don't want to use 'logger') for the
log messages to go into. That may have changed, but I don't think so.
All I want to do is hand it my thingy.... :)
I tried a while back, for vel-tools, to get the c-l project to add a
marker interface like
interface DoesLogging {
setLogger(Logger logger);
}
so that a component could indicate and accept a c-l logger from its
instantiating container, as i think its just gauche when a component
babbles w/o being asked to...
Clearly the world recognizes that there is more to this issue than the
c-l pattern (the log4j pattern actually). It's actually general for
any kind of resource - and while this pattern will survive because
it's useful, the patterns that you see in current "IoC" containers are
also important, and that's what I'm trying to prevent losing.
>
> 2. Commons Logging is just that - common.
least common :)
> I have experience teaching people
> to use various tools such as Velocity, struts and Hibernate. I have
> found it
> annoying and confusing that I have to show my developers two different
> logging setups.
With what I'm advocating, you could still ignore the logging and just
have it use c-l, but they would have choices if you wanted to $DEITY
forbid, do something different. The fact that the logger Velocity uses
internally isn't plain-vanilla c-l should be utterly irrelevant to
them.
>
> 3. Commons Logging is an active project that focuses on one thing and
> in IMO
> does it very well. I don't see what benefit the Velocity project gets
> for
> having it's own custom solution, when a perfectly good quasi-standard
> tool
> already exists.
I don't know how to answer that one. I don't mind being different when
there is a better way. (Hence velocity vs JSP...)
And the same argument applied with s/c-l/log4j/ when c-l was being
proposed.... :)
geir
>
>
> Rob Harrop
>
>
> On 9/2/04 9:01 pm, "Geir Magnusson Jr" <ge...@4quarters.com> wrote:
>
>>
>> On Feb 9, 2004, at 12:56 PM, Marinó A. Jónsson wrote:
>>
>>>>> Once again - users don't need to use it even though Vel depended on
>>>>> it. The
>>>>> user could use i.e. Log4J directly if he wanted to - in
>>>> which case Vel
>>>>> would
>>>>> use Log4J too (via c-l). So your "biggest reason" sounds
>>>> pretty weak
>>>>> to me
>>>>> :)
>>>>
>>>> You are missing my point.
>>>
>>> Well, I think you are missing mine.
>>
>> That's not an answer, but I'll take the bait :
>>
>> What is your point?
>>
>>>
>>>>>> From the beginning of this thread, I've been in full support of a
>>>>>> c-l adapter that people could choose to use
>>>>>
>>>>> Now that's just plain silly :)
>>>>
>>>> Why? What are you arguing for if not c-l?
>>>
>>> Sorry if I have been vague :) I'm arguing for dropping LogSystem in
>>> favour
>>> of c-l. What you are proposing is an adapter to the adapter - and
>>> that,
>>> IMO, is silly.
>>
>> it would be entirely silly if c-l was just an adapter, in the sense of
>> a common interface. But it isn't. It's a logging system in itself,
>> as
>> well as a logging implementation finder, which is more than an
>> adapter.
>>
>>>
>>>>> However this lowest common demoninator is quite sufficient for
>>>>> middleware,
>>>>> like Vel, that has simple logging needs and shouldn't impose any
>>>>> logging
>>>>> restrictions on the projects using it (except of course for
>>>> the c-l jar
>>>>> dependency - which is not much of a restriction IMO).
>>>>
>>>> How do you access features of log4j that aren't in the logger
>>>> interface?
>>>
>>> This, I think, is the root of your misunderstanding.
>>
>> Oh, just answer the question.... You were arguing that c-l's lcd
>> approach to logging is quite sufficient. I ask you, how do you take
>> advantage of new features in logging systems? The answer is you
>> can't.
>> That's an ok answer, btw, if you also say "and I don't care". But it
>> doesn't change the issue at all.
>>
>>> First off I want to
>>> emphasize the semantic distinction between middleware developers and
>>> application developers (see Nathan's post on the subject)
>>
>> [I'm still responding to that]
>>
>>> - this case refers
>>> to application developers. Although you have c-l in the classpath,
>>> and
>>> various middleware components use it to route their log messages to
>>> your
>>> preferred logging solution, you don't need to route the log messages
>>> for
>>> _your_ project through c-l too! You can act as if c-l wasn't there
>>> at
>>> all!
>>
>> I think you need to be clear here. I prefer when my middleware is
>> logs
>> to it's own logging. I don't want middleware logging into my logs. I
>> experience nothing but annoyance when things like JMS client libraries
>> (a true middleware) barf into my logs of high level app info. (and
>> yes, I know that w/ log4j, I just configure to put middleware spew
>> into
>> a separate log...)
>>
>>>
>>> By "the logger interface" I assume you are under the impression that
>>> you can
>>> have only one logger interface for both the middleware and your
>>> project.
>>
>> I'm not really sure what you are getting at.
>>
>>> Not so - you just use i.e. org.apache.log4j.Logger directly in your
>>> project
>>> while the middleware would use org.apache.commons.logging.Log to
>>> access the
>>> "true" logging solution (in this case Log4J). This way the
>>> middleware
>>> doesn't impose any logging restrictions, but offers central logging
>>> configuration for the whole application (in this case the Log4J
>>> conf).
>>
>> That's all well and good. But I'd also be happy to do something like
>>
>> Middleware m = new Middleware(middlewareLogger);
>>
>> This sort if insertion of dependencies is a PERFECTLY VALID if I want
>> to do it that way (see recent rage of lightweight IoC containers, for
>> example).
>>
>> I'd also like to be able to do things like :
>>
>> Middleware m1 = new Middleware(middlewareLogger1);
>> Middleware m2 = new Middleware(middlewareLogger2);
>>
>> Or
>>
>> Middleware m = new Middleware(null);
>>
>> to shut off the logging when i don't care.
>>
>> How do I do that w/ c-l?
>>
>>>
>>>>>> I'm not against us making it easy that users can use vel
>>>> w/ c-l, but
>>>>>> I don't want it to be the only option. But we've been
>>>> through this.
>>>>>
>>>>> Amazingly yes, over and over again ... a brick wall it is,
>>>> I guess ;)
>>>>
>>>> You can keep ignoring what I'm saying, and then indeed we'll have a
>>>> brick wall....
>>>
>>> I'm definitely not ignoring what you're saying - but from it I can
>>> only
>>> deduce that you are labouring under a terribly persistent
>>> misconception
>>> about c-l.
>>
>> Ok. That's possible. To address that, rather than debate container
>> patterns, I'll start another thread w/ a proposal. From that we can
>> argue the technical merits of the proposed solution.
>>
>>>
>>>> I'm confused about what you want. is it c-l only,
>>>> improvements to the
>>>> internal logging, or both, or none?
>>>
>>> Preferrably c-l only - but in case that is not an option I agree with
>>> Nathan
>>> that improvements to the internal logging are needed.
>>
>> And if you read what I said, I say the same thing. There *no*
>> disagreement there.... What I'm fighting is the inability to
>> differentiate between our choice of logging pattern in Velocity
>> (which,
>> to belabor, I agree can be improved) and the logging implementation
>> that we choose to do it with.
>>
>> geir
>>
>>>
>>> Marinó
>>>
>>>>
>>>> geir
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --------------------------------------------------------------------
>>>> -
>>>>> 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-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
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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-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: Hello All
Posted by Rob Harrop <ro...@robharrop.com>.
First off all I am new so I may be well out of order here I just have a few
points to make that may be slightly different.
1. Despite the fact that Commons Logging comes with a provider, it acheives
the same goal as LogSystem, in that is decouples the applications that wants
to write log messages from the tool performing the actual logging.
2. Commons Logging is just that - common. I have experience teaching people
to use various tools such as Velocity, struts and Hibernate. I have found it
annoying and confusing that I have to show my developers two different
logging setups.
3. Commons Logging is an active project that focuses on one thing and in IMO
does it very well. I don't see what benefit the Velocity project gets for
having it's own custom solution, when a perfectly good quasi-standard tool
already exists.
Rob Harrop
On 9/2/04 9:01 pm, "Geir Magnusson Jr" <ge...@4quarters.com> wrote:
>
> On Feb 9, 2004, at 12:56 PM, Marinó A. Jónsson wrote:
>
>>>> Once again - users don't need to use it even though Vel depended on
>>>> it. The
>>>> user could use i.e. Log4J directly if he wanted to - in
>>> which case Vel
>>>> would
>>>> use Log4J too (via c-l). So your "biggest reason" sounds
>>> pretty weak
>>>> to me
>>>> :)
>>>
>>> You are missing my point.
>>
>> Well, I think you are missing mine.
>
> That's not an answer, but I'll take the bait :
>
> What is your point?
>
>>
>>>>> From the beginning of this thread, I've been in full support of a
>>>>> c-l adapter that people could choose to use
>>>>
>>>> Now that's just plain silly :)
>>>
>>> Why? What are you arguing for if not c-l?
>>
>> Sorry if I have been vague :) I'm arguing for dropping LogSystem in
>> favour
>> of c-l. What you are proposing is an adapter to the adapter - and
>> that,
>> IMO, is silly.
>
> it would be entirely silly if c-l was just an adapter, in the sense of
> a common interface. But it isn't. It's a logging system in itself, as
> well as a logging implementation finder, which is more than an adapter.
>
>>
>>>> However this lowest common demoninator is quite sufficient for
>>>> middleware,
>>>> like Vel, that has simple logging needs and shouldn't impose any
>>>> logging
>>>> restrictions on the projects using it (except of course for
>>> the c-l jar
>>>> dependency - which is not much of a restriction IMO).
>>>
>>> How do you access features of log4j that aren't in the logger
>>> interface?
>>
>> This, I think, is the root of your misunderstanding.
>
> Oh, just answer the question.... You were arguing that c-l's lcd
> approach to logging is quite sufficient. I ask you, how do you take
> advantage of new features in logging systems? The answer is you can't.
> That's an ok answer, btw, if you also say "and I don't care". But it
> doesn't change the issue at all.
>
>> First off I want to
>> emphasize the semantic distinction between middleware developers and
>> application developers (see Nathan's post on the subject)
>
> [I'm still responding to that]
>
>> - this case refers
>> to application developers. Although you have c-l in the classpath, and
>> various middleware components use it to route their log messages to
>> your
>> preferred logging solution, you don't need to route the log messages
>> for
>> _your_ project through c-l too! You can act as if c-l wasn't there at
>> all!
>
> I think you need to be clear here. I prefer when my middleware is logs
> to it's own logging. I don't want middleware logging into my logs. I
> experience nothing but annoyance when things like JMS client libraries
> (a true middleware) barf into my logs of high level app info. (and
> yes, I know that w/ log4j, I just configure to put middleware spew into
> a separate log...)
>
>>
>> By "the logger interface" I assume you are under the impression that
>> you can
>> have only one logger interface for both the middleware and your
>> project.
>
> I'm not really sure what you are getting at.
>
>> Not so - you just use i.e. org.apache.log4j.Logger directly in your
>> project
>> while the middleware would use org.apache.commons.logging.Log to
>> access the
>> "true" logging solution (in this case Log4J). This way the middleware
>> doesn't impose any logging restrictions, but offers central logging
>> configuration for the whole application (in this case the Log4J conf).
>
> That's all well and good. But I'd also be happy to do something like
>
> Middleware m = new Middleware(middlewareLogger);
>
> This sort if insertion of dependencies is a PERFECTLY VALID if I want
> to do it that way (see recent rage of lightweight IoC containers, for
> example).
>
> I'd also like to be able to do things like :
>
> Middleware m1 = new Middleware(middlewareLogger1);
> Middleware m2 = new Middleware(middlewareLogger2);
>
> Or
>
> Middleware m = new Middleware(null);
>
> to shut off the logging when i don't care.
>
> How do I do that w/ c-l?
>
>>
>>>>> I'm not against us making it easy that users can use vel
>>> w/ c-l, but
>>>>> I don't want it to be the only option. But we've been
>>> through this.
>>>>
>>>> Amazingly yes, over and over again ... a brick wall it is,
>>> I guess ;)
>>>
>>> You can keep ignoring what I'm saying, and then indeed we'll have a
>>> brick wall....
>>
>> I'm definitely not ignoring what you're saying - but from it I can only
>> deduce that you are labouring under a terribly persistent misconception
>> about c-l.
>
> Ok. That's possible. To address that, rather than debate container
> patterns, I'll start another thread w/ a proposal. From that we can
> argue the technical merits of the proposed solution.
>
>>
>>> I'm confused about what you want. is it c-l only,
>>> improvements to the
>>> internal logging, or both, or none?
>>
>> Preferrably c-l only - but in case that is not an option I agree with
>> Nathan
>> that improvements to the internal logging are needed.
>
> And if you read what I said, I say the same thing. There *no*
> disagreement there.... What I'm fighting is the inability to
> differentiate between our choice of logging pattern in Velocity (which,
> to belabor, I agree can be improved) and the logging implementation
> that we choose to do it with.
>
> geir
>
>>
>> Marinó
>>
>>>
>>> geir
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>>> 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-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
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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: Hello All
Posted by Tim Colson <tc...@cisco.com>.
> >>> Now that's just plain silly :)
LOL - What's silly is grown men arguing about a log topic on a "Hello
All" thread, from a newbie chap who is planning to write a book about
Velocity and logging. <grin>
-Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Hello All
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Feb 9, 2004, at 12:56 PM, Marinó A. Jónsson wrote:
>>> Once again - users don't need to use it even though Vel depended on
>>> it. The
>>> user could use i.e. Log4J directly if he wanted to - in
>> which case Vel
>>> would
>>> use Log4J too (via c-l). So your "biggest reason" sounds
>> pretty weak
>>> to me
>>> :)
>>
>> You are missing my point.
>
> Well, I think you are missing mine.
That's not an answer, but I'll take the bait :
What is your point?
>
>>>> From the beginning of this thread, I've been in full support of a
>>>> c-l adapter that people could choose to use
>>>
>>> Now that's just plain silly :)
>>
>> Why? What are you arguing for if not c-l?
>
> Sorry if I have been vague :) I'm arguing for dropping LogSystem in
> favour
> of c-l. What you are proposing is an adapter to the adapter - and
> that,
> IMO, is silly.
it would be entirely silly if c-l was just an adapter, in the sense of
a common interface. But it isn't. It's a logging system in itself, as
well as a logging implementation finder, which is more than an adapter.
>
>>> However this lowest common demoninator is quite sufficient for
>>> middleware,
>>> like Vel, that has simple logging needs and shouldn't impose any
>>> logging
>>> restrictions on the projects using it (except of course for
>> the c-l jar
>>> dependency - which is not much of a restriction IMO).
>>
>> How do you access features of log4j that aren't in the logger
>> interface?
>
> This, I think, is the root of your misunderstanding.
Oh, just answer the question.... You were arguing that c-l's lcd
approach to logging is quite sufficient. I ask you, how do you take
advantage of new features in logging systems? The answer is you can't.
That's an ok answer, btw, if you also say "and I don't care". But it
doesn't change the issue at all.
> First off I want to
> emphasize the semantic distinction between middleware developers and
> application developers (see Nathan's post on the subject)
[I'm still responding to that]
> - this case refers
> to application developers. Although you have c-l in the classpath, and
> various middleware components use it to route their log messages to
> your
> preferred logging solution, you don't need to route the log messages
> for
> _your_ project through c-l too! You can act as if c-l wasn't there at
> all!
I think you need to be clear here. I prefer when my middleware is logs
to it's own logging. I don't want middleware logging into my logs. I
experience nothing but annoyance when things like JMS client libraries
(a true middleware) barf into my logs of high level app info. (and
yes, I know that w/ log4j, I just configure to put middleware spew into
a separate log...)
>
> By "the logger interface" I assume you are under the impression that
> you can
> have only one logger interface for both the middleware and your
> project.
I'm not really sure what you are getting at.
> Not so - you just use i.e. org.apache.log4j.Logger directly in your
> project
> while the middleware would use org.apache.commons.logging.Log to
> access the
> "true" logging solution (in this case Log4J). This way the middleware
> doesn't impose any logging restrictions, but offers central logging
> configuration for the whole application (in this case the Log4J conf).
That's all well and good. But I'd also be happy to do something like
Middleware m = new Middleware(middlewareLogger);
This sort if insertion of dependencies is a PERFECTLY VALID if I want
to do it that way (see recent rage of lightweight IoC containers, for
example).
I'd also like to be able to do things like :
Middleware m1 = new Middleware(middlewareLogger1);
Middleware m2 = new Middleware(middlewareLogger2);
Or
Middleware m = new Middleware(null);
to shut off the logging when i don't care.
How do I do that w/ c-l?
>
>>>> I'm not against us making it easy that users can use vel
>> w/ c-l, but
>>>> I don't want it to be the only option. But we've been
>> through this.
>>>
>>> Amazingly yes, over and over again ... a brick wall it is,
>> I guess ;)
>>
>> You can keep ignoring what I'm saying, and then indeed we'll have a
>> brick wall....
>
> I'm definitely not ignoring what you're saying - but from it I can only
> deduce that you are labouring under a terribly persistent misconception
> about c-l.
Ok. That's possible. To address that, rather than debate container
patterns, I'll start another thread w/ a proposal. From that we can
argue the technical merits of the proposed solution.
>
>> I'm confused about what you want. is it c-l only,
>> improvements to the
>> internal logging, or both, or none?
>
> Preferrably c-l only - but in case that is not an option I agree with
> Nathan
> that improvements to the internal logging are needed.
And if you read what I said, I say the same thing. There *no*
disagreement there.... What I'm fighting is the inability to
differentiate between our choice of logging pattern in Velocity (which,
to belabor, I agree can be improved) and the logging implementation
that we choose to do it with.
geir
>
> Marinó
>
>>
>> geir
>>
>>
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>>> 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-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
>>
>>
>
>
>
> ---------------------------------------------------------------------
> 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-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: Hello All
Posted by "Marinó A. Jónsson" <ma...@centrum.is>.
> > Once again - users don't need to use it even though Vel depended on
> > it. The
> > user could use i.e. Log4J directly if he wanted to - in
> which case Vel
> > would
> > use Log4J too (via c-l). So your "biggest reason" sounds
> pretty weak
> > to me
> > :)
>
> You are missing my point.
Well, I think you are missing mine.
> >> From the beginning of this thread, I've been in full support of a
> >> c-l adapter that people could choose to use
> >
> > Now that's just plain silly :)
>
> Why? What are you arguing for if not c-l?
Sorry if I have been vague :) I'm arguing for dropping LogSystem in favour
of c-l. What you are proposing is an adapter to the adapter - and that,
IMO, is silly.
> > However this lowest common demoninator is quite sufficient for
> > middleware,
> > like Vel, that has simple logging needs and shouldn't impose any
> > logging
> > restrictions on the projects using it (except of course for
> the c-l jar
> > dependency - which is not much of a restriction IMO).
>
> How do you access features of log4j that aren't in the logger
> interface?
This, I think, is the root of your misunderstanding. First off I want to
emphasize the semantic distinction between middleware developers and
application developers (see Nathan's post on the subject) - this case refers
to application developers. Although you have c-l in the classpath, and
various middleware components use it to route their log messages to your
preferred logging solution, you don't need to route the log messages for
_your_ project through c-l too! You can act as if c-l wasn't there at all!
By "the logger interface" I assume you are under the impression that you can
have only one logger interface for both the middleware and your project.
Not so - you just use i.e. org.apache.log4j.Logger directly in your project
while the middleware would use org.apache.commons.logging.Log to access the
"true" logging solution (in this case Log4J). This way the middleware
doesn't impose any logging restrictions, but offers central logging
configuration for the whole application (in this case the Log4J conf).
> >> I'm not against us making it easy that users can use vel
> w/ c-l, but
> >> I don't want it to be the only option. But we've been
> through this.
> >
> > Amazingly yes, over and over again ... a brick wall it is,
> I guess ;)
>
> You can keep ignoring what I'm saying, and then indeed we'll have a
> brick wall....
I'm definitely not ignoring what you're saying - but from it I can only
deduce that you are labouring under a terribly persistent misconception
about c-l.
> I'm confused about what you want. is it c-l only,
> improvements to the
> internal logging, or both, or none?
Preferrably c-l only - but in case that is not an option I agree with Nathan
that improvements to the internal logging are needed.
Marinó
>
> geir
>
>
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > 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-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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Hello All
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Feb 8, 2004, at 10:54 PM, Marinó A. Jónsson wrote:
> Geir said:
>> Remember, my opposition to just switching lock, stock and
>> barrel to c-l
>> isn't just about a dependency. It's actually the weakest of my
>> arguments against it. The biggest reason is that I don't think we
>> should force users to only use it and give up the injection pattern.
>
> Once again - users don't need to use it even though Vel depended on
> it. The
> user could use i.e. Log4J directly if he wanted to - in which case Vel
> would
> use Log4J too (via c-l). So your "biggest reason" sounds pretty weak
> to me
> :)
You are missing my point.
>
>> From the beginning of this thread, I've been in full support
>> of a c-l
>> adapter that people could choose to use
>
> Now that's just plain silly :)
Why? What are you arguing for if not c-l?
>
>> There was log4j for the longest time which seemed to satisfy everyone
>> for everything. Except people at Sun, who decided to roll their own
>> for jdk 1.4 rather than turn log4j into a JSR and roll into the 1.4
>> umbrella JSR. And the the people in commons, who added to
>> the insanity
>> with ensuring the lowest common denominator support for
>> logging through
>> a common interface (although I do appreciate c-l's 'trace()' as it's
>> part of my jihad to get log4j to add it...)
>
> However this lowest common demoninator is quite sufficient for
> middleware,
> like Vel, that has simple logging needs and shouldn't impose any
> logging
> restrictions on the projects using it (except of course for the c-l jar
> dependency - which is not much of a restriction IMO).
How do you access features of log4j that aren't in the logger interface?
>
>> I'm not against us making it easy that users can use vel w/
>> c-l, but I
>> don't want it to be the only option. But we've been through this.
>
> Amazingly yes, over and over again ... a brick wall it is, I guess ;)
You can keep ignoring what I'm saying, and then indeed we'll have a
brick wall....
I'm confused about what you want. is it c-l only, improvements to the
internal logging, or both, or none?
geir
>
>
>
> ---------------------------------------------------------------------
> 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-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: Hello All
Posted by "Marinó A. Jónsson" <ma...@centrum.is>.
Geir said:
> Remember, my opposition to just switching lock, stock and
> barrel to c-l
> isn't just about a dependency. It's actually the weakest of my
> arguments against it. The biggest reason is that I don't think we
> should force users to only use it and give up the injection pattern.
Once again - users don't need to use it even though Vel depended on it. The
user could use i.e. Log4J directly if he wanted to - in which case Vel would
use Log4J too (via c-l). So your "biggest reason" sounds pretty weak to me
:)
> From the beginning of this thread, I've been in full support
> of a c-l
> adapter that people could choose to use
Now that's just plain silly :)
> There was log4j for the longest time which seemed to satisfy everyone
> for everything. Except people at Sun, who decided to roll their own
> for jdk 1.4 rather than turn log4j into a JSR and roll into the 1.4
> umbrella JSR. And the the people in commons, who added to
> the insanity
> with ensuring the lowest common denominator support for
> logging through
> a common interface (although I do appreciate c-l's 'trace()' as it's
> part of my jihad to get log4j to add it...)
However this lowest common demoninator is quite sufficient for middleware,
like Vel, that has simple logging needs and shouldn't impose any logging
restrictions on the projects using it (except of course for the c-l jar
dependency - which is not much of a restriction IMO).
> I'm not against us making it easy that users can use vel w/
> c-l, but I
> don't want it to be the only option. But we've been through this.
Amazingly yes, over and over again ... a brick wall it is, I guess ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Hello All
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
Warning - long one, but if you are interested in the topic, read
through. Nathan spent time on his post, and I did also.
If you don't care, don't bother.
On Feb 8, 2004, at 6:21 PM, Nathan Bubna wrote:
> Geir Magnusson Jr said:
>> On Feb 8, 2004, at 1:49 PM, Marinó A. Jónsson wrote:
>>>>> for the record - c-l in Vel (or any middleware) does NOT force the
>>>>> userbase
>>>>> to use c-l.
>>>>
>>>> That's not true. You must have c-l around in your cp for any
>>>> component
>>>> that uses it.
>>>
>>> true, but I think it's misleading to say that it is "forcing the
>>> userbase to
>>> have to use c-l exclusively" if Vel depends on it - but the user is
>>> free to
>>> use any logging solution he desires.
>>
>> I'm not sure I said 'exclusively'.
>>
>> it forces c-l to be around, and generally speaking adds a runtime
>> configuration requirement to deal with the logging.
>
> i call double-standard. we already require or include
> commons-collections.
It would be a double standard if we were advocating getting another
dependency at the same time which rejecting c-l for getting a
dependency.
This was before your time I think, but commons collections was seeded
by us, with the ExtendedProperties that we contributed (after stealing
from Turbine...), IIRC. Then we decided to support the effort by using
it. We had a big fight once when the c-c committers wanted to change
things out from underneath us. If we were smart we would have let them
and just dropped the dependency. One class, that was in our codebase
in the first place. Others might call it a 'mistake' rather than a
'double-standard'.
Remember, my opposition to just switching lock, stock and barrel to c-l
isn't just about a dependency. It's actually the weakest of my
arguments against it. The biggest reason is that I don't think we
should force users to only use it and give up the injection pattern.
From the beginning of this thread, I've been in full support of a c-l
adapter that people could choose to use.
>
> and since when do people dislike having "standard" (aka common) runtime
> configuration options? especially for logging!
Well, apparently there was a huge dislike. :)
There was log4j for the longest time which seemed to satisfy everyone
for everything. Except people at Sun, who decided to roll their own
for jdk 1.4 rather than turn log4j into a JSR and roll into the 1.4
umbrella JSR. And the the people in commons, who added to the insanity
with ensuring the lowest common denominator support for logging through
a common interface (although I do appreciate c-l's 'trace()' as it's
part of my jihad to get log4j to add it...)
I'm not against us making it easy that users can use vel w/ c-l, but I
don't want it to be the only option. But we've been through this.
>
>>>> The model I like better is an 'early binding' discovery
>>>> (like we have in Vel already) that find the logger to use based on
>>>> what's in the CP. For example, if you don't use the -dep
>>>> version, vel
>>>> will search for logkit or log4j and use them if no other logging is
>>>> specified.
>>>
>>> that's exactly what c-l does :)
>>
>> But you can programmatically not have Vel do it if you give it a
>> logger
>> before init(). How do you keep that level of control w/ c-l? I don't
>> need a detailed example here - just a handwaving description will
>> suffice.
>
> sure, you can make Velocity use c-l in such a way that you just pass
> in/around
> log instances. they're objects after all. it's just a matter of how
> you use
> them. you could replace LogSystem with c-l and have Velocity classes
> log to
> that one c-l instance that they access through the
> Velocity/VelocityEngine
> methods (warn, info, error, etc), and any app developers using
> Velocity could
> do the same. but then i don't really see much point in using c-l
> either.
> it's not just LogSystem i don't like, it's that whole approach to
> logging.
> IMHO, it's a PITA.
Interesting. This is different from my perception of your position.
Can you elaborate?
>
> personally, i prefer the static logger per class approach. you
> clearly don't,
> but in my experience, most people do. you have the commit power, but
> you
> generally appear to be in the minority around here. so i'd say we're
> still
> pretty much at a standstill since no one is changing their minds.
> meanwhile,
> the current LogSystem is still pretty skimpy on features and
> useability. i
> believe everyone agrees could use a lot of improvement regardless of
> how.
The issue of improving the log system is utterly unrelated to c-l, and
something we about which we are in violent agreement. The kneejerk
reaction to "just use c-l cuz it's a 'standard'" is what I'm against.
Every time I implement a framework or -ish, I always use one level of
indirection for my logging, building a simple Logger interface, a
factory, and then an implementation that uses an existing, established
logging framework, or c-l. It takes about 20 minutes, and then I reuse
it if I legally can. This is what c-l does for you, but allows me the
freedom of the pattern (which came from log4j) w/o the binding to the
implementation.
As I said, I generally follow the log4j pattern (which is what c-l
copies) of having the ability to pull a logger out of the aether :
Logger l = MyLogSystem.getLogger( <whatever > );
Sometimes it's static for the class when appropriate, as you seem to
like, although in situations where you have multiple, concurrent
instances of the same class with a reasonable lifetime and output that
needs to be differentiated for whatever reason (think something like a
servlet container - different concurrent app execution - w/o the
classloader boundaries to separate static class instances), I choose
instance loggers rather than static class logger. I also generally
have MyLogSystem implement the Logger interface methods statically, so
I can
MyLogSystem.error("Yikes...")
when I want to in something lightweight like a small tool that would be
used in an environment where failure of something (like sending email)
is of interest to operations. I wouldn't require the user of that tool
to think about logging via the CTOR....
So, I think that you are mistaken in your assessment of how I use
logging, and how I think it should be.
I do the same thing everyone else does, and what sounds like a superset
of what you do. I suspect others also do what I do, keeping a loose
binding of that internal logging system to an external system like
log4j or c-l, but I've never discussed it w/ anyone.
I have no problem doing this in velocity, as it's what we do already re
the pattern of decoupling, and agree we could improve via the static
factory pattern. But I'll still push back against just using c-l as I
still believe there is great power to continue to offer our current
configuration pattern, giving the velocity user programmatic control of
what's going on, explicitly setting the logger to which the internal
logging happens. We can continue to keep the user experience as easy
as possible for the uninterested by adding c-l to our automatic
discovery.
> really, we've been over all these things before.
>
>>>>> c-l "adapts" to the preferred logger so it's pretty transparent to
>>>>> the user :)
>>>>
>>>> Uh huh :) I'd like to keep velocity out of the commons-* fray.
>>>> This
>>>> POV, which I've held for a while, was recently confirmed when I
>>>> upgraded to hibernate 2.1, which has what feels like a gazillion
>>>> dependencies, all w/o any version numbers. To upgrade, I just had
>>>> to
>>>> shut my eyes and cp *.jar foo/lib and hope for the best.
>>>>
>>>> To be fair, it worked out ok, but I think that was more luck than
>>>> design. If we can keep things as simple as possible, w/ minimalist
>>>> dependencies, then I think that over the long run, we'll reduce the
>>>> potential for problems.
>>>
>>> so it all comes down to dependency aversion - IOW using c-l puts
>>> virtually
>>> no restraints on users, but the c-l jar needs to be present in the CL
>>> so
>>> it's a bad thing :)
>>
>> that's not what I'm saying. I do have dependency aversion, but read
>> the bit above.
>
> agreed. you do have a dependency aversion, but you also have
> significantly
> different notions of the best way to do logging. in particular, it
> seems you
> think all components should develop their own simple adapters which
> will all
> need to be individually configured by the application developer,
> instead of
> having a pwerful common adapter that the developer need only configure
> once.
> :)
Read above.
>
>>> Seems like a small price to pay IMO. I can sympathize
>>> with your view on dependencies in general - but I think it needs to
>>> be
>>> addressed on a case-by-case basis ... and in this case I think the
>>> pros
>>> weigh much heavier than the cons.
>>
>> No, because if you want to use c-l, just make the 10 line adapter and
>> use it. If not, use vel as is... you get both, and I don't have to
>> deal with it...
>
> but as VelocityTools developers, we do have to deal with it. right
> now, we
> are using the singleton model. this lets the standard tools perform
> logging
> via the static Velocity.* logging methods. this is not ideal, but is
> tolerable for the moment. however, we need to switch the
> VelocityViewServlet
> (and VelocityTools in general) from using the Velocity class to using
> VelocityEngine. once we do this, the tools no longer have easy access
> to
> Velocity's logsystem. now, we could hack up some way to pass them the
> VelocityEngine the servlet is using, but the thought of it just makes
> me
> cringe.
Me too.
>
> as a user, i would rather need only to configure logging for each app
> i work
> on once and in one place. yes, i can pump Velocity log messages
> through c-l
> and vice-versa, but that's a dumb suggestion that seems to indicate
> misunderstanding of the issues. it would just be pushing log messages
> through
> one more adapter (performance hit) before going to the actual logging
> system i
> am using for my application. that may be the most "reasonable"
> solution for
> anyone developing another *component* that uses Velocity (i fear this
> will be
> the fate of VelocityTools), but application developers have to
> configure the
> logging adapter of each component (e.g. Velocity) separately in order
> to point
> them to their one actual logging solution (Avalon, log4j, jdk1.4,
> etc.). the
> more components that develop their own logging adapters, the more of a
> pain
> this becomes.
Not at all. Given automatic discovery, Velocity would find c-l if
that's what you were using...
>
> also, switching to c-l (with the each-class-has-its-own-static-logger
> paradigm)
or log4j...
> would give me the power to filter/silence/redirect log messages
> according to source as well as severity. this would be nice since it
> often
> happens that i care about INFO (and WARN, DEBUG, etc) messages from
> one class,
> but not another.
>
> Geir, if you can't see where we're coming from on this by now, then i
> don't
> expect you ever will. and if you really do see it and just flat out
> disagree,
> just say so. you have the veto power of a committer and the influence
> of the
> project lead, so i don't want to waste time pushing on a brick wall
> that won't
> budge.
read above. There are two issues here. One is the patterns, and the
other is the implementation. C-l is the implementation. Re the
patterns, I think that you can have what you want :
- the convenience of pulling the logger via the static factory
- making static class loggers via the same where you want to
- the "light and get away" simplicity of it finding and using c-l w/o
you having to think about it
We both get
- improvement in internal logging w/in velocity
I get
- keeping the programmatic control pattern for configuration freedom
The only thing I believe I don't have a satisfactory answer for you is
performance, as it's true we'd have to delegate through methods in the
internal façade. However, I'm not sure that's really a big enough deal
to worry about, as c-l does the same thing anyway, and I've never heard
that as an arg for not using c-l ;)
I bet the original poster had no clue what he was getting into...
:D
geir
>
> 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-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: Hello All
Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr said:
> On Feb 8, 2004, at 1:49 PM, Marinó A. Jónsson wrote:
> >>> for the record - c-l in Vel (or any middleware) does NOT force the
> >>> userbase
> >>> to use c-l.
> >>
> >> That's not true. You must have c-l around in your cp for any
> >> component
> >> that uses it.
> >
> > true, but I think it's misleading to say that it is "forcing the
> > userbase to
> > have to use c-l exclusively" if Vel depends on it - but the user is
> > free to
> > use any logging solution he desires.
>
> I'm not sure I said 'exclusively'.
>
> it forces c-l to be around, and generally speaking adds a runtime
> configuration requirement to deal with the logging.
i call double-standard. we already require or include commons-collections.
and since when do people dislike having "standard" (aka common) runtime
configuration options? especially for logging!
> >> The model I like better is an 'early binding' discovery
> >> (like we have in Vel already) that find the logger to use based on
> >> what's in the CP. For example, if you don't use the -dep
> >> version, vel
> >> will search for logkit or log4j and use them if no other logging is
> >> specified.
> >
> > that's exactly what c-l does :)
>
> But you can programmatically not have Vel do it if you give it a logger
> before init(). How do you keep that level of control w/ c-l? I don't
> need a detailed example here - just a handwaving description will
> suffice.
sure, you can make Velocity use c-l in such a way that you just pass in/around
log instances. they're objects after all. it's just a matter of how you use
them. you could replace LogSystem with c-l and have Velocity classes log to
that one c-l instance that they access through the Velocity/VelocityEngine
methods (warn, info, error, etc), and any app developers using Velocity could
do the same. but then i don't really see much point in using c-l either.
it's not just LogSystem i don't like, it's that whole approach to logging.
IMHO, it's a PITA.
personally, i prefer the static logger per class approach. you clearly don't,
but in my experience, most people do. you have the commit power, but you
generally appear to be in the minority around here. so i'd say we're still
pretty much at a standstill since no one is changing their minds. meanwhile,
the current LogSystem is still pretty skimpy on features and useability. i
believe everyone agrees could use a lot of improvement regardless of how.
really, we've been over all these things before.
> >>> c-l "adapts" to the preferred logger so it's pretty transparent to
> >>> the user :)
> >>
> >> Uh huh :) I'd like to keep velocity out of the commons-* fray. This
> >> POV, which I've held for a while, was recently confirmed when I
> >> upgraded to hibernate 2.1, which has what feels like a gazillion
> >> dependencies, all w/o any version numbers. To upgrade, I just had to
> >> shut my eyes and cp *.jar foo/lib and hope for the best.
> >>
> >> To be fair, it worked out ok, but I think that was more luck than
> >> design. If we can keep things as simple as possible, w/ minimalist
> >> dependencies, then I think that over the long run, we'll reduce the
> >> potential for problems.
> >
> > so it all comes down to dependency aversion - IOW using c-l puts
> > virtually
> > no restraints on users, but the c-l jar needs to be present in the CL
> > so
> > it's a bad thing :)
>
> that's not what I'm saying. I do have dependency aversion, but read
> the bit above.
agreed. you do have a dependency aversion, but you also have significantly
different notions of the best way to do logging. in particular, it seems you
think all components should develop their own simple adapters which will all
need to be individually configured by the application developer, instead of
having a pwerful common adapter that the developer need only configure once.
:)
> > Seems like a small price to pay IMO. I can sympathize
> > with your view on dependencies in general - but I think it needs to be
> > addressed on a case-by-case basis ... and in this case I think the pros
> > weigh much heavier than the cons.
>
> No, because if you want to use c-l, just make the 10 line adapter and
> use it. If not, use vel as is... you get both, and I don't have to
> deal with it...
but as VelocityTools developers, we do have to deal with it. right now, we
are using the singleton model. this lets the standard tools perform logging
via the static Velocity.* logging methods. this is not ideal, but is
tolerable for the moment. however, we need to switch the VelocityViewServlet
(and VelocityTools in general) from using the Velocity class to using
VelocityEngine. once we do this, the tools no longer have easy access to
Velocity's logsystem. now, we could hack up some way to pass them the
VelocityEngine the servlet is using, but the thought of it just makes me
cringe.
as a user, i would rather need only to configure logging for each app i work
on once and in one place. yes, i can pump Velocity log messages through c-l
and vice-versa, but that's a dumb suggestion that seems to indicate
misunderstanding of the issues. it would just be pushing log messages through
one more adapter (performance hit) before going to the actual logging system i
am using for my application. that may be the most "reasonable" solution for
anyone developing another *component* that uses Velocity (i fear this will be
the fate of VelocityTools), but application developers have to configure the
logging adapter of each component (e.g. Velocity) separately in order to point
them to their one actual logging solution (Avalon, log4j, jdk1.4, etc.). the
more components that develop their own logging adapters, the more of a pain
this becomes.
also, switching to c-l (with the each-class-has-its-own-static-logger
paradigm) would give me the power to filter/silence/redirect log messages
according to source as well as severity. this would be nice since it often
happens that i care about INFO (and WARN, DEBUG, etc) messages from one class,
but not another.
Geir, if you can't see where we're coming from on this by now, then i don't
expect you ever will. and if you really do see it and just flat out disagree,
just say so. you have the veto power of a committer and the influence of the
project lead, so i don't want to waste time pushing on a brick wall that won't
budge.
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: Hello All
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Feb 8, 2004, at 1:49 PM, Marinó A. Jónsson wrote:
>>> for the record - c-l in Vel (or any middleware) does NOT force the
>>> userbase
>>> to use c-l.
>>
>> That's not true. You must have c-l around in your cp for any
>> component
>> that uses it.
>
> true, but I think it's misleading to say that it is "forcing the
> userbase to
> have to use c-l exclusively" if Vel depends on it - but the user is
> free to
> use any logging solution he desires.
I'm not sure I said 'exclusively'.
it forces c-l to be around, and generally speaking adds a runtime
configuration requirement to deal with the logging.
>
>> The model I like better is an 'early binding' discovery
>> (like we have in Vel already) that find the logger to use based on
>> what's in the CP. For example, if you don't use the -dep
>> version, vel
>> will search for logkit or log4j and use them if no other logging is
>> specified.
>
> that's exactly what c-l does :)
But you can programmatically not have Vel do it if you give it a logger
before init(). How do you keep that level of control w/ c-l? I don't
need a detailed example here - just a handwaving description will
suffice.
>
>>> c-l "adapts" to the preferred logger so it's pretty transparent to
>>> the user :)
>>
>> Uh huh :) I'd like to keep velocity out of the commons-* fray. This
>> POV, which I've held for a while, was recently confirmed when I
>> upgraded to hibernate 2.1, which has what feels like a gazillion
>> dependencies, all w/o any version numbers. To upgrade, I just had to
>> shut my eyes and cp *.jar foo/lib and hope for the best.
>>
>> To be fair, it worked out ok, but I think that was more luck than
>> design. If we can keep things as simple as possible, w/ minimalist
>> dependencies, then I think that over the long run, we'll reduce the
>> potential for problems.
>
> so it all comes down to dependency aversion - IOW using c-l puts
> virtually
> no restraints on users, but the c-l jar needs to be present in the CL
> so
> it's a bad thing :)
that's not what I'm saying. I do have dependency aversion, but read
the bit above.
> Seems like a small price to pay IMO. I can sympathize
> with your view on dependencies in general - but I think it needs to be
> addressed on a case-by-case basis ... and in this case I think the pros
> weigh much heavier than the cons.
No, because if you want to use c-l, just make the 10 line adapter and
use it. If not, use vel as is... you get both, and I don't have to
deal with it...
geir
>
> cheers,
> Marinó
>
>>
>> geir
>>
>>>
>>>
>>> cheers,
>>> Marinó
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>>> 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-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
>>
>
>
>
> ---------------------------------------------------------------------
> 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-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: Hello All
Posted by "Marinó A. Jónsson" <ma...@centrum.is>.
> > for the record - c-l in Vel (or any middleware) does NOT force the
> > userbase
> > to use c-l.
>
> That's not true. You must have c-l around in your cp for any component
> that uses it.
true, but I think it's misleading to say that it is "forcing the userbase to
have to use c-l exclusively" if Vel depends on it - but the user is free to
use any logging solution he desires.
> The model I like better is an 'early binding' discovery
> (like we have in Vel already) that find the logger to use based on
> what's in the CP. For example, if you don't use the -dep
> version, vel
> will search for logkit or log4j and use them if no other logging is
> specified.
that's exactly what c-l does :)
> > c-l "adapts" to the preferred logger so it's pretty transparent to
> > the user :)
>
> Uh huh :) I'd like to keep velocity out of the commons-* fray. This
> POV, which I've held for a while, was recently confirmed when I
> upgraded to hibernate 2.1, which has what feels like a gazillion
> dependencies, all w/o any version numbers. To upgrade, I just had to
> shut my eyes and cp *.jar foo/lib and hope for the best.
>
> To be fair, it worked out ok, but I think that was more luck than
> design. If we can keep things as simple as possible, w/ minimalist
> dependencies, then I think that over the long run, we'll reduce the
> potential for problems.
so it all comes down to dependency aversion - IOW using c-l puts virtually
no restraints on users, but the c-l jar needs to be present in the CL so
it's a bad thing :) Seems like a small price to pay IMO. I can sympathize
with your view on dependencies in general - but I think it needs to be
addressed on a case-by-case basis ... and in this case I think the pros
weigh much heavier than the cons.
cheers,
Marinó
>
> geir
>
> >
> >
> > cheers,
> > Marinó
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > 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-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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Hello All
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Feb 8, 2004, at 1:42 PM, Rob Harrop wrote:
> On 8/2/04 6:17 pm, "Geir Magnusson Jr" <ge...@4quarters.com> wrote:
>> Uh huh :) I'd like to keep velocity out of the commons-* fray. This
>> POV, which I've held for a while, was recently confirmed when I
>> upgraded to hibernate 2.1, which has what feels like a gazillion
>> dependencies, all w/o any version numbers. To upgrade, I just had to
>> shut my eyes and cp *.jar foo/lib and hope for the best.
>>
>> To be fair, it worked out ok, but I think that was more luck than
>> design. If we can keep things as simple as possible, w/ minimalist
>> dependencies, then I think that over the long run, we'll reduce the
>> potential for problems.
>>
> <robh>
> That is a very good point, my current project has about 60 jar
> files, 55
> of which are dependencies. On the commons front I have only experienced
> problems with commons collections, everything else seems to have gone
> pretty
> well.
Yes. But as things mature, and the number of available 3rd party
components that one uses to build solutions increases (like hibernate,
velocity, whatever...) the threat of collision increases, especially as
components make the major version # jump (1.x -> 2.x, for example) with
the high probability of major changes in interfaces or functionality.
>
> On a separate topic I noticed talk of a template compiler, has anyone
> started on that yet and what are the plans?
It's been discussed for years now. My belief is that it won't buy
much, as after the first time a template is parsed, it's kept in memory
as an object graph, and calls from part to part are just method calls.
It's all compiled bytecode at that point.
geir
> </robh>
>> geir
>>
>>>
>>>
>>> cheers,
>>> Marinó
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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-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: Hello All
Posted by Rob Harrop <ro...@robharrop.com>.
On 8/2/04 6:17 pm, "Geir Magnusson Jr" <ge...@4quarters.com> wrote:
>
> On Feb 8, 2004, at 11:36 AM, Marinó A. Jónsson wrote:
>
>> Geir said:
>>> I think we should have a c-l logger in Vel, but go read the
>>> archives as
>>> to why I don't think it should be the only choice. I believe there's
>>> one in Tools, I threw one together (it's really simple, actually...)
>>
>> yup - it's pretty simple to throw together an adapter for the adapter
>> :)
>
> Why stop there? How about and adapter adapter for the adapter?
>
> (Reminds me of the question - how do you test mock objects? mock mock
> objects?)
>
>>
>>> We'll also go revise some of our logging strategies
>>> internally, but I'm
>>> really really against forcing the userbase to have to use c-l
>>> exclusively.
>>
>> for the record - c-l in Vel (or any middleware) does NOT force the
>> userbase
>> to use c-l.
>
> That's not true. You must have c-l around in your cp for any component
> that uses it. The model I like better is an 'early binding' discovery
> (like we have in Vel already) that find the logger to use based on
> what's in the CP. For example, if you don't use the -dep version, vel
> will search for logkit or log4j and use them if no other logging is
> specified.
>
>> c-l "adapts" to the preferred logger so it's pretty transparent
>> to the user :)
>
> Uh huh :) I'd like to keep velocity out of the commons-* fray. This
> POV, which I've held for a while, was recently confirmed when I
> upgraded to hibernate 2.1, which has what feels like a gazillion
> dependencies, all w/o any version numbers. To upgrade, I just had to
> shut my eyes and cp *.jar foo/lib and hope for the best.
>
> To be fair, it worked out ok, but I think that was more luck than
> design. If we can keep things as simple as possible, w/ minimalist
> dependencies, then I think that over the long run, we'll reduce the
> potential for problems.
>
<robh>
That is a very good point, my current project has about 60 jar files, 55
of which are dependencies. On the commons front I have only experienced
problems with commons collections, everything else seems to have gone pretty
well.
On a separate topic I noticed talk of a template compiler, has anyone
started on that yet and what are the plans?
</robh>
> geir
>
>>
>>
>> cheers,
>> Marinó
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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: Hello All
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Feb 8, 2004, at 11:36 AM, Marinó A. Jónsson wrote:
> Geir said:
>> I think we should have a c-l logger in Vel, but go read the
>> archives as
>> to why I don't think it should be the only choice. I believe there's
>> one in Tools, I threw one together (it's really simple, actually...)
>
> yup - it's pretty simple to throw together an adapter for the adapter
> :)
Why stop there? How about and adapter adapter for the adapter?
(Reminds me of the question - how do you test mock objects? mock mock
objects?)
>
>> We'll also go revise some of our logging strategies
>> internally, but I'm
>> really really against forcing the userbase to have to use c-l
>> exclusively.
>
> for the record - c-l in Vel (or any middleware) does NOT force the
> userbase
> to use c-l.
That's not true. You must have c-l around in your cp for any component
that uses it. The model I like better is an 'early binding' discovery
(like we have in Vel already) that find the logger to use based on
what's in the CP. For example, if you don't use the -dep version, vel
will search for logkit or log4j and use them if no other logging is
specified.
> c-l "adapts" to the preferred logger so it's pretty transparent
> to the user :)
Uh huh :) I'd like to keep velocity out of the commons-* fray. This
POV, which I've held for a while, was recently confirmed when I
upgraded to hibernate 2.1, which has what feels like a gazillion
dependencies, all w/o any version numbers. To upgrade, I just had to
shut my eyes and cp *.jar foo/lib and hope for the best.
To be fair, it worked out ok, but I think that was more luck than
design. If we can keep things as simple as possible, w/ minimalist
dependencies, then I think that over the long run, we'll reduce the
potential for problems.
geir
>
>
> cheers,
> Marinó
>
>
>
> ---------------------------------------------------------------------
> 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-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: Hello All
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Feb 8, 2004, at 1:36 PM, Rob Harrop wrote:
> It seems I have sparked an existing debate :).
You've joined an existing debate :)
>
> I think it is also preference - I like CL but I'm sure there are those
> who
> have preferred techs, it just seems strange that Velocity has an
> adapter for
> logging techs when that is exactly what CL is.
It isn't strange when you consider we had it years before someone came
up w/ it in commons. The difference though is the model - we ask the
developer to assert the implementation rather than the component
asserting itself...
geir
>
> Rob
>
> On 8/2/04 4:36 pm, "Marinó A. Jónsson" <ma...@centrum.is> wrote:
>
>> Geir said:
>>> I think we should have a c-l logger in Vel, but go read the
>>> archives as
>>> to why I don't think it should be the only choice. I believe there's
>>> one in Tools, I threw one together (it's really simple, actually...)
>>
>> yup - it's pretty simple to throw together an adapter for the adapter
>> :)
>>
>>> We'll also go revise some of our logging strategies
>>> internally, but I'm
>>> really really against forcing the userbase to have to use c-l
>>> exclusively.
>>
>> for the record - c-l in Vel (or any middleware) does NOT force the
>> userbase
>> to use c-l. c-l "adapts" to the preferred logger so it's pretty
>> transparent
>> to the user :)
>>
>>
>> cheers,
>> Marinó
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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-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: Hello All
Posted by Rob Harrop <ro...@robharrop.com>.
It seems I have sparked an existing debate :).
I think it is also preference - I like CL but I'm sure there are those who
have preferred techs, it just seems strange that Velocity has an adapter for
logging techs when that is exactly what CL is.
Rob
On 8/2/04 4:36 pm, "Marinó A. Jónsson" <ma...@centrum.is> wrote:
> Geir said:
>> I think we should have a c-l logger in Vel, but go read the
>> archives as
>> to why I don't think it should be the only choice. I believe there's
>> one in Tools, I threw one together (it's really simple, actually...)
>
> yup - it's pretty simple to throw together an adapter for the adapter :)
>
>> We'll also go revise some of our logging strategies
>> internally, but I'm
>> really really against forcing the userbase to have to use c-l
>> exclusively.
>
> for the record - c-l in Vel (or any middleware) does NOT force the userbase
> to use c-l. c-l "adapts" to the preferred logger so it's pretty transparent
> to the user :)
>
>
> cheers,
> Marinó
>
>
>
> ---------------------------------------------------------------------
> 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: Hello All
Posted by "Marinó A. Jónsson" <ma...@centrum.is>.
Geir said:
> I think we should have a c-l logger in Vel, but go read the
> archives as
> to why I don't think it should be the only choice. I believe there's
> one in Tools, I threw one together (it's really simple, actually...)
yup - it's pretty simple to throw together an adapter for the adapter :)
> We'll also go revise some of our logging strategies
> internally, but I'm
> really really against forcing the userbase to have to use c-l
> exclusively.
for the record - c-l in Vel (or any middleware) does NOT force the userbase
to use c-l. c-l "adapts" to the preferred logger so it's pretty transparent
to the user :)
cheers,
Marinó
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Hello All
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Feb 7, 2004, at 11:02 AM, Rob Harrop wrote:
> Hi,
>
> First off I would like to give a big thanks for bring us such a great
> project! My name is Rob Harrop and I am currently working on a
> Velocity book
> and I plan to get a bit more involved on the development front during
> and
> especially after writing the book.
>
> Initially I want to know what the plans are regarding Commons Logging.
> As
> part of the book I plan to implement a custom logger for Commons
> Logging,
> which I will be happy to give to the project. Longer term I would be
> happy
> to get involved and move the project over to Commons Logging if this
> is part
> of the overall strategy.
LOL
I think we should have a c-l logger in Vel, but go read the archives as
to why I don't think it should be the only choice. I believe there's
one in Tools, I threw one together (it's really simple, actually...)
We'll also go revise some of our logging strategies internally, but I'm
really really against forcing the userbase to have to use c-l
exclusively.
geir
>
> Regards,
>
> Rob Harrop
>
>
> ---------------------------------------------------------------------
> 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-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: Hello All
Posted by Dave Newton <da...@solaraccess.com>.
On Sat, 2004-02-07 at 11:39, Nathan Bubna wrote:
> search the mailing list archives for "logging" if you want to brush up on the
> debate.
With the caveat that the brushing will take about a week to read all the
messages ;)
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Hello All
Posted by Nathan Bubna <na...@esha.com>.
Rob Harrop said:
> First off I would like to give a big thanks for bring us such a great
> project! My name is Rob Harrop and I am currently working on
> a Velocity book and I plan to get a bit more involved on the
> development front during and especially after writing the book.
cool!
> Initially I want to know what the plans are regarding Commons Logging. As
> part of the book I plan to implement a custom logger for Commons Logging,
> which I will be happy to give to the project.
anything like these?
http://jakarta.apache.org/velocity/tools/javadoc/org/apache/velocity/tools/generic/log/package-summary.html
> Longer term I would be happy
> to get involved and move the project over to Commons Logging if this is part
> of the overall strategy.
personally, i would love to see this happen, but just to warn you, there
remain some very significant members of this community who aren't interested.
search the mailing list archives for "logging" if you want to brush up on the
debate.
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: Hello All
Posted by Dave Newton <da...@solaraccess.com>.
On Sat, 2004-02-07 at 11:02, Rob Harrop wrote:
> First off I would like to give a big thanks for bring us such a great
> project! My name is Rob Harrop and I am currently working on a Velocity book
> and I plan to get a bit more involved on the development front during and
> especially after writing the book.
Great, the project could use monetary infusion from the book profits!
> part of the book I plan to implement a custom logger for Commons Logging,
> which I will be happy to give to the project.
How is the implementation of a logger related to Velocity?
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org