-1 for log4j
In many projects that I am involved in, java.util.logging is the preferred/required logging framework - usually due to corporate policy. 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.
Having read the article I found its content to be very misleading and full of FUD. On the surface the article tends to give the message that commons-logging is problematical and should be avoided at all cost. However, when you read between the lines, the problem is not that people choose to use commons logging. The problem is in fact the way that some application server vendors have implemented classloading and logging within their offerings - particularly when they ship their application server with commons-logging included. Incidentally, JBoss has very similar issues with classloading, conflicting logging and so on and it uses log4j directly and there is no commons-logging in sight. The 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.
From my interpretation, the article was actually recommending the following (although it didn't make it explicitly clear):
1) If you are the developers of an actual deliverable application that will not be integrated with other products then pick one particular logging strategy and use it directly
2) If you are the developers of an application server then fix your classloading & logging so that there are no conflicts with the logging strategy of other products or libraries
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)
I would therefore suggest that commons-logging is actually a valid technical choice in the case of Wicket. 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.
regards, Chris
Donnerstag, Juergen wrote:
In the light of the article mentioned above, and I think it is very
profound, I agree to switch to log4j.
+1
Regards Juergen
P.S: I'll gather the votes over the next 2 weeks.
-----Ursprüngliche Nachricht-----
Von: Gwyn Evans [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 3. November 2004 22:52
An: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Betreff: Re: AW: [Wicket-user] Wicket; Package com.voicetribe.util.code
On Mon, 1 Nov 2004 09:51:37 +0100, Donnerstag, Juergen <[EMAIL PROTECTED]> wrote:
this is true. It has been discussed about 2 weeks before to replace ICodeBroadcaster with commons-logging.
It may be a bit late, but can I ask that if you've not read this (http://www.qos.ch/logging/thinkAgain.jsp) and the links it points to, would you *please* do so...
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_idU88&alloc_id065&op=click _______________________________________________ Wicket-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/wicket-user
------------------------------------------------------- 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
