September 4th, 2009 - Release of SLF4J 1.5.9-RC0
Hello all,
I am proud to announce the immediate availability of SLF4J version
1.5.9-RC), consisting of bug fixes and minor enhancements. It is
totally compatible with SLF4J version 1.5.8. However, the slf4j-ext
module ships with a new package
Thorbjoern Ravn Andersen wrote:
added by portage for gitosis-gentoo skrev:
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project SLF4J: Simple Logging Facade for Java.
Could you remove
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 - Release of CAI18N version 0.2
I am happy to announce the immediate availability
28th of August 2009 - Release of CAI18N version 0.2
I am happy to announce the immediate availability of CAI18N version
0.2. Compiler Assisted Internationalization, abbreviated as CAI18N, is
a java library for writing internationalized messages. CAI18N is spawn
of SLF4J.
The two-page manual
Ralph Goers wrote:
On Aug 24, 2009, at 1:25 PM, Ceki Gulcu wrote:
Takeshi Kondo wrote:
Hi Ceki
The fact that it can't be done in log4j does not mean that it can't
be done.
Is it mean that it can be done in logback?
If it is, I'll change logger to logback.
To be honest, at present
Takeshi's submission is not a finished product so let's go easy on him. While I
have still not bought the idea of levels in enums or resource bundles, I think
the idea of using enums for resource bundle keys is an important step forward.
Having levels in the enum or resource bundles (I
Hi Takeshi,
Thank you for your response. I have looked at your code again and now understand
how levels can be set in resource bundles.
Having said that, I am not convinced that associating levels to keys in resource
bundles is a good idea because there are other possibly better ways of
Takeshi Kondo wrote:
Hi Ceki
The fact that it can't be done in log4j does not mean that it can't be
done.
Is it mean that it can be done in logback?
If it is, I'll change logger to logback.
To be honest, at present time it can't be done in logback either. However,
logback already has
Hello all,
Given that git is in my opinion such a clearly better version control
system than Subversion, I migrated the SLF4J svn repository to git. It
was easier than expected.
There are two master repositories, one hosted at git.qos.ch and the
other hosted at github. For more information on
Jukka Zitting wrote:
Hi,
It would be useful to have the old svn branches and tags also
reflected in the slf4j.git repository. If you used the standard layout
option to git-svn when migrating the code, they actually should
already exist as remote branches. Copying the references to normal
I think git supports a whole bunch of protocols including http and/or webdav.
The git.qos.ch server currently supports SSH (port 22) and the git protocol
(port 9418).
Github allows you to fork the repository, but the forked version, as far as I
could tell, is accessible only via the git
Added http support for cloning. See http://slf4j.org/repos.html
Ceki Gulcu wrote:
I think git supports a whole bunch of protocols including http and/or
webdav. The git.qos.ch server currently supports SSH (port 22) and the
git protocol (port 9418).
Github allows you to fork
Takeshi Kondo wrote:
If log level is separated, logging code is
public class enum LogMessages{
@Debug(debug log message)
TEST0001
}
Doesn't LogMessages need to be compiled? If LogMessages needs compiling, how is
it helpful?
--
Ceki Gülcü
Logback: The reliable, generic, fast
Takeshi Kondo wrote:
public class enum LogMessages{
@Debug(debug log message)
TEST0001
}
If I followed you, the idea is to encode the resource bundle *keys* within
enums. You still need to check the consistency of the resource bundle keys,
including copies found in various language
Comments inline.
Pete Muir wrote:
Hi,
As discussed here https://jira.jboss.org/jira/browse/WBRI-290, we would
like to switch to slf4j as our logger (it offers a logging facade,
supports MDC/NDC and parameter replacement).
However, as Takeshi highlights here
Pete Muir wrote:
This is valid in Java 5 and above. For example:
public interface Logger {
public enum LogMessages {
WRONG_PASSWORD
}
public static class Test {
public void test() {
Logger logger = new Logger() {
public void warn(Enum? message) {
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, or easily provide your own. As I said, I'm also
Ralph Goers wrote:
In cases like event logging it may be that the event logs
are viewed by customer service reps speaking in multiple languages. In
that case the locale of the person viewing the log is important (which
may be days or months after the log entry was recorded).
Very good
Hello all,
My submission for a SLF4J/logback talk for this year's Devoxx
conference has been accepted. For those who don't know Devoxx, rumor
has it that it is the biggest Java conference in Europe.
Cheers,
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for
Hello Thorbjoern,
It's a nice read. I'd like to link to it from the Articles section of
http://slf4j.org/docs.html asap. Please let me know when you are ready.
Thorbjoern Ravn Andersen wrote:
Joern Huxhorn skrev:
Thorbjoern Ravn Andersen wrote:
Would your friend be interested in
Ralph, thank you for catching this.
Ralph Goers wrote:
.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
June 10th, 2009 - Release of SLF4J 1.5.7
Hello all,
I am happy to announce the immediate availability of SLF4J version
1.5.7, consisting of bug fixes and minor enhancements. It is totally
compatible with SLF4J version 1.5.6.
Please refer to the the news page for precise details.
Thorbjoern Ravn Andersen wrote:
Ceki Gulcu skrev:
Here is a idea:
Marker TX_BEGIN = MarkerFactory.getMarker(TX_BEGIN);
Marker TX_END= MarkerFactory.getMarker(TX_END);
try {
logger.info(TX_BEGIN, beginning tx);
doSomething();
} finally {
logger.info(TX_END, ending tx);
}
Ok. If I
Thorbjoern Ravn Andersen wrote:
I think that would be one of those use cases for an NDC... see
http://apps.sourceforge.net/trac/lilith/wiki/NestedDiagnosticContext
Interesting. But does anything actually happen when the push and pops
are executed?
You can emulate NDC using MDC. Anyway,
Here is a idea:
Marker TX_BEGIN = MarkerFactory.getMarker(TX_BEGIN);
Marker TX_END= MarkerFactory.getMarker(TX_END);
try {
logger.info(TX_BEGIN, beginning tx);
doSomething();
} finally {
logger.info(TX_END, ending tx);
}
Thorbjoern Ravn Andersen wrote:
Ceki Gulcu skrev:
Thorbjoern
Jukka Zitting wrote:
On Thu, May 28, 2009 at 6:17 PM, Ceki Gulcu c...@qos.ch wrote:
No, just that in most cases some essential piece of the puzzle (source
code, stack traces, or in this specific example thread names) is not
readily available for a variety of different reasons. For example
ogradyjd wrote:
I think I may have glossed over a major point in what I need to do. The
logging system has to continue working as it does now, with no knowledge
that the log message stream is being forked. One of the major problems I'm
trying to get around is that the log files and
Jukka Zitting wrote:
Anyway, what I was trying to say is that you can typically get away
with less detailed log messages when you have access to the source
code (and understand it, e.g. you known how the controller in your
example it works) and detailed logging metadata (thread names, line
Thorbjoern Ravn Andersen wrote:
Naturally.
Often people who ask a question have gotten stuck on solving a problem
in a specific way, and ask about how to do the specific way. Knowing
about the underlying problem may allow an alternate approach which may
even happen to work better (if at
Hello Robert,
As Jukka's mail indicates, the modification you suggest is not
necessarily for the better. I personally tend to agree with
Jukka. There are probably others who would be more inclined to agree
with your position. However, even in cases where we all agree on the
merits of a change,
SLF4J offers very little in terms of functionality beyond the
abstraction of logging frameworks. I should have mentioned that it
does on so on purpose. The message interceptor functionality is not
aligned with that minimalistic philosophy. In short, there very little
chance for the interceptor
Thorbjoern Ravn Andersen wrote:
But enough technicalities. I'd much rather that you provide specific
detail on what it is you want to solve, and why it cannot be done within
the current functionality?
It would be interesting to hear about the problem he is trying to
solve but ultimately
Thorbjoern Ravn Andersen wrote:
For people who come to slf4j and do not already know about the subject
it is a steep learning curve. Apparently even intentionally...
The intention is obviously not to annoy users on purpose.
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible
Thorbjoern Ravn Andersen wrote:
Please don't toppost.
I was not aware that we had a posting policy.
I'll revert it for now, and come back to it later. I found that Bruce
Eckell uses it in his book Thinking in C++ so there is at least another
author I can locate who use it :)
After
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?
Reasonable yes, possible no. There are 5 warnings total in the project
(all modules). Two in LoggerFactory about
wrote:
Ceki Gulcu skrev:
Thorbjørn Ravn Andersen wrote:
As such I see no reason not to promote logback - you just need to
communicate very clearly that you are advertising for some other
software that happens to have been written by you. IMHO that is
better than the official slf4j text
You can easily make maveninzed project eclipse-ready by launching the mvn
eclipse:eclipse command. Once you do that, you just import into Eclipse the
various SLF4J modules as eclipse projects. Once you have eclipse and maven
installed, and SLF4J checked out, the mvn eclipse:eclipse procedure
Thorbjoern Ravn Andersen wrote:
I humbly disagree, and deserves credit for that feels more like
boasting than providing neutral information (as you happen to have
written both pieces of software AND the manual providing the link).
Deserves credit is the term I used in an email. It is not
Hello Thorbjørn,
Do you intend to pursue this effort on coloring? As this revision stands, I
don't see the point... Put differently, it looks like a lot of effort for a
meager result. WDYT?
r...@slf4j.org wrote:
Author: ravn
Date: Sun Apr 19 02:23:53 2009
New Revision: 1321
Modified:
Hi Thorbjørn,
Would you please elaborate on why you removed the section on built-in support
in logback? Was it for reasons of principal or readability?
r...@slf4j.org wrote:
Author: ravn
Date: Sat Apr 18 21:20:52 2009
New Revision: 1318
Modified:
Thorbjoern Ravn Andersen wrote:
The praise for logback sticked out as much as the putting down of JCL,
as this is in the context of a platform neutral logging framework facade.
I have to agree, having a separate section on logback stuck out.
--
Ceki Gülcü
Logback: The reliable, generic,
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 the manual making
changes on my own. These changes will be committed shortly.
Cheers,
r...@slf4j.org wrote:
Author: ravn
Date: Thu Apr 16
Hello all,
With impetus given by Ralph Goers, the SLF4J documentation has been simplified
and improved. The updated documentation should be especially helpful for new
SLF4J users. If you find any part of the documentation unclear, please let us know.
TIA,
--
Ceki Gülcü
Logback: The
See http://slf4j.org/faq.html#declared_static
The official stance is that there is no official stance. :-)
Thorbjoern Ravn Andersen wrote:
c...@slf4j.org skrev:
One notable exception is that the logger field is not static.
I thought it was by mistake, but apparently it is deliberate. I
WTF?
c...@slf4j.org wrote:
Author: ceki
Date: Fri Apr 17 15:05:40 2009
New Revision: 1310
Added:
slf4j/trunk/slf4j-ext/slf4j-ext/
Log:
Share project slf4j-ext into
https://svn.slf4j.org/repos/slf4j/trunk/slf4j-ext;
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging
Thorbjoern Ravn Andersen wrote:
Is there any scenario to your knowledge where the logger lookup
mechanism may be slow?
No, it's never slow. However, some implementations are better than others.
Am I right in assuming that the logback mechanism for looking up
loggers is faster than in
Ralph Goers wrote:
Ceki,
As much as I would like to take credit for this, r...@slf4j.org isn't me.
No it isn't. I had user ids 'ravn' and 'rgoers' confused.
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
It was actually Thorbjørn Ravn Andersen and not Ralph who started the work on
the documentation. Sorry for the confusion.
Ceki Gulcu wrote:
Hello all,
With impetus given by Ralph Goers, the SLF4J documentation has been
simplified and improved. The updated documentation should
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 is the current status on EventLogger and EventData classes?
Hello all,
SLF4J users have been asking for varags support for a long time. See
http://bugzilla.slf4j.org/show_bug.cgi?id=31 for more details. The
plan is to add varags support in SLF4J version 1.6 to be released later
this year, possibly in October 2009.
The idea is extremely simple. We would
/faq.html#IllegalAccessError
Gunnar Wagenknecht wrote:
Ceki Gulcu schrieb:
Hello Gunnar,
MDC is by construction a class with static methods. I fail to see how
IMDCFactory could be made to create a fixed and static class. It just
does not make sense. Have you noticed the MDCAdapter interface
Hello Gunnar,
MDC is by construction a class with static methods. I fail to see how
IMDCFactory could be made to create a fixed and static class. It just
does not make sense. Have you noticed the MDCAdapter interface?
Cheers,
Gunnar Wagenknecht wrote:
Hi,
I started implementing a native
Hello Jukka,
Jukka Zitting wrote:
Hi,
On Mon, Feb 9, 2009 at 4:42 PM, Ceki Gulcu c...@qos.ch wrote:
I guess that you'd svnsync initialize both repositories with a username
and password of your choice and we'd proceed from there.
OK. I now have a mirror of SLF4J at http://svn
After brief testing, svn synchronization seems to work well. I noticed that svn
commits now take a little longer to complete, by say 5 seconds, which is quite
acceptable. Intentionally setting a wrong address for synchronization did not
affect the regular commit process which is quite
Hi Jukka,
A daily sync would be fine but an hourly sync, if it's not too much of a hassle,
would be even better. As an alternative and from what I understand, it seems
that the svnsync sync command can be driven from the master repository. Thus,
adding a post-commit hook would be quite
Do you mean moving 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
Our infrastructure runs quite nicely. I am just trying to ensure that it will
survive physical disaster. In exchange for backup service of our svn repository,
we are willing respond in kind (act as a back up for a remote svn repository).
As for SLF4J moving to Apache, it's just not worth the
, this is your last chance to reconsider...
Jukka Zitting wrote:
Hi,
On Wed, Feb 4, 2009 at 11:18 PM, Ceki Gulcu c...@qos.ch wrote:
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
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 importantly
act as a backup.
Any volunteers?
[1] http://tinyurl.com/7b24qu
--
Ceki Gülcü
Hello all,
I'd like to release SLF4J 1.5.6 which corrects the long standing and very
annoying bug 84 and its younger sibling bug 113. If you'd like to mention
recent changes in news.html I invite you do so before tomorrow.
Cheers,
--
Ceki Gülcü
Logback: The reliable, generic, fast and
.
On Mon, Nov 17, 2008 at 10:12 AM, Thorbjørn Ravn Andersen
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
Ceki Gulcu skrev:
Optional means that the artifact is not exported transitively. It
should not
affect the compile or test class paths.
Ok
Needles to say, the 'integration' module is part of SLF4J:
http://svn.slf4j.org/viewvc/slf4j/trunk/
http://svn.slf4j.org/viewvc/slf4j/trunk/integration/
Ceki Gulcu wrote:
Hello Ralph, Thorbjørn,
How about using the 'integration' module? It is designed for testing after
all
ralph.goers @dslextreme.com wrote (on logback-dev mailing list):
I am starting to wonder if ext should be a root directory for some
subprojects. For example, AOP could be one subproject, utils another,
AS400 a third. Then we wouldn't need to make the dependencies optional,
but it will lead
Hello Ralph,
Ralph Goers wrote:
I added a new class to slf4j-ext. Should I create a bug to track it? I
don't see the normal maven changes.xml either so I guess that isn't
part of the process?
You can just document its addition in news.html.
On a related note, the class I added has a
Hello Thorbjørn,
Thorbjørn Ravn Andersen wrote:
What is your current estimate for the 1.5.6 release?
I would like to get logback 0.9.12 out the door first. SLF4J 1.5.6 will come
later, probably in December.
/Thorbjørn
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible
Hello,
Looking at docs, I came across this:
You MUST remember to have slf4j-api-1.5.6.jar explicitly provided to
the program to be instrumented. If not, the one embedded in the
slf4j-ext-1.5.6.jar library is used, and these classes cannot see the
jars loaded later. (Empirically
Thorbjørn Ravn Andersen wrote:
Ceki Gulcu skrev:
Thorbjørn Ravn Andersen wrote:
I have been wondering what exactly it is that you are trying to do? Is
it trying to establish a unit for CPU usage from which you can establish
an upper bound for how long a given test may take
Thorbjørn Ravn Andersen wrote:
Superficially. It looked to me as you were calibrating using a sort
(due to the checkins handling the different algorithms in the Windows
and Linux JVM's), which may or may not be relevant for logging
performance as the operations done are different.
The
Hello
You can see the latest Continuum build results for SLF4J and logback at
http://continuum.qos.ch/
You can register a new user (which is complicated because most of the links
need
to be massaged) or alternatively login as dev with password dev + 1,
where
+ stands for append.
Thorbjørn Ravn Andersen wrote:
I have been wondering what exactly it is that you are trying to do? Is
it trying to establish a unit for CPU usage from which you can establish
an upper bound for how long a given test may take?
Something like that. By measure the time it takes to perform a
/pom.xml
UbinderVersion.pl
Aintegration/lib/slf4j-simple-INCOMPATIBLE.jar
svn: Server sent unexpected return value (403 Forbidden) in response to
OPTIONS request for 'https://svn.slf4j.org/repos'
So, currently I am a bit stuck. Please advise :)
/Thorbjørn
Ceki Gulcu skrev
Thorbjørn Ravn Andersen wrote:
Ceki Gulcu skrev:
Why are you disabling printSummary for the tests?
I am trying to avoid log blindness. Essentially I would like the
complete output from maven to contain only information about stuff that
failed
October 17th, 2008 - Release of SLF4J 1.5.5
Version 1.5.5 comes less than 24 hours after release 1.5.4. We
realized that the version check mechanism introduced in SLF4J 1.5.4
was inconsistent with the large size of SLF4J's installed user
base. We cannot expect external SLF4J implementations to
Hi Ralph,
We use virtual email adresses which are quite involved to get right. I usually
need 3 iterations. So I impersonated your svn id (rgoers) by clobbering your
MD5-encoded password with my MD5-encoded password. I know mine password and do
not know yours. When notifications go through,
Hello Ralph,
Thank you for documenting the org.slf4j.ext package. My recent commit below
brings changes in indentation which should be invisible to users. Otherwise, I
added a reference to XLogger and XLoggerFactory in the javadocs.
If you don't mind, I would like to change the indentation of
October 16th, 2008 - Release of SLF4J 1.5.4
I am happy to announce the the immediate availability of SLF4J version
1.5.4.
This version corrects critical bugs. You are highly encouraged to
upgrade to SLF4J version 1.5.4. The upgrade should pose no
problems. Nevertheless, you might still want to
Yes, it's definitely an error. It was fixed in revision 1188.
Thank you Raplh.
Ralph Goers wrote:
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?
--
Sure, no worries.
Ralph Goers wrote:
Darn. Please ignore. Resending to the logback list.
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
___
dev mailing list
dev@slf4j.org
Hi Thorbjørn,
Why is Hudson the Extensible continuous integration engine relevant in
relation with building slf4j or more precisely running mvn test?
Cheers,
Thorbjørn Ravn Andersen wrote:
I did some research to see if I could run automated testing on a clean
room JVM, but it turned out to
Hello Ralph,
Any progress on this item?
Ralph Goers wrote:
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
Thorbjørn Ravn Andersen wrote:
I asked earlier how you set up Eclipse to work with slf4j but did not
get a clear answer. Do you just extract the files outside of eclipse
and manually set up a complete build path?
After checking out SLF4J, I invoke mvm eclipse:eclipse from the top-level
Thorbjørn Ravn Andersen wrote:
Thank you. Yes, this works for me if I use maven 2.0.9 (the default
maven on OS X 10.5 is 2.0.6), and imports well (but no slf4j-parent
project, hmm).
slf4j-parent produces a pom artifact (packaging type = pom). So it seems
normal that slf4j-parent should
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 sure I can get that
documented by the end of the
Ralph Goers wrote:
I'd also like to point that XLogger.enter and exit() method use the TRACE
level
whereas LogTransformer uses DEBUG. A little consistency is in oder... Either
both use TRACE or both should use DEBUG.
Obviously, I prefer TRACE for this. Logging with flow tracing
Ralph Goers wrote:
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.
In our code we manually add entry, exit, caught, etc. to everything
except simple
Hello all,
I'd like to soon cut a release for SLF4J 1.5.4.
Here is the change summary.
- Improvements to documentations as well as fix for packaging problems related
to slf4j-ext module.
- At initialization time, LoggerFactory will check that the version of the
slf4j-binding matches that of
for this.
-Original Message-
From: Ceki Gulcu [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 24, 2008 2:49 AM
To: Goers, Ralph
Subject: Re: FW: New logging
Hi Ralph,
Thank you for your input. I agree that having to declare both an xlogger and
a
logger is cumbersome
Thorbjørn Ravn Andersen wrote:
I'm trying to get unit tests up and running in Maven for the agent, but
I am unfamiliar with the Maven way of doing things, so I'd appreciate
some comments.
I've figured out how to use the argLine tag to get -javaagent:foobar
put in the right place of
Thorbjørn Ravn Andersen wrote:
Ralph Goers skrev:
Thanks,
I'm quite interested in this, but not only for entering and exiting but
eventually for other logging as well. However, I wouldn't want it in
all classes. I'd prefer to see additional configuration to define which
classes
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).
Oh the joy of other peoples tools :)
Maven is far from perfect.
On a related note, the
Thorbjørn Ravn Andersen wrote:
Any particular reason you wrote a Perl script instead of using the Ant
Replace task?
Here is the rationale. As the release manager, I am the only one who runs the
script. The Ant equivalent of the script would not gain much except the
dependency on Perl
Thorbjørn Ravn Andersen wrote:
Ceki Gulcu skrev:
Does _log field refers to a logger named after the containing class? If so,
you
could enable/disable logging for each java class separately using the
configuration mechanism provided in log4j/jul/logback. In other words,
additional
Thorbjørn Ravn Andersen wrote:
Frankly I just want to know to know when I was (one of the) responsible
for the build breaking and when it was ok again.
If the problem persists we'll tackle it.
Also it confused me a bit in the beginning to see stack traces in the
maven output, but
Hello all,
Thorbjørn has observed that slf4j test spewed a lot of garbage on the console.
I
just modified the various tests so that the unit test are silent. This has been
done by
- In slf4j-jdk14, setting the level of the root logger to OFF
- In jcl-over-slf4j, replacing slf4j-simple by
September 12th, 2008 - Release of SLF4J 1.5.3
I am happy to announce the immediate availability of SLF4J version
1.5.3.
Added a new module called slf4j-ext for slf4j-extensions. See its
documentation for further details.
Fixed bug 71 which was re-opened by Manfred Geiler. SLF4J loggers now
Hello All,
I will be unavailable for couple of weeks and did not wish to delay this
release
any further.
Ceki Gulcu wrote:
September 12th, 2008 - Release of SLF4J 1.5.3
[snip]
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
Hello Thorbjørn,
Thorbjørn Ravn Andersen wrote:
My Windows box needed to be reinstalled and it takes longer than
expected to be fully back in business. This includes my logback/slf4j
subscriptions.
A crashing laptop? Sounds like fun. :-)
I'd like to know which development
Hi Matt,
Matt Humphreys wrote:
Hi,
a 0.1 release candidate of the slf4j taglib is available for download
http://www.slf4j.org/taglib/
That's a good start. You might also want to upload slf4j-taglib-0.1RC.jar and
accompanying files to mvnrepo-slf4j-tablib so that people can declare
Hello Matt,
I also added a cronjob that automatically correct the permissions for the
www-slf4j-taglib module.
Cheers,
Matt Humphreys wrote:
Hi,
a 0.1 release candidate of the slf4j taglib is available for download
http://www.slf4j.org/taglib/
matt
--
Ceki Gülcü
Logback: The
Thorbjørn Ravn Andersen wrote:
Ceki Gulcu skrev den 25-08-2008 22:18:
If your are uncomfortable with incorporating XLogger in the instrumentation
code, that's fine with me. However, if you are uncomfortable with XLogger by
itself, regardless of instrumentation, then I welcome any
1 - 100 of 126 matches
Mail list logo
