On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote: > > 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.
Not sure I understand... The helper method _is_ in o.a.c.l and is used by many people - as long as we preserve backward compat I would expect to be there. And if we add your push interface, I will *expect* it to be there. > 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. Yes, Log can be used using the helper method - it's there for convenience and is quite important in making the stuff easy to use. If you create a logger without a simple to use helper and without a pull mechansim - it'll not be useable by all the people who want this. You can still choose to ignore it - or to use a different mechanism. Including JNDI - Craig may explain us if web.xml would allow us to define 'custom' resources ( besides JDBC drivers, etc ). If it does, then we automatically have another valid mechansim to get a Log in a servlet environment - pushed by the 'deployer' via JNDI and web.xml. Class.forName() also works. There are many ways to get a Log instance, and I don't see the problem with providing a simple helper, based on a clear standard ( JDK1.3 service discovery, and JAXP ), for people who want a 1-liner based on a clear standard. > Serious question : how do I implement a new LogFactory? > > Do I have to rely on classpath order? (no thanks...) No, use service discovery ( if you want your LogFactory to work with the static method - again, you don't have to if all the users of your logger are using push). http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Service%20Provider > 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. Yes. There is no expectation that you a _required_ to use it - it's just one helper you can use or ignore. > Or put another way, commons logging has pull discovery implicit in the > model. No, commons-logging supports JDK1.3 discovery explicitely ( but not exclusively ). As I said, I suppose getting a logger from JNDI will work as well, and 'push' does work fine even today ( except it's only 'implicit', there is no explicit contract or method name ), same for Class.forName or custom user code. > 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 I prefer a package that support multiple models rather then one that supports none. > 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? I have no idea :-) > 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? Yes. And Class.forName() will allways work, JNDI will allways work, and setLog() will allways work. You can assume that as well. > 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. That's where we disagree. In order to use Log you need to get it somehow. And commons tries to support the mechansims that are needed by different projects. The good direction is to add more to solve other's itches. > But discovery of an interface can be separate from the definition of the > interface, or so I believe. Sure - but why would we do that ? Name one interface that doesn't provide a mechanism to get it ( except DOM - but DOM3 will fix that ). > > 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. You can't. The static accessor implements the services/ - if it have a bug, we can fix it. If you want a different mechansim - you can add it. But the static accessor must work the way it is supposed to, it's not replaceable. > > 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... If you want to use Log - what do you do ? You are required to implement the marker interface to use Log, or you are required to use discovery. ( or do a class.forName ). > 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... Same for LogFactory.getLog(). > Hm. I have some reservations now - :) I didn't realize the pull model was > so critical to commons logging... Of course it is critical - that's how most people are using it. You change it - and all our projects will stop working. What's the problem ? If you add LogUser and people will use it, then it'll become as critical as LogFactory. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
