Hmmm... no logging levels does make it less attractive. Sean
On 12/29/05, Korhonen, Kalle <[EMAIL PROTECTED]> wrote: > > -----Original Message----- > > From: Sean Schofield [mailto:[EMAIL PROTECTED] > > 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 <[EMAIL PROTECTED]> wrote: > > > What do you say to reuse the external context logger? > > > > > > No dependencies at all? > > > > > > regards, > > > > > > Martin > > > > > > On 12/29/05, Sean Schofield <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: > > > > > > 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 > > <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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* <[EMAIL PROTECTED] > > > > > > > > > <mailto:[EMAIL PROTECTED]>> 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 > > > > > >
