myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Marinschek <martin.marinsc...@gmail.com>
Subject Re: Loggers in API Components
Date Thu, 29 Dec 2005 20:30:59 GMT
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