maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ceki <c...@qos.ch>
Subject Re: Logger and Embedded Maven Core ITs
Date Sun, 17 Mar 2013 20:10:26 GMT


On 17.03.2013 00:47, Jason van Zyl wrote:
> If that's the case Ceki might be able to add the clearing of the logger map to the reset
method.
>
> Ceki, would this be hard to change?

I just added a reset method to SimpleLoggerFactory. See 
https://github.com/qos-ch/slf4j/commit/6dd3a60ee77a5cd17e for the 
commit.  Here is sample code for invoking this method in Maven tests:

import org.slf4j.ILoggerFactory;
import org.slf4j.LoggerFactory;

   ILoggerFactory iLoggerFactory = LoggerFactory.getILoggerFactory();
   if(iLoggerFactory instanceof SimpleLoggerFactory) {
     ((SimpleLoggerFactory) iLoggerFactory).reset();
   }

As the reset() method is package protected, it needs to be invoked from 
code in the org.slf4j.impl package. A "friend" class could expose the 
reset method to classes in other packages.

Anyway, let me know how if this works for you.

> On Mar 16, 2013, at 4:38 PM, Stuart McCulloch <mcculls@gmail.com> wrote:
>
>> On 16 Mar 2013, at 13:58, Jason van Zyl wrote:
>>
>>> Hervé,
>>>
>>> Can you take a look at the logging changes you made to try and use the SLF4J
package private method for resetting the logger? The streams are being reset correctly but
the logging level doesn't appear to be reset which causes the embedded ITs to fail.
>>
>> Did some investigating and the issue seems to be that SLF4J Simple uses a static
singleton logger factory which contains a map of cached loggers.
>>
>> Because embedded test mode uses the same classloader for all the tests (it only forks
once at the start) each test therefore sees the same logger factory and any previously cached
loggers.
>>
>> This means that although the MavenCLI successfully resets SLF4J to refresh the log
level, the new setting doesn't affect previously cached loggers (they only pick up the level
in their constructor).
>>
>> This can be shown with the following hack to clear the logger map (not sane code,
just proof-of-concept) which solves the embedded logging IT failures:
>>
>> diff --git a/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/Slf4jSimpleConfiguration.java
b/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/Slf4jSimpleConfiguration.java
>> index 6a7f385..f1af143 100644
>> --- a/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/Slf4jSimpleConfiguration.java
>> +++ b/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/Slf4jSimpleConfiguration.java
>> @@ -58,5 +58,20 @@ public void activate()
>>          // property for root logger level or System.out redirection need to be taken
into account
>>          MavenSlf4jFriend.reset();
>>          MavenSlf4jSimpleFriend.init();
>> +
>> +        try
>> +        {
>> +             org.slf4j.ILoggerFactory loggerFactory = org.slf4j.LoggerFactory.getILoggerFactory();
>> +             synchronized ( loggerFactory )
>> +             {
>> +                 java.lang.reflect.Field loggerMap = loggerFactory.getClass().getDeclaredField(
"loggerMap" );
>> +                 loggerMap.setAccessible( true );
>> +                 ( (java.util.Map) loggerMap.get( loggerFactory ) ).clear();
>> +             }
>> +        }
>> +        catch ( Exception e )
>> +        {
>> +            // ignore for now...
>> +        }
>>      }
>> }
>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder & CTO, Sonatype
>>> Founder,  Apache Maven
>>> http://twitter.com/jvanzyl
>>> ---------------------------------------------------------
>>>
>>> People develop abstractions by generalizing from concrete examples.
>>> Every attempt to determine the correct abstraction on paper without
>>> actually developing a running system is doomed to failure. No one
>>> is that smart. A framework is a resuable design, so you develop it by
>>> looking at the things it is supposed to be a design of. The more examples
>>> you look at, the more general your framework will be.
>>>
>>> -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason

--
Ceki



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message