At 10:41 PM 10/19/2005, Jacob Kjome wrote:
No, I'm talking about running LogWeb against Log4j-1.3 at runtime, not
compiling
LogWeb against 1.3. LogWeb was compiled against 1.2.xx and run against 1.3.
I'm not saying this is the end-all-be-all test of runtime compatibility,
but it
does seem to work against an application, LogWeb, that hits a lot of Log4j's
api.
I suggest you either wait for Mark to cut a new alpha (I think he said he was
going to do it tonight or, at least, very soon) or build it yourself and
verify
whether my statements are correct.
Yes, that would be the right thing to do. Unfortunately, I am quite
overwhelmed with other tasks.
Wasn't that discussed before and considered a no-go for many users of JCL to
move to SLF4J? Seems like a small sacrifice to make in order to ease the
transition from JCL to SLF4J.
From what I have seen so far, the users who wish to see TRACE added
cannot make a coherent and logical case. (Alternatively, I may be too
thick to understand their case which is a distinct possibility.) I would
love to hear about a logical justification for TRACE. Currently the
dominant argument seems to be "some of our users wanted it, so we
added it" which is simultaneously both a very valid and bogus
argument, depending on how you look at it.
Certain user's refusal to consider SLF4J because TRACE is missing has
to be weighed against the good of the SLF4J API in the long run, say 3
years from now.
Cheers,
Jake
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
Improve your Sudoku skills at http://www.sudoku-grok.com/
_______________________________________________
dev mailing list
[email protected]
http://slf4j.org/mailman/listinfo/dev
