Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 99729 invoked from network); 3 Apr 2002 22:12:28 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 3 Apr 2002 22:12:28 -0000 Received: (qmail 7247 invoked by uid 97); 3 Apr 2002 22:12:32 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 7231 invoked by uid 97); 3 Apr 2002 22:12:32 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 7220 invoked from network); 3 Apr 2002 22:12:31 -0000 Message-ID: <003501c1db5c$a5dbbc80$0b03050a@eb.com> Reply-To: "Morgan Delagrange" From: "Morgan Delagrange" To: "Jakarta Commons Developers List" , "Morgan Delagrange" References: Subject: Re: [logging] Need interface... Date: Wed, 3 Apr 2002 16:12:29 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ----- Original Message ----- From: To: "Jakarta Commons Developers List" ; "Morgan Delagrange" Sent: Wednesday, April 03, 2002 3:04 PM Subject: Re: [logging] Need interface... > On Wed, 3 Apr 2002, Morgan Delagrange wrote: > > > > Please move the discussion about IoC and Avalon to avalon-dev. > > > > I'm sorry if this is such a politically charged term for you. I'm merely > > referring to the practice of externally generating a class' Log object. > > Call it what you like. > > The practice of allowing an external class to set the log object is > pretty standard since Beans were used the first time. > > The practice of forcing all components to use setters and not allowing > pull is specific to Avalon. > > Jumping from 'allowing a component to be managed by having a setter' to > 'all compoents should be configured only with setters and everyone > should use only IoC' is what I don't like in this context. Fine by me. All I mean to refer to is externally setting the Log object. Use whatever terminology makes you comfortable. > > > > Most of the components implement Beans patterns and should support > > > runtime changes to config ( JMX or not ). That has nothing to > > > do with any inversion of control, it's standard java. > > > > In this particular case, we would not implement this interface in our > > components, because we do not require that an external > > framework/factory/whatever generate Log objects for individual classes. And > > Yes, we do not _require_ an external 'whatever' to generate and set the > Log objects. > > But that doesn't mean we shouldn't _allow_ 'watever' to set or change > the Log object. > > That's the difference. Not _allowing_ this because some other project is > forcing everyone to use only this pattern is a bit crazy. I'm not saying that we shouldn't allow you to set an external Logger because Avalon requires it. 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. > > 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. > > It may be 'inconsistent' from Avalon perspective, but that doesn't mean > we shouldn't use it. We don't claim to support IoC. > > Costin > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: For additional commands, e-mail: