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. Cheers Niclas -- +------//-------------------+ / http://www.bali.ac / / http://niclas.hedhman.org / +------//-------------------+
