On 4/3/02 5:47 PM, "Richard Sitze" <[EMAIL PROTECTED]> wrote:
> On 4/3/02 4:49 PM, "Geir Magnusson Jr. " <[EMAIL PROTECTED]> wrote: > >>>> And in that framework, can they have their components use the generic >>>> commons interface for logging? >>> >>> No. The biggest difference (and it's important to the Avalon community) > is >>> that logged messages are "Object" in commons, and "String" in LogKit. > That >>> kind of trashes the idea of sharing a common interface. However, the > CODE >>> you write can be "independent" of this. >> >> Sorry - why do I care if a hypothetical commons generic interface doesn't >> jive with the Avalon philosophy? > > OK, so I have other goals... see more ranting below. This is curious... > >> >> I mean, this conversation gives me an idea - a LoggingLogging project in >> commons that has >> >> 1) the same Log interface as o.a.c.l >> >> 2) the LogUser interface (with michaels change to setFactory()) >> >> 3) an empty Factory impl >> >> And then optional Factory Impls that use the o.a.c.l package to provide > real >> impl using log4j or logkit. > > Other than the "empty Factory Impl", you just described commons logging + > your proposed change. Bingo. The fact that your force a working factory into the mix in the current commons logging is a problem, as I see it - you "draw a line" with the components - "implement this, or else..." > >> >> No philosophy. >> >> No implied framework. > > How does a default factory implementation become an entire framework? It's a framework - you have to support the contract of providing a Log singleton if you are going to use components that use Commons Logging. That's fine if the Commons Logging project is up front about what they are doing - I am blaming myself for not figuring this out.... Not a complicated framework, but a framework none-the-less. > The > "heart" is the Log interface, and that interface isn't tied to the use of > the factory. Hang on here - if that was true, the whole pull vs push issue would be moot. It appears to be assumed that you have have to implement the Log singleton in order to support the general Log interface. I.e. Right now, if something says that it supports the Log interface, either it's assumed that the Log singleton is used to access a Log impl, or the whole things is somewhat useless as there is no statement about how one is supposed to supply a Log interface to a component to use. See my problem? > >> >> Push, pull, slide, jigger, throw, catch, .... > > With your change, you can "push", or import the factory and "pull". For > the rest you'll have to submit a more detailed design proposal :-) > :) >> >> Just a common interface that people can use for logging... >> > > OK. So, if you have decided that the Avalon equivalent to commons logging > is not appropriate, and you believe that what you want is commons logging + > new interface, then I have no objection. I am not saying that it's not appropriate - I thought that you were implying that I should use Avalon, the framework. But there are lots of existing code that might be at a point where they want to switch to a generic logging wrapper to put around what they have, so insulate the codebase from the future... > > +1, for what it's worth from me :-) > > <rant> > Hey Avalon - do you hear that??? I STILL WANT YOU TO EXTEND THE commons > logging Log interface IN YOUR Logger face, I mean interface! ;-) (sorry, > just couldn't resist - it's been a long day). If Avalon had a generic, implementation-contract-free interface... The problem there is that if people are going to create components in commons that would be useful for the system that I am doing this for (Velocity tools...), then I would want that users could use them too... > Having "Object message" instead of "String message" parameters may not be > ideal from your position, but the BENEFITS FAR OUTWEIGH the concerns. I've already whined about having Object params (I have all sorts of problems with it...) but I'm over that. We'll get burned at some point, blame will be assigned to innocent parties, and life will go on... :) > In addition, if you could somehow keep Geir in sync with your push > interface, it would be even cooler. Well, I will certainly go look. Right now, even with your +1, it's pretty clear that there is too much opposition to move forward... Thanks geir > </rant> > > <ras> > > ******************************************* > Richard A. Sitze [EMAIL PROTECTED] > CORBA Interoperability & WebServices > IBM WebSphere Development > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting "Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech." - Benjamin Franklin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
