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. > 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?) > 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... > 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? > 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 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. > 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? 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
