On 4/5/02 3:28 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> 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 it will. > > And if we add your push interface, I will *expect* it to be there. And it might. But the 'push interface' has no implementation associated with it... I would expect, for example that I would write an app that uses the pull interface to get a factory, and then give that factory to my components...) >> 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. It's just an interface. You don't *use* the interface, you use the service/package/class/whatever that *implements* the interface... So again, I'm not advocating creating a new or different logger - just separating the generic interface apart from the *truly excellent* implementation of that interface in o.a.c.l. > 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. Pushed in how? >From the sound of it now, any commons-logging-using component expects to be able to do the logger = LogFactory.getLog(me) thing... > 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. Costin, I don't see a problem with it either. It's beautiful. There are lots of things I don't have a problem with - I just don't think they all belong in the same place... > >> 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 Thanks. <...reading....> So you can have multiple LogFactory implementations available at the same time? I still don't get it - I looked at digester - it does the ususal Log logger = LogFactory.... Initializer. Now, if there were several impls of LogFactory in the classpath, which one wins? Digester isn't using Service.providers() approach... > > >> 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. Right > >> 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. Right - all these are legit. Let me try another way : Suppose you let me put LogUser into o.a.c.l. To use this, o.a.c.l jar must be in the classpath. How do I prevent someone from using the discovery mechanism to get the default impl? Would this be solved if there was : o.a.c.gl.jar - with the interfaces, no impl o.a.c.l.jar - with the *truly excellent* impl with nice discovery support So then I could put o.a.c.gl.jar in the classpath, and discovery then won't work... (I know what you say about security - that isn't the issue here...) > >> 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. I aaree, but see the question above. > > >> 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. > No, JNDI won't always work : if no one pushes a Log into the JNDI context, there won't be one to find, unless there is some other default implementation in the o.a.c.l package I haven't seen... > >> 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. Yep! > > >> 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 ? So people don't assume a specific implementation? > Name one interface that doesn't > provide a mechanism to get it ( except DOM - but DOM3 will fix that ). 1) Anything in the JMS spec, I believe. 2) JDBC : There are no default mechanisms in JDBC to get an impl of almost everything... I guess 'DriverManager' is there, but that's not an interface... 3) Any java2 collections -> java.util.List, unless you count new ArrayList(), which is different, totally different, than ListFactory.getList() > >>> 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. I see. That isn't a problem in something that is supposed to be a generic logging interface? No completing implementations can exist then? See why I think there is some value in interface separate from impl? Why can't I drop another jar and do the same META-INF/services thing? >>> 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 ). Or have a completely different private mechanism where I have some init method, in which one arg is o.a.c.gl.Log. In which case that�s a push with a totally different semantic - the LogUser marker interface isn't implemented - but as it's a class in a private package or something, it doesn't matter... Choices, choices, choices... > >> 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(). Same what? >> 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. <sigh> I never advocated changing the pull model. I resent the implication. > > 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]> > -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Age and treachery will always triumph over youth and talent -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
