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
> > > > >
> > > >
> > > >
> > >
>
>

Reply via email to