logging-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Log4J v 1.3 and v 2.0
Date Fri, 17 Sep 2004 15:42:35 GMT
On Friday 17 September 2004 20:06, Shapira, Yoav wrote:

> One that I'd advise against, because why would you ever want to remove
> logging from your webapp?  One of the basic premises of log4j is that
> logging is an essential basic feature of any application, one that
> should always be used (judiciously).  The use-case of removing the
> logging subsystem of a running application is one that right now (it's
> early morning here) doesn't make much sense to me.

Let's say we have a server that _really_ wants to run 'forever'. I want to 
upgrade from Log4J 1.3 to  1.5 after a couple of years... :o) No kidding!
And that without shutting anything down...

> By the way, in m years on the log4j-user and other mailing lists, I've
> never seen a single request for either of your use-cases.  So I'm
> curious as to what makes you think they're needed?  They might be nice
> to have, but not at the price of breaking backwards-compatibility.

We have started a discussion with Ceki on how to accommodate for our request. 
The problem at the moment is that we are to high up on the "power user" 
scale, that what we are trying to achieve is not easily conveyed. The promise 
we make is solving JAR Hell through dependency resolution, in-app component 
dependency, hierarchical application containers, and classloader management 
for hot-deploy, hot-redeploy, hot-undeploy applications, and the ability to 
grow existing applications in runtime.
This is not ordinary web-apps, nor your average Desktop client or other basic 
app. We are building a robust framework for future application servers, where 
"fake hot-deploys" won't cut it.
There is also a security concern of not exposing implementation classes to 
client apps, which may have profound consequences (security experts perhaps 
can tell)... It is not really my area.

We think that when smart people like Ceki and yourself "gets it", you will be 
somewhat impressed and be happy that Log4J is a central piece of it, instead 
of the now feature-wise outdated LogKit.

We think that a reorganization into API, SPI vs Impl(s) Jars is sufficient, 
and that the compounded Jar (all classes in the same jar) can be kept for the 
average user. Whether the 'separation' is easy or not depends largely on how 
well structured the current codebase is, i.e. is there proper separation 
between API and Impls and so on. As far as I have looked it looks promising, 
but it is too early to tell for sure.

  / http://www.bali.ac        /
 / http://niclas.hedhman.org / 

View raw message