At 04:08 09.10.2002 -0700, you wrote: >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.
What do you mean by "for use on clients"? Applets? More comments at the end... >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? One question is whether the JVM will load unused classes in a jar file. Assume a jar file is 1MB consisting of 1000 classes of which only 3 are used. What is the memory footprint? The disk footprint is 1MB but is that directly correlated with the memory footprint? If classes are loaded on a need-only basis, then why would anyone care about the disk footprint, unless the jar file is accessed from the network. >--jason > > >PS. Sorry for rambling... can't sleep, but I am still tired. I know the feeling. -- Ceki TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. -- Jon Postel, RFC 793 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
