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 some of the description? The
bugzilla-dae...@pixie.qos.ch skrev:
return null;
Please. No null values returned - it means that you need to check the
return value each and every time. Much rather a NullObject.
http://en.wikipedia.org/wiki/Null_Object_pattern
--
Thorbjørn Ravn Andersen ...plus... Tubular
Joern Huxhorn skrev:
Thorbjoern Ravn Andersen wrote:
Would your friend be interested in reviewing such documentation,
perhaps even with the intent of providing it to the students?
Yes, he'd be interested in both ;)
I got around to finish the first draft :)
I'd appreciate your
Joern Huxhorn skrev:
On 01.06.2009, at 20:23, Thorbjoern Ravn Andersen wrote:
Ceki Gulcu skrev:
Hi Thorbjoern,
You have two tools at your disposal: markes and MDC. Do you think you
could come up with something using those two primitives?
Perhaps. It would need to map into two calls, one
Ceki Gulcu skrev:
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
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 understand this correctly, it still
Robert Elliot skrev:
Just curious about this - I often find myself catching an exception
and not really having anything to say about it other than that I want
to log the exception. So I end up calling log.error(ex.getMessage(),
ex) - which seems a bit redundant as I'll get the message out
Joern Huxhorn skrev:
Would your friend be interested in reviewing such documentation,
perhaps even with the intent of providing it to the students?
I'll ask him and let you know,
I have pondered a bit on this and started writing today. It is still
very early but I thought you might want
Hi Ceki.
I am looking at the AS/400 Collection Services where it would be
interesting to write a logback appender for.
It has a notion of a transaction context where you basically say
transaction start (gives A as a handle), log stuff in context A
(repeatedly), transaction A stop
How
Jukka Zitting skrev:
Hi,
On Thu, May 28, 2009 at 4:32 PM, Robert Elliot r...@lidalia.org.uk wrote:
I take it you include a date stamp in all your log messages then?
Point taken. Though in fact I would put a timestamp in a log message
if it was directly relevant to the logged event
John O'Grady skrev:
Hello devs - I love your product, and I'm trying to use it in a
special logging system I'm developing as an open source project. One
of the things I need for this to work is the ability to intercept
messages being logged by the slf4j framework, ostensibly right after
the
Ceki Gulcu skrev:
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
Joern Huxhorn skrev:
A friend of mine is a tutor at TU Darmstadt, teaching very fresh
computer science students the very first steps of Java.
He thinks, and I agree, that it's a good idea to show them a proper
logging framework right ahead so they don't even start putting
System.out into their
Ceki Gulcu skrev:
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.
Obviously? Not to me, sorry.
Thank you
Ceki Gulcu skrev:
- partially reverted 1329
Note on log levels needlessly clutters the text
Have you considered *discussing* this before just deleting it?
There is a VERY good reason for me writing this text.
I am sorry for not discussing this particular item. Would you please
Ceki Gulcu skrev:
Hello Thorbjoern,
I am in favor of code prettifiers as long as they allow us to
emphasize, e.g. present in bold, selected parts of the code, but if
not, then I prefer ugly. :-)
Thorbjoern Ravn Andersen wrote:
Ceki Gulcu skrev:
Hello Thorbjørn,
Do you intend to pursue
Ralph Goers skrev:
Yes, I knew that. The issue is I really don't want to us Eclipse as my
IDE. It seems silly to load it just to see the warnings. Most, if not
all, the ones you mentioned would also be shown in IntelliJ. Running
something as a maven report is far more palatable than being
Ceki Gulcu skrev:
As in revision 1325, the mention of logback is quiet discreet. I will
not bend backwards and avoid mentioning logback just to prove that
SLF4J provides a neutral playing field. I do not wish to start a
debate about morality.
BTW, have you actually looked at 1325?
I read
Ceki Gulcu skrev:
Hello Thorbjoern,
I am in favor of code prettifiers as long as they allow us to
emphasize, e.g. present in bold, selected parts of the code, but if
not, then I prefer ugly. :-)
I have tried to find a blog entry again who talked about that most
programmers these days use
Ralph Goers skrev:
Unfortunately, I use IntelliJ. Presumably SLF4J could just use the
checkstyle plugin and then I could verify it before committing.
Setting up checkstyle for a multi module project is a bit tricky, but
I've
I don't mind a few extra commits.
If you can use Eclipse on
Ceki Gulcu skrev:
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:
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 thought
the official stance was that logger fields should be static to avoid
having to reinitialize for each new instance of the containing
Ceki Gulcu skrev:
See http://slf4j.org/faq.html#declared_static
The official stance is that there is no official stance. :-)
If I understand the link correctly the primary reason for recommending
not static is to allow repository selectors to work with logback?
Do you have benchmark figures
Ceki Gulcu skrev:
See http://slf4j.org/faq.html#declared_static
The official stance is that there is no official stance. :-)
If I understand the link correctly the primary reason for
recommending not static is to allow repository selectors to work
with logback?
Hmm, I would not word it
24 matches
Mail list logo
