On 4/5/02 1:25 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote: > >>>> In o.a.c.l with some implicit assumptions (which I am trying to dodge...) >>> >>> It's quite explicit, and your proposal seem to hava a LogFactory too. >> >> The assumptions are *not* explicit - the assumption I am talking about is >> that you must get the log via a pull from a singleton in o.a.c.l. Again, >> nothing wrong with that, but wanted to be clear. > > There is no "must". The static method and the discovery is a helper, > nothing require you to use it. > But from what I've heard, everyone *expects* it to be there, as it's in the o.a.c.l jar. You've seem to have coupled a generic logging interface o.a.c.l.Log to the expectation of a pull-able implementation, and all I am suggesting is that maybe the interface can be separate from the pull impl. > The name-based registration of components is pretty widespread in java - > and most people know how to use it and how to not use it if they want to. > Almost all APIs in use today are using it - JDBC, JNDI, JAXP - even > servlets ( you get a servlet by name, and web.xml is full of crap to > simplify the configuration of name-based resources). I'm not complaining about it! > However nothing in the API prevent you to instantiate a DOM parser > yourself and add setDOMParser in your code. > > >>> BTW, are you going to also propose a o.a.c.genericxmlparser, >>> o.a.c.genericjdbc, etc ? After all, there are few dozen APIs using the >>> same pattern with common-logging, do you feel confused when using them >>> too ? >> >> Nope. JDBC doesn't come with an impl, does it? Don't I go and use the >> mm.sql MySQL driver package throuh which getConnection() will return an >> object that implements Connection? That's what I am trying to get to here - >> an implementation free interface spec. > > Ok, the 'implementation' you talk about is the println() fallback if > log4j, logkit, jdk1.4 or any other impl is detected. > > JAXP does come with a default implementation as well, same for JMX and > JNDI. ( JDBC was not the best example, my mistake :-). But one I was able to deftly capitalize on! :) And the JNDI impl as great as long as you don't want to do anything with it. Sorry :) Serious question : how do I implement a new LogFactory? Do I have to rely on classpath order? (no thanks...) > > BTW, JDBC does include the registration code ( also pull based - you > don't have to call mm.sql.Driver directly except to make it register > itslef in DriverManager ). And it also include a second pull and name > based mechansim - JNDI. :) > > >> Then the basic implementation is commons-logging for the pull crowd, (and >> maybe push) and anyone who has another idea can do what they want. > > You can do what you want anyway - there are already a dozen interfaces for > Log besides o.a.c.logging.Log. > > The current Log interface is good enough and used in several packages, and > I don't plan to use any other log interface in any code I write. I thought you got it. There is no need to be defensive here - I am not trying to disrupt o.a.c.l, force any behavior on anyone, force implementation on anyone, etc... I am not trying to do another Log interface because there is a problem with o.a.c.l. There isn't any problem with the *interface* o.a.c.l.Log. It's beautiful! Perfect! I salute the vision! and the code formatting is just immaculate. And the comments... Mere words don't do them justice... :) OK? The problem I have is that there is implementation support built into the package, and that leads to the expectation that if I am in o.a.c.l there is a working LogFactory I can reach via a singleton. Or put another way, commons logging has pull discovery implicit in the model. That's all. It's the *expectation* - I understand now that it's explicit because if you want to use the generic Log interface, that log factory impl is *always* going to be around somewhere, so just try... I was proposing the same interfaces with no promises about the existence of factories. If you want to pull - be my guest and use o.a.c.l. And if public interface Log implements o.a.c.gl.Log then they are 100% compatible with each other. (not bidirectionally, but that could be fixed :) > > >> You guys say you don't want this interface in the Logging package, and then >> make fun of me when I propose a generic interface package that fully >> supports the existing and includes it? > > You can create 10 interfaces if you want - what matter is what we use > in our code, and for now it seems most of us are using commons-logging > as the interface for logging. Right - because you wanted a COMMON interface for logging. I am not asking anyone to use anything different. Why you seem to be saying that the generic logging interface can't be separate from the pull-compatible implementation is beyond me... Utterly. See what I'm saying? > >> However, I would think you would want to separate the interfaces, to prevent >> a *component* from calling setFactory() > > No need for that - there are already pretty good mechansims to prevent > and define who is allowed to set factory. Either Permission or > a 'set once' policy or a guard will do it. > ( the permission is actually a guard, I put it separately since it's the > standard way to do this kind of stuff ). > > As usually, if sandbox is not used no interface will prevent anything. > >> What I am thinking about here is that you could write a component that does >> both the static factory pull (catching any exceptions) well as support >> container push at the same time. Maybe I'm wrong... > > Pull is already done. I know that. Just curious - what made you feel the necessity to point that out? > If you want to implement push - you can use a > different package if you can't convince people to put it in > common-logging. Sigh. If I want to implement push - I do it privately in my app. There is no 'push implementation' I am proposing - just the marker interface that lets me know I *can* push. And I like the idea of package separation from o.a.c.l because of the implicit assumption of LogFactory. >>> Can you give any arguments for that ( besides 'it seems' ) ? >> >> Because if I use o.a.c.l, it's assumed that there exists a singleton >> somewhere such that >> >> LogFactory.getFactory() > > What do you mean 'it's assumed' ??? There is a helper method in > LogFactory, and the semantic is pretty well defined. There is no MUST USE > in it. But it must always BE THERE if you are using o.a.c.l. Therefore, of using o.a.c.l, people *assume*. So why not make the simple Log interface outside of o.a.c.l so you can use that w/o dragging in the impl assumptions? Lets step back : 1) This is not a push vs pull value debate. I don't care. I have used both and like both. 2) This is not a criticism of o.a.c.l per se. I like the interfaces and am excited about a single interface for *making calls* to a logger. 3) I think that the idea of a generic logging interface is great, and doesn't have to be tied to an discovery model, no matter how valid that model is. > > >> Will work. That SEEMS like a huge assumption and requires an implementation >> to be part of o.a.c.l > > If a Log implementation wants to be 'discovered' by the helper, it must > follow the rules ( set in JDK1.3 spec BTW - the META-INF/services is > there ). > > The implementation of the discovery is part of o.a.c.l because many > people prefer to use the discovery instead of hardcoding calls to > a logger impl ( or to a DOM parser, etc ). That�s great! That's wonderful! You make many people happy and provide good software. But discovery of an interface can be separate from the definition of the interface, or so I believe. > > >> I want to just define the interfaces separately in o.a.c.gl that o.a.c.l >> builds upon with the current implementation strategy. People could still >> use o.a.c.l as is w/o even knowing about o.a.c.gl, o.a.c.gl could be used >> w/o knowing about o.a.c.l, and things that support o.a.c.gl could also be >> used in a o.a.c.l environment, as the Logs and Factorys are compatible. > > I doubt o.a.c.gl will be used - I'm -1 on adding another layer, its > confusing and doesn't actually gives any benefit. The user will still use > a Log interface with the methods we have - so why add another package ? > Who wants discovery will still use LogFactory directly - again no > need for another package. > > If you create a package with the push interfaces ( or some other > management stuff ) - that would be usefull. But I would never want to set push interfaces in stone - because the possibilities are so rich... > > > >> No - the problem as I see it, and I maybe hugely mistaken, is in the >> expectation - that if I am in an o.a.c.l environment, I can assume that I >> can do a pull to get the Log or factory. This makes me worry that if I >> have a system that claims that logging is done via o.a.c.l, then I have to >> provide the ability to pull. > > You don't have to provide it - the discovery is already implemented ( and > a user could use getResource( "META-INF/services/..." ) and > Class.forName() himself. How do I replace the implementation of LogFactory? I want to override the static accessor, for example. I'm not familiar with services discovery.... I'll go read though... > > If you don't support named-based loggers - fine, you just don't include > any LogFactory impl. The user will still be able to use the fallback impl, > which is System.println() ( nothing special here - he would be able to > do that anyway ). > >> Like I have been trying to say - there are no implementation requirements on >> the part of the component. > > Well, your original proposal ( to have a LogUser interface ) would put > implementation requirement on a component that wants to use it, wouldn't > it ? What? Of course - if you want to implement the marker interface, you have to implement the marker interface. We've reached tautology land... But not if you don�t want to use it (more tautology...) - which is where I think Morgan was coming from - he didn't want to go back an change existing stuff... > > >> If you want to pull all the time, use o.a.c.l. Don't even worry about >> o.a.c.gl > > That's exactly what we are all saying - put LogUser in a separate package. Ok - so that's halfway there. But I am not sure what that buys us - why putting it in a different package does anything. > Again, you have at least my +1 on putting LogUser in o.a.c.l, it seems > you have Craig's +0, and so far a single -1 which may be switched with > a bit of effort. Hm. I have some reservations now - :) I didn't realize the pull model was so critical to commons logging... -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting The obvious solutions are challenging -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
