commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@optonline.net>
Subject Re: [logging] Need interface...
Date Thu, 04 Apr 2002 00:37:30 GMT
On 4/3/02 6:08 PM, "Morgan Delagrange" <mdelagra@yahoo.com> wrote:

> 
> ----- Original Message -----
> From: "Geir Magnusson Jr." <geirm@optonline.net>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> Sent: Wednesday, April 03, 2002 4:43 PM
> Subject: Re: [logging] Need interface...
> 
> 
>> On 4/3/02 5:12 PM, "Morgan Delagrange" <mdelagra@yahoo.com> 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.                                     geirm@optonline.net
System and Software Consulting
Be a giant.  Take giant steps.  Do giant things...


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message