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.)
Sean 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 >
