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]>
