myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Korhonen, Kalle" <kkorh...@cisco.com>
Subject RE: Loggers in API Components
Date Thu, 29 Dec 2005 21:52:21 GMT
> -----Original Message-----
> From: Sean Schofield [mailto:sean.schofield@gmail.com] 
> Subject: Re: Loggers in API Components
> I don't know much about it but it sounds like that might be a 
> good solution.  Maybe that is the intention behind providing 
> it in the first place?  I wasn't around when it was 
> implemented.  I will take a look at some point (bigger issues 
> going on at the moment.)

The external context logger in servlet environment uses
ServletContext.log() as defined in the servlet spec so its up to the
container to deal with it. Tomcat uses commons-logging. It'd be a good
solution otherwise, but the bad thing is that there are no logging
levels. As such, I think it should only be used for start-up &
initialization, shutdown notification and fatal error messages.

Kalle

> On 12/29/05, Martin Marinschek <martin.marinschek@gmail.com> wrote:
> > What do you say to reuse the external context logger?
> >
> > No dependencies at all?
> >
> > regards,
> >
> > Martin
> >
> > On 12/29/05, Sean Schofield <sean.schofield@gmail.com> wrote:
> > > I agree with Manfred on this.  Stick with commons logging 
> and don't 
> > > worry about the dependency.
> > >
> > > sean
> > >
> > > On 12/23/05, Manfred Geiler <manfred.geiler@gmail.com> wrote:
> > > > Sorry for stepping into this discussion so late.
> > > >
> > > > -0.5 on having a "hard" dependency of jsf-api to an external 
> > > > logging api At least Craigs issue must be assured: developers 
> > > > should be able to compile their custom components 
> against jsf-api 
> > > > without having the need for extra libs 
> (commons-logging). Is this 
> > > > guaranteed if we only use commons-logging within 
> methods and there 
> > > > is no public/protected API dependency in jsf-api?
> > > > If yes, I'm -0 on that.
> > > >
> > > > +1 on keeping commons-logging as the primary logging 
> for impl, tomahawk, etc.
> > > >
> > > > +1 on doing more logging ;-)
> > > >
> > > > If we apply the well-known "IsDebugEnabled()" pattern, there 
> > > > should not be any performance impact.
> > > >
> > > >
> > > > Manfred
> > > >
> > > >
> > > >
> > > >
> > > > 2005/12/16, Adam Winer <awiner@gmail.com>:
> > > > > Not the spec god here, but I'd certainly vote -1 on any spec 
> > > > > requirement that jsf-api has to be dependency free, 
> as long as 
> > > > > those dependencies are private implementation 
> details.  (So, you 
> > > > > couldn't have a public or protected logger instance.)
> > > > >
> > > > > The only thing that would change my mind would be some ruling 
> > > > > from the J2EE overlords.
> > > > >
> > > > > -- Adam
> > > > >
> > > > >
> > > > > On 12/16/05, Martin Marinschek 
> <martin.marinschek@gmail.com> wrote:
> > > > > > Ok, I believe the EG has to sort out what they 
> think on this issue first.
> > > > > >
> > > > > > If not, we'll get a TCK test in the next spec 
> testing if there 
> > > > > > is a reliance of JSF-API on any other jar and we'll 
> go stomach up.
> > > > > >
> > > > > > regards,
> > > > > >
> > > > > > Martin
> > > > > >
> > > > > > On 12/16/05, Shane Bryzak <Shane_Bryzak@symantec.com>
wrote:
> > > > > > >  On Fri, 2005-12-16 at 13:10 +1300, Simon Kitching wrote:
> > > > > > >  Can we please not get sidetracked from the core issues?
> > > > > > >
> > > > > > > They are:
> > > > > > > * should we do logging via a MyFaces logging api, 
> to avoid 
> > > > > > > direct dependencies between lots of MyFaces classes and

> > > > > > > *any* external logging library?
> > > > > > > * are external dependencies allowed in the API jarfile?
> > > > > > >
> > > > > > > Once we sort those out, then we can debate 
> whether to choose 
> > > > > > > commons-logging or SLF4J.
> > > > > > >
> > > > > > >
> > > > > > >  My apologies Simon, I didn't mean to sidetrack 
> this issue.  
> > > > > > > My two cents is that avoiding dependencies should 
> not be a priority for the sake of itself.
> > > > > > > If there is an external library that is 
> compelling enough in 
> > > > > > > its usefulness then I don't see the problem with taking

> > > > > > > advantage of it.  I mentioned SLF4J, first of all 
> because I 
> > > > > > > was surprised that no-one had mentioned it 
> previously, and 
> > > > > > > secondly because it is specifically designed to eliminate

> > > > > > > the dependency on any single external logging 
> library (it is not a logging implementation itself), which 
> seems to be the foremost goal of this thread.
> > > > > > >
> > > > > > >  So, +1 from me for allowing an external dependency.
> > > > > > >
> > > > > > >  Regards,
> > > > > > >  Shane
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Simon
> > > > > > >
> > > > > > > Travis Reeder wrote:
> > > > > > > > That looks like a very interesting option, I 
> really like 
> > > > > > > > the formatted way of showing the messages and 
> the simple 
> > > > > > > > runtime jar swap to switch implementations.
> > > > > > > >
> > > > > > > > Travis
> > > > > > > >
> > > > > > > > On 12/15/05, *Shane Bryzak* <Shane_Bryzak@symantec.com

> > > > > > > > <mailto:Shane_Bryzak@symantec.com>> wrote:
> > > > > > > >
> > > > > > > > How about using SLF4J? (http://www.slf4j.org/) 
> > > > > > > > <http://www.slf4j.org/%29> For anyone that doesn't
know 
> > > > > > > > what this is, here's an excerpt from the site:
> > > > > > > >
> > > > > > > > "The Simple Logging Facade for Java or (SLF4J) 
> is intended 
> > > > > > > > to serve as a simple facade for various logging APIs

> > > > > > > > allowing to the end-user to plug in the desired 
> > > > > > > > implementation at /deployment/ time. SLF4J also 
> allows for 
> > > > > > > > a gradual migration path 
> > > > > > > > <http://www.slf4j.org/manual.html#gradual> away
from
> > > > > > > Jakarta Commons
> > > > > > > > Logging (JCL)."
> > > > > > > >
> > > > > > > > It's written by Ceki Gulcu (who also wrote 
> Log4J) and is 
> > > > > > > > compatible with the Apache license. I'm using it 
> > > > > > > > successfully in production code right now, and 
> the great 
> > > > > > > > thing about it is that it defers the choice of 
> logging API to the user at deployment time.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > >
> > > > > > > > Shane
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, 2005-12-16 at 09:35 +1300, Simon Kitching
wrote:
> > > > > > > >> Hi Mario,
> > > > > > > >>
> > > > > > > >> Mario Ivankovits wrote:
> > > > > > > >> > Why wouldnt you create this wrapper library

> under the 
> > > > > > > >> > umbrella of commns-logging?
> > > > > > > >> > Different commons-logging libraries using
static 
> > > > > > > >> > linking instead of the dynamic behaviour.
> > > > > > > >> > Say: commons-logging-log4j, commons-logging-jdklogger
> > > > > > > >>
> > > > > > > >> This sort of thing is under *consideration* 
> for commons-logging 2.0.
> > > > > > > >> However there are a number of limitations to this

> > > > > > > >> approach. You can find discussions on this in

> the commons 
> > > > > > > >> email archives, and see experimental 
> implementations of 
> > > > > > > >> various sorts in the commons-logging SVN tree.

> It's not just as simple as code-it-and-release.
> > > > > > > >>
> > > > > > > >> > I think it isnt that a good idea if every

> project comes 
> > > > > > > >> > with its own wrapper library. In the worst
case this 
> > > > > > > >> > will double the number of libraries used
- 
> even more logging hassle.
> > > > > > > >>
> > > > > > > >> What I have proposed for MyFaces is *not* the

> same thing 
> > > > > > > >> at all. Have a look at the code I've attached
here:
> > > > > > > >> http://issues.apache.org/jira/browse/MYFACES-949
> > > > > > > >>
> > > > > > > >> This solution is very lightweight and has 
> fairly good performance.
> > > > > > > >> However as the javadoc on those classes describe,
this 
> > > > > > > >> does *not* allow logging implementations to be

> swapped at 
> > > > > > > >> runtime like commons-logging does. The patch I've

> > > > > > > >> proposed requires a *recompilation* of the 
> MyFaces code 
> > > > > > > >> in order to swap logging libraries. That's the

> price paid for having a lightweight solution (so few lines of code).
> > > > > > > >>
> > > > > > > >> And that's not an approach that can be build 
> into commons-logging!
> > > > > > > >>
> > > > > > > >> Despite recompilation being required, it *does*

> > > > > > > >> centralise the dependency on the underlying 
> library into 
> > > > > > > >> *one* class, rather than having classes all over
the 
> > > > > > > >> MyFaces library depending directly on commons-logging.
> > > > > > > >>
> > > > > > > >> It also means that someone can come along and

> modify that 
> > > > > > > >> single class to use something other than 
> commons-logging, 
> > > > > > > >> so that MyFaces doesn't depend on *any* jar 
> with org.apache.commons.logging classes in it.
> > > > > > > >>
> > > > > > > >> Regards,
> > > > > > > >>
> > > > > > > >> Simon
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > http://www.irian.at
> > > > > >
> > > > > > Your JSF powerhouse -
> > > > > > JSF Consulting, Development and Courses in English 
> and German
> > > > > >
> > > > > > Professional Support for Apache MyFaces
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
> 

Mime
View raw message