On 4/3/02 6:08 PM, "Morgan Delagrange" <[EMAIL PROTECTED]> wrote:
> > ----- Original Message ----- > From: "Geir Magnusson Jr." <[EMAIL PROTECTED]> > To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> > Sent: Wednesday, April 03, 2002 4:43 PM > Subject: Re: [logging] Need interface... > > >> On 4/3/02 5:12 PM, "Morgan Delagrange" <[EMAIL PROTECTED]> wrote: >> >> [snip] >> >>> >>> I _am_ saying that this interface doesn't make me happy, because as soon > as >>> we introduce it people will assert something like, "Commons Component X > does >>> not correctly implement the commons-logging component because Class Y > does >>> not implement the external configuration interface." I do not want to >>> implement that interface in other Commons components; I don't think it's >>> worth it. Therefore I don't support its introduction to the Commons > logger >>> component. >> >> Therefore - the only valid implementation of the interface that you see is >> the static, singleton-accessed 'pull' approach? >> >> Can that be noted somewhere? > > Not at all. If you want your application to implement push Logs, then do > so. I wouldn't mind the interface if it didn't introduce the expectation > that a client of commons-logging will implement it. Wouldn't it be nice then if I said "this component will use a commons logger" that you can mechanically figure out how? We don't have to then have another conversation describing how it gets the logger? That's what happens now, right? There is what appears to be an unspoken assumption that if I do something like protected static Log logger = Log.getLogger(...); >From within my component, it will magically work and not randomly chuck a ClassNotFoundException depending on the app using the component? > >>> >>>>> since we don't expect such behaviour in Commons components, it seems >>>>> counter-productive to support it in the logger, which would introduce >>> the >>>>> possibility of such an interface being used inconsistently. >>>> >>>> Not sure why you wouldn't expect it - Ant, Tomcat ( all versions ), > Axis, >>>> etc are all essentially based on the JavaBeans patterns. >>>> >>>> Tomcat is now going even deeper into this with JMX support, and many >>>> discussion on ant sugest more 'configurability' for components is >>>> desired. >>>> >>>> >>>> I'm also not sure what 'inconsistent' use means for you - I think >>>> ant, tomcat and most other projects I know are consistently using the >>>> bean methods, togheter with JNDI and other pull patterns. >>> >>> I only said that, "In this particular case, [Commons component > developers] >>> do not require that an external framework/factory/whatever generate Log >>> objects for individual classes". I didn't say that Commons components >>> should not have bean methods. Of course they should, when appropriate. > I >>> don't think logging is one of those cases. If we add this interface, I > fear >>> that some components will start to adopt it internally, while others > will >>> not. That's what I mean by using the interface inconsistently. >>> >> >> Are you saying that the Commons Logging component is for internal use only >> by commons components? >> > > Of course not. > Ok, good. Are you saying that any component/class/tool that implements the generic commons logger Log interface is only usable in an application environment where a special class with a static method getLogger() is in the classpath? [Modulo the real name of the class and method... You get what I mean, I hope...] I hope the answer is 'no' also, because otherwise, you are defining framework-like requirements on any app using commons-logging-using components. I am not trying to be combative - I just think that this discussion showed me that the commons logger is not as general-purpose as I thought it was - so either I made a huge mistake in leaping to conclusions, or I came at it from a different angle that has some validity :) geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Be a giant. Take giant steps. Do giant things... -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
