Thanks - it's been slow going partly because I'm being a perfectionist and partly because I found the problems around making it work in a multiple web app context without class loader leaks preventing a web app from being reclaimed properly really hard, and testing the solutions harder still.
My responses may be slow or short for the next 2 weeks as I am typing one handed with my arm in a sling... On 23 Feb 2010, at 21:19, Ceki Gülcü wrote: > Hi Robert, > > > What a pleasant surprise to see this issue moving along. I'll look at > your branch after the release of logback 0.9.19 early march. The > discussion on this topic in bug 110 was really constructive btw. > > > On 23/02/2010 7:24 PM, Robert Elliot wrote: >> It's still moving - see branch at http://github.com/Mahoney/slf4j.git >> under sysout-over-slf4j. It's close to code complete but there's some >> tidy up and test coverage I wanted to beef up and I wanted to review the >> Javadoc before updating the bugzilla entry (and I need to get round to >> printing and signing the form saying I've given it freely). >> It should be trivial to compile it (mvn package) and the only runtime >> dependency is slf4j-api. It will require you to add the following line >> somewhere early in the application's startup sequence: >> org.slf4j.sysoutslf4j.context.SysOutOverSLF4J.sendSystemOutAndErrToSLF4J(); >> >> I'd be interested in any feedback as to how it behaves in the wild. >> >> On 23 Feb 2010, at 12:07, Ceki Gülcü wrote: >> >>> Hello Gilles, >>> >>> If as Nikolas suspects, swing uses java.util.logging which it probably >>> does, then go with his suggestion of redirecting j.u.l. to SLF4J. >>> >>> If for some reason swing actually writes directly to the console, then >>> you would want to capture system.out and direct it to SLF4J. Robert >>> Elliot started working on this very tricky topic and made some real >>> progress, see [1]; but for some unfortunate reason the issue got stalled. >>> >>> HTH >>> >>> [1] http://bugzilla.slf4j.org/show_bug.cgi?id=110 >>> >>> On 23/02/2010 12:51 PM, Nikolas Everett wrote: >>>> You'd have to catch all the different loggers and funnel them into >>>> slf4j. I assume swing uses java.util.logging so you'd want the JUL to >>>> SLF4J section of http://www.slf4j.org/legacy.html . In all of my >>>> projects I typically include the other bridges (JCL and Log4J) as a >>>> matter of course but I normally don't have to deal with JUL. >>>> >>>> On Tue, Feb 23, 2010 at 6:02 AM, Gilles Gaillard >>>> <[email protected] <mailto:[email protected]> >>>> <mailto:[email protected]>> wrote: >>>> >>>> Hi, >>>> >>>> I'm new to logback and would like to know if the following already >>>> exist / is possible, i searched the mailing list but did not find this. >>>> >>>> I've a GUI application performing usual logging through logback >>>> (that's ok) and would ensure that any unexpected failure(s) be logged. >>>> For example, unexpected errors occuring on the swing EDT go the std err. >>>> Usually I would do this by redirecting the standard out/err streams >>>> to some file output. Note also that I would like to ensure that logs >>>> from different threads will log properly. For example, stack traces >>>> should not be mangled by other logs. >>>> >>>> I wonder it is possible to do this through the logback configuration. >>>> If not what would be the best way. >>>> >>>> Thanks, >>>> -- Gilles >>> >>> _______________________________________________ >>> Logback-user mailing list >>> [email protected] <mailto:[email protected]> >>> http://qos.ch/mailman/listinfo/logback-user >> >> >> >> _______________________________________________ >> Logback-user mailing list >> [email protected] >> http://qos.ch/mailman/listinfo/logback-user > > _______________________________________________ > Logback-user mailing list > [email protected] > http://qos.ch/mailman/listinfo/logback-user _______________________________________________ Logback-user mailing list [email protected] http://qos.ch/mailman/listinfo/logback-user
