Why are you doing a release of a release candidate?
Ralph
On Oct 29, 2009, at 11:47 AM, Ceki Gulcu wrote:
October 29th, 2009 - Release of SLF4J 1.5.9.RC1
Hello all,
I am happy to announce the immediate availability of SLF4J version
1.5.9.RC1, consisting of bug fixes and minor enhancements.
On Oct 29, 2009, at 1:21 PM, Ceki Gulcu wrote:
Hi there,
If the question is why a release candidate and not just 1.5.9, then
the answer is that I wanted to get input on the cal10n api and slf4j
use of it before making an official release. This made sense for
1.5.9-rc0. For 1.5.9.rc1,
On Oct 29, 2009, at 4:14 PM, Joern Huxhorn wrote:
Hi guys,
I'm just a bit confused about the started work on version 1.5.10
part in the tag description.
Are you planning to skip .9, going straight to .10?
Regards,
Joern.
That is the impression I got since this was a formal release
The JDK version in the compiler plugin needs to be set to 1.6. I'm
getting a compile error in MessageIdVerifier. The default JVM on my
machine is 1.5. I guess you don't have a mailing list yet for the
project.
Ralph
On Aug 28, 2009, at 6:04 AM, Ceki Gulcu wrote:
28th of August 2009 -
I'm out of town on vacation right now so I might not get a chance to
review this for a couple of days. But I'd like to provide my feedback
before anything is incorporated.
Ralph
On Aug 22, 2009, at 10:32 PM, Takeshi Kondo wrote:
On Aug 19, 2009, at 8:31 AM, Pete Muir wrote:
Hi Ralph,
Whether or not resource bundles suck in our opinion, they are the
standard approach to this so I believe we can't just dismiss them.
Let me rephrase. It isn't just that they suck. In my environment
resource bundles don't work for
On 19 Aug 2009, at 17:16, Ralph Goers wrote:
On Aug 19, 2009, at 8:31 AM, Pete Muir wrote:
Hi Ralph,
Whether or not resource bundles suck in our opinion, they are the
standard approach to this so I believe we can't just dismiss them.
Let me rephrase. It isn't just that they suck. In my
On Aug 19, 2009, at 1:58 PM, Ceki Gulcu wrote:
Ralph Goers wrote:
As I've said, I'm not at all in favor of SLF4J doing I18N. It is
better to do it under a framework such as Spring's MessageSource
interface where you can either use the default implementation,
which uses ResourceBundles
On Aug 19, 2009, at 2:15 PM, Ceki Gulcu wrote:
Ralph Goers wrote:
* The provision of the Locale should be an orthogonal concept to
the logging of messages and the creation of the Logger. This
should be handled via the MDC.
could be handled via the MDC. There are other ways to do
Interesting, but I personally would not be happy with that interface.
1. It relies on resource bundles.
2. None of the methods accept a Locale so the framework has to rely on
the default locale. Without this it means that while the app can
support any language a particular instance can only
.reportFailure(Class path contains multiple SLF4J bindins.);
should be
.reportFailure(Class path contains multiple SLF4J bindings.);
Ralph
On Jun 9, 2009, at 1:24 PM, c...@slf4j.org wrote:
Author: ceki
Date: Tue Jun 9 22:24:16 2009
New Revision: 1345
Modified:
The issue is in what the benefit is in having Markers for each of the
various kinds of alerts. If you check out the SLF4J extensions you
will find an EventLogger class that is meant to do this kind of thing.
It uses a Marker to categorize the log record as an Event. It then
uses a
On Jun 2, 2009, at 12:52 AM, Thorbjørn Ravn Andersen wrote:
Ralph Goers skrev den 02-06-2009 01:52:
We have a class called RequestContext. All it contains is a bunch
of constants and static helper methods to store fields into the
MDC. At the start of every request we call
We have a class called RequestContext. All it contains is a bunch of
constants and static helper methods to store fields into the MDC. At
the start of every request we call RequestContext.initialize(). That
clears the MDC and then adds a key named id that contains a
java.util.UUID as a
On Apr 23, 2009, at 8:55 AM, Ceki Gulcu wrote:
Ralph Goers wrote:
Also, As that message says I added the documentation for the two
classes. The email you quoted was from almost 2 months ago. I had
expected to get feedback on this long before this and had come to
the conclusion
On Apr 23, 2009, at 9:25 AM, Thorbjoern Ravn Andersen wrote:
c...@slf4j.org skrev:
Fewer eclipse warnings
Would it be a reasonable goal that the code base compile without any
Eclipse warnings at all?
Unfortunately, I use IntelliJ. Presumably SLF4J could just use the
checkstyle plugin
Ceki,
As much as I would like to take credit for this, r...@slf4j.org isn't
me.
Ralph
On Apr 17, 2009, at 1:37 AM, Ceki Gulcu wrote:
Hi Ralph,
I really like the changes you have made. JCL bashing is or was, as
you correctly point out, mostly unhelpful. I am currently going
through
On Apr 16, 2009, at 5:40 AM, Ceki Gulcu wrote:
Ralph Goers wrote:
I figured the easiest way to discuss this was over code so I
checked in the EventLogger classes. If it is OK I'll add
documentation for it. Otherwise the classes can easily be reverted.
Ralph
Hello all,
What
On Apr 16, 2009, at 8:59 AM, Ralph Goers wrote:
On Apr 16, 2009, at 5:40 AM, Ceki Gulcu wrote:
Ralph Goers wrote:
I figured the easiest way to discuss this was over code so I
checked in the EventLogger classes. If it is OK I'll add
documentation for it. Otherwise the classes can
When do you have the next SLF4J release in mind? I have a project that
is using what is in trunk that will be doing their formal build next
week. I'd prefer not to have to check SLF4J into our source control so
that we can do a release.
___
dev
Still has a grammatical error. It should be allowing the end user to
or allowing end users to.
Ralph
On Mar 27, 2009, at 12:25 PM, c...@slf4j.org wrote:
Author: ceki
Date: Fri Mar 27 20:25:36 2009
New Revision: 1295
Modified:
slf4j/trunk/slf4j-site/src/site/pages/index.html
Log:
Fix
?
Thanks
From: Ralph Goers [mailto:rgo...@apache.org]
To: slf4j developers list [mailto:d...@slf4j.org]
Sent: Fri, 20 Feb 2009 17:44:38 -0500
Subject: Re: [slf4j-dev] SLF4J Wrapper class line number incorrect
Take a look at XLogger in slf4j-ext.
Out of curiosity, what do you need the wrapper
I figured the easiest way to discuss this was over code so I checked
in the EventLogger classes. If it is OK I'll add documentation for it.
Otherwise the classes can easily be reverted.
Ralph
On Feb 24, 2009, at 5:20 PM, Ralph Goers wrote:
On Feb 24, 2009, at 3:32 PM, Joern Huxhorn wrote
On Feb 24, 2009, at 3:32 PM, Joern Huxhorn wrote:
Hi Ceki
On 24.02.2009, at 20:00, Ceki Gulcu wrote:
Joern,
Accepting parameters of type Object instead of String opens the
door for nasty bugs as you point out. At the same time, it also
constitutes an important extension point for
Take a look at XLogger in slf4j-ext.
Out of curiosity, what do you need the wrapper for?
Ralph
On Feb 20, 2009, at 2:58 PM, Ashley Westwell wrote:
Good Afternoon
I have created a wrapper layer for SLF4J (Listed below). However the
line number are incorrect, it is using the line numbers in
SLF4J's svn repository to sourceforge, or
something else?
Ralph Goers wrote:
What about leveraging sourceforge?
On Feb 4, 2009, at 2:18 PM, Ceki Gulcu wrote:
Hello all,
I am looking for a volunteer to mirror the logback svn repository
using svnsync as explained in [1]. This mirror would
What about leveraging sourceforge?
On Feb 4, 2009, at 2:18 PM, Ceki Gulcu wrote:
Hello all,
I am looking for a volunteer to mirror the logback svn repository
using svnsync as explained in [1]. This mirror would be used to ease
the load on our server (which is not very heavy) but most
You can look at the dependency for commons-lang in the pom. You should
also update your documentation to let users know they will have to
specify the dependency in their pom.
Ceki Gulcu wrote:
Optional means that the artifact is not exported transitively. It should not
affect the compile or
What Ceki is doing is an imperfect, but better approach than what you
are suggesting. The current approach adjusts its expectations based on
the baseline performance of the build machine. So as builds are done on
slower or faster hardware the expected baseline should change with it.
The
That's weird.
[EMAIL PROTECTED] wrote:
Author: rgoers
Date: Thu Oct 16 15:59:51 2008
New Revision: 1197
Modified:
slf4j/trunk/slf4j-site/src/site/pages/extensions.html
Log:
testing email notifications
Modified: slf4j/trunk/slf4j-site/src/site/pages/extensions.html
Sure, the indentation would be consistent with the coding standards for
the project. My personal style is as shown so it invariably shows
through on occasion. I noticed in the commit log that developers is
spelled incorrectly. I will fix that.
Ceki Gulcu wrote:
Hello Ralph,
Thank you for
In writing the doc I noticed that THROWING_MARKER and CATCHING_MARKER
both have names of EXCEPTION and also are EXCEPTION_MARKERs, which
also has a name of EXCEPTION. Is this an error?
Ceki Gulcu wrote:
Hello Ralph,
Any progress on this item?
Ralph Goers wrote:
Yes, that is fine
Darn. Please ignore. Resending to the logback list.
Ralph Goers wrote:
I would have opened a Jira issue for this (I will) but it appears to
be unavailable.
We have run into a serious performance problem with a custom appender.
The appender is not particularly fast and logback ends up being
I would have opened a Jira issue for this (I will) but it appears to be
unavailable.
We have run into a serious performance problem with a custom appender.
The appender is not particularly fast and logback ends up being a system
wide bottleneck. This is because the doAppend method of
Yes, that is fine with me.
Ceki Gulcu wrote:
Hello Ralph,
There is no hard deadline on the release, although I would like to get it
done
sometime this week, or early next week. Does that sound feasible to you?
Ralph Goers wrote:
It depends on how long you want to wait. I'm pretty
Thorbjørn Ravn Andersen wrote:
Ralph Goers skrev:
XLogger just provides some basic extended methods in a standardized
way. I would prefer that rather than use _log.debug you would use
XLogger.entry as it makes filtering them easier.
Let us come back to that later
Ceki Gulcu wrote:
What would be better, if it is possible, is to inject the logging
dynamically when needed and completely remove it when not, eliminating
any performance overhead at all.
Stopping and then restarting the application without the agent does exactly
that, no? Do you
would it be able to be removed?
In other words, eventually I'd like to see enabling and disabling of
logging (i.e. the equivalent of configuring Loggers) done via AOP.
Thorbjørn Ravn Andersen wrote:
Ralph Goers skrev:
Can you describe how this is intended to work? Does this inject logging
place.
BTW, since you have filed an ICLA, should we create a user for you in SVN?
Cheers,
Ralph Goers wrote:
I'm posting this to the dev list to help maintain the public record.
Original Message
Subject: FW: FW: New logging
Date:Wed, 24 Sep 2008 06:22:44
Thorbjørn Ravn Andersen wrote:
I read up a bit on this. It appears that maven-surefire-plugin cannot
both do unit tests and integration tests in the same life cycle (as far
as I understood).
Actually you can. I've done it. I'll dig around and find an example of
how to do it.
Ralph
Ceki Gulcu wrote:
logging for the entire class. Had you used markers, one could enable/disable
entry/exit logging without necessarily affecting logging in the rest of the
containing class. By the way, XLogger.enter() and exit() methods use the
appropriate markers.
I mentioned this as
Can you describe how this is intended to work? Does this inject logging
at runtime or build time?
[EMAIL PROTECTED] wrote:
Author: ravn
Date: Wed Oct 1 21:57:55 2008
New Revision: 1155
Added:
slf4j/trunk/slf4j-ext/src/main/java/org/slf4j/agent/AgentPremain.java
(contents, props
Does anyone know what has happened to qos.ch and logback? The mailing
list has been dead for days and the logback website went offline today.
___
dev mailing list
dev@slf4j.org
http://www.slf4j.org/mailman/listinfo/dev
I have a related question. I have built timing methods somewhat similar
to the StopWatch in logback. It seems more appropriate to me that these
be in SLF4J than logback since they really don't rely on any particular
logger implementation. I'd be happy to provide my version of these for
you to
of logback is a
very
good idea.
Anyway, I'd be happy to look at your timing methods.
You might want to enter a bug report so that this does not fall through the
cracks.
Ralph Goers wrote:
I have a related question. I have built timing methods somewhat similar
to the StopWatch
45 matches
Mail list logo
