My concern would be that things will get out of hand and we'll do so much logging that it will affect performance in a noticeable way. We should find a way to "compile-out" some of the logging for production use before "logging everthing".
> -----Original Message----- > From: Sean Schofield [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 07, 2005 7:49 AM > To: MyFaces Development > Subject: Re: Loggers in API Components > > I'm in favor of commons logging for everything (api, Impl and > tomahawk.) I agree with Travis that a simple logging message can go a > long way in solving a problem. In fact, robust logging can be a way > that we differentiate ourselves from other implementations. > > sean > > On 12/7/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > > Logging is always contentious. I'd rather we let the end-users > > decide, and currently the "standard" for doing that in a framework is > > to use commons-logging. We do need to clear up whether it's ok to use > > it for the api jar file, though. > > > > Our wiki currently reads: > > > > http://wiki.apache.org/myfaces/MyFaces_Developer_Notes > > =============================== > > Logging > > > > Except in the JSF API (javax.faces.*) classes, where there must not be > > any dependencies to additional libraries, commons-logging is used for > > logging generally. Commons-logging should be used in the recommended > > way, i.e. each class has it's own private static logger. > > =============================== > > > > On 12/7/05, Martin Cooper <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > On 12/6/05, Adam Winer <[EMAIL PROTECTED]> wrote: > > > > On 12/6/05, Simon Kitching <[EMAIL PROTECTED]> wrote: > > > > > > > > > Is it really ok for stuff in the "api" and "impl" subdirs to depend on > > > > > commons-logging? > > > > > > > > AFAIK, yes. Certainly for "impl", and I see no reason why not as well > > > > for "api", as long as it doesn't actually show up in the > > > > public/protected API. > > > > > > > > > > > > > Does the spec say anything about dependency requirements for the JSF > > > > > implementation? In particular, I'm concerned that j2ee.jar will > > > > > apparently require a JSF implementation to be included in the future; if > > > > > MyFaces is that implementation and it uses org.apache.* libs then those > > > > > libs must also be bundled in the j2ee.jar file, or be bundled by every > > > > > container that provides that j2ee file. And exposing libraries via the > > > > > container like that can cause pain, as we all found out when a buggy > > > > > version of org.apache.xerces was bundled with java 1.4 :-( > > > > > > > > JSF 1.2 requires J2SE 5.0 (both annotations and generics). And, yeah, > > > > any full J2EE webtier server in EE 5.0 will necessary include a JSF > > > > implementation - so, for instance, any Java EE 5.0 version of Tomcat > > > > must include a JSF implementation. > > > > > > > > JSF 1.1, well, in theory it would require JDK 1.3 at a minimum - > > > > though there's no specific reason why any particular implementation > > > > couldn't decide to make 1.4 the minimum. (And I can't specifically > > > > remember an API reason why it couldn't run on JDK 1.2 as well.) > > > > > > > > But as far as logging goes, if you're willing to take JDK 1.4 as a > > > > requirement (and I can't see why not), I find commons-logging a rather > > > > pointless bonus dependency - log4j is not sufficiently better than > > > > java.util.logging to justify its use > > > > > > I'm quite certain that Ceki would take you to task on that comment... > > > > > > But +1 on logging being a good thing. > > > > > > -- > > > Martin Cooper > > > > > > > > > > , and if you're only ever going to > > > > use java.util.logging, what's the point of going through an > > > > intermediary? > > > > > > > > Total agreement with Travis that logging in the components is a very good > > > thing. > > > > > > > > Cheers, > > > > Adam > > > > > > > > > > > >
