We definitely don't want to overlog and we definitely want to comply with the spec. Isn't commons logging already being used in places now (at least tomahawk?) IMO this is not a major dependency. Almost every single Java application I have seen has this dependency.
Maybe we could switch to JDK 1.4 logging at some future point. Again, an argument for not overlogging (less stuff to switch later!) I personally like log4j and commons logging and I haven't bothered to use JDK 1.4 logging. Its just a preference and laziness on my part. sean On 12/7/05, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]> wrote: > According to the rulebook: every dependency outside of J2EE 1.3 makes us > loose the "complete" JSF 1.1 compliancy... > > So the only perfect solution would be to either be very flexible on > the logging-type to be used or restrict to System.out.println ... > > tough decision > Alexander > > -----Original Message----- > From: Jesse Alexander (KBSA 21) > Sent: Wednesday, December 07, 2005 7:53 PM > To: MyFaces Development > Subject: RE: Loggers in API Components > > As soon as a JSF-1.1-implementation uses a JDK 1.4 (and above) feature > (as jdk-logging) this implementation will be flagged as non-complieant. > > Therefor we have a use-case against java.util.logging. > > As it seems, it is less of an issue if a javax.faces.* class has a > runtime > dependency (eg. to commons-logging). > > I'll try to clarify it further and report... > > regards > Alexander > > -----Original Message----- > From: Abrams, Howard A [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 07, 2005 7:31 PM > To: MyFaces Development > Subject: RE: Loggers in API Components > > Oh, and +1 for java.util.logging unless someone has a MyFaces use-case > that it can't handle gracefully. > > > -----Original Message----- > > From: Travis Reeder [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, December 07, 2005 10:21 AM > > To: MyFaces Development > > Subject: Re: Loggers in API Components > > > > I'm pretty sure logging is the last thing we'll have to look at for > > performance, there are many other things that will need to be > > optimized first. And I'm not saying log everything, but in places > > where it's needed like validation errors. And I think the > > cost-benefit of logging messages vs logging performance will be far > > more beneficial on the messages side. We can always optimize later > > when people are comfortable using MyFaces and one form of comfort is > > knowing why things aren't working. Sean has a good point, that logging > > can be a good differentiator, Tapestry stands out as a good example. > > > > I'm +1 for java.util.logging, I really don't know why people think > > log4j is so much better, maybe someone can fill me in? (I can see the > > flames rising from that question... ;) ) In any case, I hope we can > > come to some conclusion quickly, I'd like to start making this happen. > > > > Travis > > > > On 12/7/05, Abrams, Howard A <[EMAIL PROTECTED]> wrote: > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
