Hi folks, Maybe i don't get the whole picture here but i would like to propose my point of view and some ideas i've come up with. First of all, i would like to use the proper acronyms to define what we are talking about : API : Application programming interface. A set of reusable classes or routines that provide common functionality. SPI : Service provider interface : A set of classes that provide an implementation for an API. We all know that in every cornerstone project, the interface should be cleary separated from the implementation. It allows us then to choose the implementation without modifying the code. For example : you have JDBC, JNDI, JAXP (and others ...) which are APIs and you can find SPI for these : - database vendor (sybase, oracle, ibm ...) specific SPI (aka drivers) for JDBC. - storing system specific SPI for JNDI : ldap, dns, cosnaming, filesystem... - vendor specific SPI (Xalan-J from apache, Saxon, Java 2 Standard Edition 1.4.0 Beta from sun) for JAXP - ... What i'd like to see is another line like : - JLI (java logging interface) API which has 3 implementations (SPI) : JLog, Log4j, and J2SE 1.4 default implementation. So where does Log4j fit in this picture in it's actual state ? For sure, Log4j provides very useful functionalities to handle application logging. Indeed, user feedback has been tremendous, and Ceki has been hard at work to add more features to the product. It could then be considered as the defacto standard for java logging. But i don't think it's enough for everyone to use it directly in all applications. Why ? Because i don't think anybody want their apps tied to a particuliar vendor specific implementation no matter its quality. If i'm an J2EE programmer, i don't want to tie my code to Weblogic or Websphere or JBoss... I want to program to a standard API and be able to deploy my applications on whichever platform i want. I think the logging API should cover 95% of logging need (categories, filters, and so on ok...) but not the tiny remaining 5% to satisfy everyone. If you have the specific need in your own components to use the fancy double-mapped-nested-diagnostic-context-o-matic, then fine, use all the proprietary bells and whistles of your logging product and bypa ss the now-too-limited-for-you standard API. I for one want to be able to switch logging implementation for whatever reason : sometimes it will be because the way log4j handles logging will not meet the requirements for performance, security, available memory (in a PDA for example), and so on... Ok now here is another thing we could consider using when dealing with things such as logging : aspect programming. The idea is to decouple 'technical' concerns such as logging, security of exeception handling from the business core of the application (it sounds like a commercial ad). Aspect programming has an implementation in Java : www.aspectj.org. I read on their website that they plan to add the possibility of dynamicaly adding 'aspects' to existing class files. So, you don't worry about logging at compile time, nor at runtime unless you specify otherwise and write some kind of descriptor that would be applied on the classes at runtime by the AspectJ toolkit... cheers, Gilles Philippart
