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:[EMAIL PROTECTED] > 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 > > [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > -- > Geir Magnusson Jr 203-247-1713(m) > [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
