You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Manfred Geiler <ma...@gmail.com> on 2006/01/10 14:39:23 UTC
Re: Loggers in API Components
>> facesContext.getExternalContext().log();
Yes, this was my first intention then, when I did not dare to add
dependencies to other libs in the first place - one year ago, or two?
;-)
And it again came into my mind during the current discussion. But, as
Kalle mentioned, there are no log levels at all. So, although nifty,
this would be a non-practicable solution.
Adam, do you remember the primary idea behind adding this log method
to the ExternalContext API? Looks to me like it is only there, because
ServletContext does have it as well. Or is there any use case scenario
for using this method?
Now, we could request the addition of log levels for JSF 2.x. But
then, we could also request the addition of log levels to
ServletContext. And that would probably be too much... ;-)
And, of course, it will be too late. Because, when JSF 2.x is out, we
will already have thousands of commons-logging calls in our code. ;-)
As nobody seems to be against it, I would say:
Kickoff for commons-logging in API.
Manfred
2005/12/30, Martin Marinschek <ma...@gmail.com>:
> Right.
>
> settled ;)
>
> regards,
>
> Martin
>
> On 12/30/05, Sean Schofield <se...@gmail.com> wrote:
> > Hmmm... no logging levels does make it less attractive.
> >
> > Sean
> >
> > On 12/29/05, Korhonen, Kalle <kk...@cisco.com> wrote:
> > > > -----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 <ma...@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 <se...@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 <ma...@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 <aw...@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
> > > > <ma...@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 <Sh...@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
> > > > > > > > > > > <ma...@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
> > > > >
> > > >
> > >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
Re: Loggers in API Components
Posted by Harald Ommang <ha...@ommang.com>.
On Tue, 10 Jan 2006 14:39:23 +0100
Manfred Geiler <ma...@gmail.com> wrote:
>>> facesContext.getExternalContext().log();
>
...
> And, of course, it will be too late. Because, when JSF
>2.x is out, we
> will already have thousands of commons-logging calls in
>our code. ;-)
>
>
Would it not be infinitely better to create a thin MyFaces
internal wrapper around Commons Logging, to keep the
dependency in a single place, instead of thousands...?
Regarding Commons Logging, take a look at this article:
http://www.qos.ch/logging/thinkAgain.jsp.
The article is from 2002, but I assume many of the
arguments are still valid.
Harald
Re: Loggers in API Components
Posted by Adam Winer <aw...@gmail.com>.
Yup, as Craig said the intention is purely to support the
Servlet/Portlet APIs without directly depending on them.
But for logging, the intention of the Java EE framework (as
of 1.4, that is) is entirely java.util.logging. ExternalContext.log()
is just one of those legacy things that we have in abundance
in Java land. commons-logging is fine for products that
can't require JDK 1.4 (like the spec part of MyFaces)
-- Adam
On 1/10/06, Craig McClanahan <cr...@apache.org> wrote:
>
>
> On 1/10/06, Manfred Geiler <ma...@gmail.com> wrote:
> > >> facesContext.getExternalContext().log();
> >
> > Yes, this was my first intention then, when I did not dare to add
> > dependencies to other libs in the first place - one year ago, or two?
> > ;-)
> >
> > And it again came into my mind during the current discussion. But, as
> > Kalle mentioned, there are no log levels at all. So, although nifty,
> > this would be a non-practicable solution.
> >
> > Adam, do you remember the primary idea behind adding this log method
> > to the ExternalContext API? Looks to me like it is only there, because
> > ServletContext does have it as well. Or is there any use case scenario
> > for using this method?
>
> One of the primary motivations is that both ServletContext and
> PortletContext have log() method signatures. As with almost everything else
> in ExternalContext, JSF tries to shield you from having to explicitly
> accomodate the differences between servlet and portlet APIs.
>
> > Now, we could request the addition of log levels for JSF 2.x. But
> > then, we could also request the addition of log levels to
> > ServletContext. And that would probably be too much... ;-)
> > And, of course, it will be too late. Because, when JSF 2.x is out, we
> > will already have thousands of commons-logging calls in our code. ;-)
>
>
> ExternalContext.log() is defined in terms of the log() calls on the
> underlying servlet and portlet APIs, which don't have such a distinction ...
> but I suppose one could implement the concept anyway at the JSF level.
>
> > As nobody seems to be against it, I would say:
> > Kickoff for commons-logging in API.
> >
> > Manfred
>
> Craig
>
>
Re: Loggers in API Components
Posted by Craig McClanahan <cr...@apache.org>.
On 1/10/06, Manfred Geiler <ma...@gmail.com> wrote:
>
> >> facesContext.getExternalContext().log();
>
> Yes, this was my first intention then, when I did not dare to add
> dependencies to other libs in the first place - one year ago, or two?
> ;-)
>
> And it again came into my mind during the current discussion. But, as
> Kalle mentioned, there are no log levels at all. So, although nifty,
> this would be a non-practicable solution.
>
> Adam, do you remember the primary idea behind adding this log method
> to the ExternalContext API? Looks to me like it is only there, because
> ServletContext does have it as well. Or is there any use case scenario
> for using this method?
One of the primary motivations is that both ServletContext and
PortletContext have log() method signatures. As with almost everything else
in ExternalContext, JSF tries to shield you from having to explicitly
accomodate the differences between servlet and portlet APIs.
Now, we could request the addition of log levels for JSF 2.x. But
> then, we could also request the addition of log levels to
> ServletContext. And that would probably be too much... ;-)
> And, of course, it will be too late. Because, when JSF 2.x is out, we
> will already have thousands of commons-logging calls in our code. ;-)
ExternalContext.log() is defined in terms of the log() calls on the
underlying servlet and portlet APIs, which don't have such a distinction ...
but I suppose one could implement the concept anyway at the JSF level.
As nobody seems to be against it, I would say:
> Kickoff for commons-logging in API.
>
> Manfred
Craig