Re: AW: AW: [Wicket-user] Wicket; Package com.voicetribe.util.code
Yes, it's such a shame that the Java team at Sun didn't get together with the Log4J group and come up with a common api like the other SPI approaches so that all logging was at least compatible with each other! Gwyn Evans wrote: On Thu, 04 Nov 2004 15:19:06 +, Chris Turner <[EMAIL PROTECTED]> wrote: 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 Interesting... I remember thinking that there's be this sort of thing someday when the first suggestions were made about the JDK including it's own logging rather than using log4j. (I've no idea how feasible that would have been, it just seems a shame they couldn't/didn't.) Anyway, thanks for the comments and with that sort of senario, which I've been fortunate to have avoided so far, I can only agree that clogging is the only way to go for Wicket! Hopefully, we won't come across any issues anyway but do tend to agree with you that gains of getting it into more places should outweigh the potential downside. Cheers, 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 --- 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
Re: AW: AW: [Wicket-user] Wicket; Package com.voicetribe.util.code
On Thu, 04 Nov 2004 15:19:06 +, Chris Turner <[EMAIL PROTECTED]> wrote: > 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 Interesting... I remember thinking that there's be this sort of thing someday when the first suggestions were made about the JDK including it's own logging rather than using log4j. (I've no idea how feasible that would have been, it just seems a shame they couldn't/didn't.) Anyway, thanks for the comments and with that sort of senario, which I've been fortunate to have avoided so far, I can only agree that clogging is the only way to go for Wicket! Hopefully, we won't come across any issues anyway but do tend to agree with you that gains of getting it into more places should outweigh the potential downside. Cheers, 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
Re: AW: AW: [Wicket-user] Wicket; Package com.voicetribe.util.code
Gwyn Evans wrote: On Thu, 04 Nov 2004 11:22:42 +, 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 us
Re: AW: AW: [Wicket-user] Wicket; Package com.voicetribe.util.code
+1 keep commons-logging Martijn Dashorst wrote: Yes, and that's why commons-logging is the only viable solution. Although commons-logging apparently has its problems, those problems might be fixed in newer versions. There are people specifically thinking about the logging problem in the commons-logging project, so let them figure out that, so that we can concentrate on developing Wicket. Creating Yet Another Logging Wrapper is not preferrable. +1 for staying with commons-logging, provided we keep up with newer versions. Martijn -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Namens Donnerstag, Juergen Verzonden: donderdag 4 november 2004 12:50 Aan: '[EMAIL PROTECTED]' Onderwerp: AW: AW: AW: [Wicket-user] Wicket; Package com.voicetribe.util.code Chris, 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. Isn't this what ICodeBroadcaster was about and what we just removed? Regards Juergen -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Im Auftrag von Chris Turner Gesendet: Donnerstag, 4. November 2004 12:23 An: [EMAIL PROTECTED] Betreff: Re: AW: AW: [Wicket-user] Wicket; Package com.voicetribe.util.code -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 - down
Re: AW: AW: [Wicket-user] Wicket; Package com.voicetribe.util.code
On Thu, 04 Nov 2004 11:22:42 +, 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
RE: AW: AW: [Wicket-user] Wicket; Package com.voicetribe.util.code
Yes, and that's why commons-logging is the only viable solution. Although commons-logging apparently has its problems, those problems might be fixed in newer versions. There are people specifically thinking about the logging problem in the commons-logging project, so let them figure out that, so that we can concentrate on developing Wicket. Creating Yet Another Logging Wrapper is not preferrable. +1 for staying with commons-logging, provided we keep up with newer versions. Martijn -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Donnerstag, Juergen Verzonden: donderdag 4 november 2004 12:50 Aan: '[EMAIL PROTECTED]' Onderwerp: AW: AW: AW: [Wicket-user] Wicket; Package com.voicetribe.util.code Chris, >>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. Isn't this what ICodeBroadcaster was about and what we just removed? Regards Juergen -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Chris Turner Gesendet: Donnerstag, 4. November 2004 12:23 An: [EMAIL PROTECTED] Betreff: Re: AW: AW: [Wicket-user] Wicket; Package com.voicetribe.util.code -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 >__
Re: AW: AW: AW: [Wicket-user] Wicket; Package com.voicetribe.util.cod e
Yes, that is the case. However, I personally feel that commons-logging is a preferable solution to logging in Wicket as we are expecting other people to write Wicket components and making them learn a custom logging API is probably not something that we wish to force on them. regards, Chris Donnerstag, Juergen wrote: Chris, 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. Isn't this what ICodeBroadcaster was about and what we just removed? Regards Juergen -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Chris Turner Gesendet: Donnerstag, 4. November 2004 12:23 An: [EMAIL PROTECTED] Betreff: Re: AW: AW: [Wicket-user] Wicket; Package com.voicetribe.util.code -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 ma
AW: AW: AW: [Wicket-user] Wicket; Package com.voicetribe.util.cod e
Chris, >>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. Isn't this what ICodeBroadcaster was about and what we just removed? Regards Juergen -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Chris Turner Gesendet: Donnerstag, 4. November 2004 12:23 An: [EMAIL PROTECTED] Betreff: Re: AW: AW: [Wicket-user] Wicket; Package com.voicetribe.util.code -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 --- 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
Re: AW: AW: [Wicket-user] Wicket; Package com.voicetribe.util.code
-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
AW: AW: [Wicket-user] Wicket; Package com.voicetribe.util.code
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
AW: [Wicket-user] contributions
Johan, Mind you giving me admin privileges temporarily? I'll than try to fix it myself. Regards Juergen -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Johan Compagner Gesendet: Dienstag, 2. November 2004 11:56 An: [EMAIL PROTECTED] Betreff: Re: [Wicket-user] contributions Maybe we will need a Wicket-Contrib yes but i need see where we put these. I thought we already had such a thing but can't find it at the moment. I also have looked at youre write access problems with the example apps. I have currently no idea why you don't have access.. Because we don't restrict anybody and developer should have write acess... johan Donnerstag, Juergen wrote: >Hi, > >May I ask one of the administrators to create a /contribution directory >for components and other pieces which should not be part of the core. > >/contribution >/contribution/components >/contribution/miscelleaneous > >Regards >Juergen > > >--- >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 > > > > --- 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 --- 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
