On 16 Dec 2004, at 00:23, Simon Kitching wrote:
On Thu, 2004-12-16 at 10:21, Richard Sitze wrote:"Henning P. Schmiedehausen" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
