On Fri, 29 Mar 2002, Ceki G�lc� wrote: > The problem with logging is different because: > > 1) logging calls are made thousands of times so the indirection through > an equalizer API (like commons-logging) has a performance impact
Only for the logger that do not implement the interface :-) If LogKit will implement commons-logging directly - the impact will be 0. Same for log4j, just add an implement. In addition any decent JIT will get rid of the extra indirection - you may notice a lot of wrappers are final. > 2) logging requires a configuration step. Currently this crucial step is > ignored in commons-logging. getAttribute/setAttribute allows same kind of configuration as SAX. No attribute is defined or standardised - in time we'll see what patterns emerge. Again - we want an API for logging, not configuration. There are some good APIs for configuration, no need to invent another one, and the configuration can/should be integrated in the 'main' application, not in components. > 3) In container based environments, it is important for the user to control > logging by carefully placing the log4j.jar file and its configuration file. By > introducing an extra indirection step (commons-logging detection mechanism) > this is made hopelessly complex. It's as complex as it was before - if you place commons-logging and log4j in the same place. However since commons-logging will be used in tomcat at a low level, and is likely to be in the common class loader - it will probably create some complications, especially in sandbox mode. But we are here to solve the problems and make things simpler :-) > 4) In future versions of Application Servers, it will be the job of the > application > server to *impose* the (log4j) hierarchy and the specific Logger > implementation. > This simply can not be achieved with commons-logging. Wrong :-) I think this has been discussed at length before releasing commons-logging, and use in an application server was one of the driving factors in designing the API. > The point is that logging in some respects is more complex than XML parsing. Just read the schema spec :-) > By the way, I am just curious, how many vendors (outside xml.apache.org) > implement JAXP? This has no direct bearing to the discussion. There are not so many parsers/xslt translators in wide use, it seems crimson/xerces/xalan/saxon have most of the users. I don't know any vendor of a parser/xslt that doesn't implement jaxp, and I don't know too many applications having xerces or crimson deps hardcoded in the code. BTW, JAXP is probably a wrong example - take SAX for example. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
