commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [logging] Enterprise Common Logging... dare we say 2.0?
Date Thu, 16 Dec 2004 22:38:34 GMT
On 16 Dec 2004, at 00:23, Simon Kitching wrote:

> On Thu, 2004-12-16 at 10:21, Richard Sitze wrote:
>> "Henning P. Schmiedehausen" <hps@intermeta.de> wrote on 12/15/2004
>
>>> ...byte-code engineering contradict each other. One of the really,
>>> really strong things of c-l is, that it needs no additional jars. 
>>> Just
>>> drop commons-logging in, develop your app, deploy with the app,
>>> commons-logging and a logger implementation, off you go.
>>
>> This is a strong point from a "lazy" point of view [no offense, 
>> please].
>> But it's also one if it's greatest weaknesses.  You have no way of 
>> knowing
>> which logger impl. you are going to be using.  Yes, you can 
>> configure. No,
>> there is no assurance that what you configured will be used...   you 
>> can
>> check it once, but when you start deploying your applications in
>> production, you have to re-check.. and re-check... and you never know 
>> when
>> someone's going to change the classpath and change the behavior.  
>> It's a
>> nightmare.
>
> I think this demonstrates a major issue.
>
> When using logging in an "enterprise" situation, the logging can be
> considered a critical part of the application. If you have heavy-duty
> monitoring systems watching for alerts from the software, and have
> sysadmins on call 24x7 to deal with issues, then for an application to
> fail to locate the correct logging libs or config files is a *failure*
> of the app. You don't want an app to start up, but then not be able to
> generate alerts if problems occur.
>
> But when using logging in other situations, logging is *not* a critical
> part, and should not cause an application to fail to start.
>
> The latter is the focus of commons-logging at the moment. And
> unfortunately as commons-logging has no *mandatory* configuration, it 
> is
> not possible to add a "fail-on-no-config" option!

+1

it seems to me that there are actually two separate levels of 
configuration: one for the total application environment and one for 
components within that environment.

after a long time trying to work out how to satisfy everyone, i now 
think that discovery processes can only work within a particular 
application domain. for example, the current discovery process works 
well on tomcat, less well on jboss, badly in applets and not at all for 
J2ME. i believe that it would be possible to create satisfactory 
discovery systems for limited domains but it would not be possible to 
use an uber-discovery process to guess the environment.

the weakness in current design seems to be the bootstrap process. a 
discovery process most suitable for only one domain is part of the code 
that components compile against.

the solution i've been considering is to separate the base 
application-environmental configuration from the sophisticated 
discovery process required to ensure proper isolation in complex 
managed server environments. (i'm not going to describe this in detail 
right now: i should post a code example but i'm tired so that'll have 
to wait.)

where does byte-code engineering come in? well, there are certain 
things that users want that are just not going to be feasible no matter 
how sophisticated a discovery process is employed. too much complexity 
leads to fragility in the discovery code: providing rewiring at the 
byte-code level would allow users great control and relieve the 
commons-logging development team of the burden of creating every more 
complex discovery code.

- robert


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


Mime
View raw message