[logback-user] (no subject)

[Robert Elliot]

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
>>>> <gillouxgaillard at wanadoo.fr <mailto:gillouxgaillard at wanadoo.fr>
>>>> <mailto:gillouxgaillard at wanadoo.fr>> 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
>>> Logback-user at qos.ch <mailto:Logback-user at qos.ch>
>>> http://qos.ch/mailman/listinfo/logback-user
>> 
>> 
>> 
>> _______________________________________________
>> Logback-user mailing list
>> Logback-user at qos.ch
>> http://qos.ch/mailman/listinfo/logback-user
> 
> _______________________________________________
> Logback-user mailing list
> Logback-user at qos.ch
> http://qos.ch/mailman/listinfo/logback-user