Hi. I am a transient to this list and have a question about the client-side footprint for Log4j. It used to be that Log4j was shipped with a -core.jar (still kind of large) for use on clients, but that is not the case anymore.
I have been going back and forth for months (starting a while ago and rekindling now) about the usage of wrappers around Log4j. Now other clients of mine are looking to switch to a real logging system and I am unsure what to suggest to them... for the actual interface mind you... I am 100% on using Log4j as the back end system. The first major issue is that in order for client-side code to use Log4j a rather large jar needs to be availabe, even though most clients will only use 1-3 interfaces. I understand there are some pipes underneith that need to exist, but it seems like you have get the entire system just to use a few classes. Are there any plans to make the minimal foot-print, for a null logger, smaller? Sure if people want to use full Log4j on their client-side, they will need more of the meat, but what about those who do not? Apache Commons Logging is ~20k, provides a functional bridge which can abstract the rest of the details. I have been looking over ACL for the past few days, pondering it vs. the JBoss Logger wrapper, read some of the papers which Ceki has written on the topic and have come to the conclusion that I do not like ACL. I do however like the 20k footprint. Log4j contains a lot more that ACL does, that is apparent, but most of the usage patterns will look more liek ACL + NDC/MDC. So, I am wondering ig it would be possible to make use of Log4j as a thin ACL-like interface, not directly exposing the full power of the library (thus requiring the classes to be present to load the Logger class). The powerful not-used-so-often bits could be put into helper classes which could use a Object accessor and casting to get at typed hooks in Logger to work with... or something. * * * I love Log4j. I think it is absolutly wonderful. I have been writting logging stems for business and pleasure for many years... but not anymore... well not really. Now I work on isolation wrappers for small footprints and switchablity (null, jdk14, whatever some lame vp wants). Why not make Log4j the only library you need? Proving a small footprint for the core interfaces, letting thin clients make use of it. Allow users to null or JDK14 backed (puke) impls (I think thus pluggablity is there isn't it). I would liek to replave ALL of the JBoss logging with plain Log4j, but due to the current memory requirements this is not possible. Are there any plans to make the core footprint smaller? --jason PS. Sorry for rambling... can't sleep, but I am still tired. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
