Re: AW: AW: [Wicket-user] Wicket; Package com.voicetribe.util.code

[Chris Turner]

Gwyn Evans wrote: On Thu, 04 Nov 2004 11:22:42 +0000, Chris Turner <[EMAIL PROTECTED]> wrote: In many projects that I am involved in, java.util.logging is the preferred/required logging framework - usually due to corporate policy. I think the point was made that the jdk logging's fine, but if you either want more advanced facilities or pre-jdk1.4 then you need something else. Yes, I agree completely. However, any library should not dictate that you must use any particular logging framework. This was the whole reason that commons-logging was developed, to allow people to write reusable libraries that can work with any logging strategy associated with the project that the library is used in. I would therefore not want a requirement on log4j as this leads to extra library, configuration and log management requirements. Some organisations I have worked for would explicitly preclude use of Wicket if it depended on log4j. I don't see that this particular argument holds any weight in this particular senario, as the choice appears not to be "log4j vs jdk", but "log4j vs clogging". Either way, you end up with extra jar(s), etc. (Why explicitly precude log4j btw? What about if clogging was using it's primary default... Which happens to be log4j?) I personally like log4j and use it in my own projects. However a number of my corporate customers dictate that jdk logging must be used for all application logging on all projects. They have non-Java support staff who are familiar with jdk log output and so on. Thus my choice for these customers is limited either to libraries that support jdk logging or ones supporting commons-logging where I can configure this to use jdk logging as opposed to log4j. Libraries that force use of log4j are therefore not an option. It's not the issue of jar files, its an issue of the actual log files produced, their locations, formats and so on. At the opposite end, I have seen some customers who dicatate the exact oppisite in that all logging must be done by log4j. To satisfy both sets (plus everyone in between) commons-logging is the ONLY viable solution. If Wicket were to dicate Log4J then many of my corporate customers would not be prapared to accept it. However they are happy for libraries and products to use commons-logging because they can set these up to produce the jdk style logs that they are used to and have the tools and skills to work with. Having read the article I found its content to be very misleading and full of FUD. I rather expected it to be labelled FUD - I'm not sure it stands up though in this case... There are a number of postings there ffrom various authors who I'd hesitate to lay that accusation against... Yes, but their arguments are not against commons-logging as a concept for use in libraries that need to integrate into many different projects, and hence many different logging environments. The bulk of their arguments relate to either using commons-logging for end applications when there is really no need to do so (because a particular logging implementation will always  have been selected and is unlikely to change), the fact that commons-logging hides some of the powerful features of the underlying logging platform OR to the poor way that commons-logging integrates with certain application servers. For most libraries (like Wicket) the full power of the underlying logging platform is not necessary. Additionally, if the application servers hadn't made such a mess of their own logging implementations then the commons-logging issue would not exist. arguments against commons-logging such as applications taking over logging control, difficulty in tracking down application server bugs and so on have nothing to do with a project deciding to use commons-logging. These are issues that must be dealt with by the application server vendor. Hmm, I thought a large part of the argument was with the clogging wrapping & discovery methods, not the appservers? The wrapping problem is indeed a problem if you apply commons-logging to your whole project. However, it is much less of a problem when applied to libraries that rarely need to access the full power of these libraries and instead rely on the logging configuration that commons-logging discovers. The commons-logging discovery methods are a problem BECAUSE of the way that app servers implement classloading and the fact that these app severs also include commons-logging within their own implementations but do not hide this from the developers of the end applications. If all application servers hid the classloaders that they use to implement their own internals and only exposed to applications a very resticted shared library class loader and the classloader for the applications then the commons-logging discovery issues would not exist. 3) If you are developing a reusable library that will be used by many people then commons-logging is a suitable solution (despite its weaknesses) Well, the view of the author of clogging was less clearcut. (Linked from the article) He suggested if you were an author of a component (NB: Not a framework) then clogging *might* be a suitable solution. I see Wicket as being closer to a component than to a framework. In the strictest sense of the word a framework is something over which you have full architectural control within your particular team (i.e. you can select design patterns, implementation strategies, library dependencies, logging solutions and so on). Wicket (and most other open source projects) are actually component libraries that make it easier to build frameworks for a particular application.  A framework for a large application includes component libraries for persistence, inversion of control, transaction, logging,  UI layer, aspects and so on plus the code and patterns for how they are all linked together. Thus Wicket is just one component within an application framework - it is not itself a framework. The closest thing to a true framework is the Spring Framework as this brings together its own implementation of all the different components (plus the ability to integrate alternative components) along with the glue logic and patterns. (Incidentally, Spring Framework went through these exact same discussions and settled on commons-logging as the best comprimise solution!) I would therefore suggest that commons-logging is actually a valid technical choice in the case of Wicket. In an ideal world, yes. The point is that it's not an ideal world and there's the suggestion that the gains of clogging are not worth the problems that clogging opens you to. I think you are spot on for cases where commons-logging is being used in an end application or in an application server: the gains are not worth the problems. However, for a reusable component library (which is what Wicket is) the problems of common-logging are actually outweighed by the gains or portability and usability of Wicket in a number of different application architectures and frameworks (where logging is log4j, jdk or some third-party or custom developed solution). The only other solution is to include a custom logging API and implementation that Wicket uses directly and into which users can plug a particular logging implementation (e.g. log4j or java.util.logging) as part of the application settings. Aren't you saying that the answer's clogging or clogging? Yes, the answer is commons-logging unless we want to dictate that users must use a particular logging framework. Any component library that dictates something as fundamental as this is unlikely to gain widespread adoption. To paraphrase a standard quote "You can have any colour as long as it's black" just does not cut it in the world of reusable component library development. regards, Chris Anyway, my vote's to drop the wrapping and just go with log4j... /Gwyn ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Wicket-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/wicket-user