2006/1/10, Korhonen, Kalle [EMAIL PROTECTED]:
-Original Message-
From: Harald Ommang [mailto:[EMAIL PROTECTED]
Subject: Re: Loggers in API Components
On Tue, 10 Jan 2006 14:39:23 +0100
Manfred Geiler [EMAIL PROTECTED] wrote:
facesContext.getExternalContext().log
On 1/11/06, Manfred Geiler [EMAIL PROTECTED] wrote:
2006/1/10, Korhonen, Kalle [EMAIL PROTECTED]:
If one really wants to combine java logging to log4jLogs, I'd think you
should be able to fairly easily write a java log handler using log4j
logger (don't know how the performance of such a
Adam Winer wrote:
On 1/11/06, Manfred Geiler [EMAIL PROTECTED] wrote:
2006/1/10, Korhonen, Kalle [EMAIL PROTECTED]:
If one really wants to combine java logging to log4jLogs, I'd think you
should be able to fairly easily write a java log handler using log4j
logger (don't know how the
On 1/11/06, Simon Kitching [EMAIL PROTECTED] wrote:
Adam Winer wrote:
On 1/11/06, Manfred Geiler [EMAIL PROTECTED] wrote:
2006/1/10, Korhonen, Kalle [EMAIL PROTECTED]:
If one really wants to combine java logging to log4jLogs, I'd think you
should be able to fairly easily write a java log
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
On 1/10/06, Manfred Geiler [EMAIL PROTECTED] wrote:
facesContext.getExternalContext().log();Yes, this was my first intention then, when I did not dare to adddependencies 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
On Tue, 10 Jan 2006 14:39:23 +0100
Manfred Geiler [EMAIL PROTECTED] 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
-Original Message-
From: Harald Ommang [mailto:[EMAIL PROTECTED]
Subject: Re: Loggers in API Components
On Tue, 10 Jan 2006 14:39:23 +0100
Manfred Geiler [EMAIL PROTECTED] wrote:
facesContext.getExternalContext().log();
And, of course, it will be too late. Because, when JSF 2
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
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
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
-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
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
]
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
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
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
I just reviewed the code of jsf-api again - and what someone - was it
you, Manfred? did before was calling
facesContext.getExternalContext().log();
Now is this what we actually want to do?
regards,
Martin
On 12/23/05, Adam Winer [EMAIL PROTECTED] wrote:
On 12/23/05, Manfred Geiler [EMAIL
replace Simons classes. And that's it...
Therefor: great work Simon
regards
Alexander
-Original Message-
From: Mario Ivankovits [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 15, 2005 8:53 AM
To: MyFaces Development
Subject: Re: Loggers in API Components
Hi Simon!
Why wouldnt you create
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
How about using SLF4J? (http://www.slf4j.org/) 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
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.TravisOn 12/15/05,
Shane Bryzak [EMAIL PROTECTED] wrote:
How about using SLF4J? (http://www.slf4j.org/) For anyone that doesn't
Travis Reeder wrote:
S, can we have a quick vote on this? I'd like to be able to check
in logging changes, and we can always change which logging facility we
use later with the good ol' search and replace.
+1 java.util.logging
-1 on using java.util.logging in MyFaces 1.1.x. That is a
-1 java.util.logging
+1 commons-logging - cause this is used right now all over the codebase.
If we want to change to use log4j directly, this would be another
issue, another vote.
regards,
Martin
On 12/15/05, Simon Kitching [EMAIL PROTECTED] wrote:
Travis Reeder wrote:
S, can we have
Martin Marinschek wrote:
-1 java.util.logging
+1 commons-logging - cause this is used right now all over the codebase.
If we want to change to use log4j directly, this would be another
issue, another vote.
I would prefer to see some myfaces logging API that would be a facade,
avoiding a
Ok,
still another issue, another vote.
For the short run, Travis should go with commons-logging IMHO.
For the long run, it might be optimal to wrap away commons-logging. If
someone actually implements that, I don't see a problem with this
approach. Simon, you are volunteering, I suppose ;) ?
Hi,
I don't see that this is such an issue for tobago/tomahawk/cherokee.
None of those components will be bundled in the container, so if one of
those libs requires a particular helper library, then the webapp
deployer can just deploy that library at the webapp level.
It's when a j2ee.jar
According to my experience, logging if done right, does not affect the
performance too much, in the worst case, you always can turn it off,
all you get is a few ifs here and then.
Usually the performance is just fine as soon as you turn on asynchronous
logging instead of synchronous.
Logging is always contentious. I'd rather we let the end-users
decide, and currently the standard for doing that in a framework is
to use commons-logging. We do need to clear up whether it's ok to use
it for the api jar file, though.
Our wiki currently reads:
I'm in favor of commons logging for everything (api, Impl and
tomahawk.) I agree with Travis that a simple logging message can go a
long way in solving a problem. In fact, robust logging can be a way
that we differentiate ourselves from other implementations.
sean
On 12/7/05, Mike Kienenberger
.
-Original Message-
From: Sean Schofield [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 07, 2005 7:49 AM
To: MyFaces Development
Subject: Re: Loggers in API Components
I'm in favor of commons logging for everything (api, Impl and
tomahawk.) I agree with Travis that a simple logging
:[EMAIL PROTECTED]
Sent: Wednesday, December 07, 2005 10:21 AM
To: MyFaces Development
Subject: Re: Loggers in API Components
I'm pretty sure logging is the last thing we'll have to look at for
performance, there are many other things that will need to be
optimized first. And I'm not saying
Oh, and +1 for java.util.logging unless someone has a MyFaces use-case
that it can't handle gracefully.
-Original Message-
From: Travis Reeder [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 07, 2005 10:21 AM
To: MyFaces Development
Subject: Re: Loggers in API Components
I'm
. to commons-logging).
I'll try to clarify it further and report...
regards
Alexander
-Original Message-
From: Abrams, Howard A [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 07, 2005 7:31 PM
To: MyFaces Development
Subject: RE: Loggers in API Components
Oh, and +1 for java.util.logging
Message-
From: Jesse Alexander (KBSA 21)
Sent: Wednesday, December 07, 2005 7:53 PM
To: MyFaces Development
Subject: RE: Loggers in API Components
As soon as a JSF-1.1-implementation uses a JDK 1.4 (and above) feature
(as jdk-logging) this implementation will be flagged as non-complieant.
Therefor
-Original Message-
From: Jesse Alexander (KBSA 21)
Sent: Wednesday, December 07, 2005 7:53 PM
To: MyFaces Development
Subject: RE: Loggers in API Components
As soon as a JSF-1.1-implementation uses a JDK 1.4 (and above) feature
(as jdk-logging) this implementation will be flagged as non
On 12/6/05, Simon Kitching [EMAIL PROTECTED] wrote:
Is it really ok for stuff in the api and impl subdirs to depend on
commons-logging?
AFAIK, yes. Certainly for impl, and I see no reason why not as well
for api, as long as it doesn't actually show up in the
public/protected API.
Does the
36 matches
Mail list logo
