Q:

Building a mockable logging API in Java, the right way

I've been reading up on writing testable code and am now trying to put that into practise by refactoring my logging framework API.  My main concern is that it should be 1) easy to call from business code, and 2) easily mockable, so that business code can be tested without invoking the real logging and also making it possible to assert that things have been logged or not from said tests. 
I've reached a point where it feels pretty testable, but I still feel it can be improved.  Please bear with me.  This is what I have so far. 
/*
 * The public API, which has a mockable internal factory responsible for creating log implementations. 
 */
public final class LoggerManager {
    private static LoggerFactory internalFactory;
    private LoggerManager() {}

    public static SecurityLogger getSecurityLogger() {
        return getLoggerFactory().getSecurityLogger();
    }
    public static SystemErrorLogger getSystemErrorLogger() {
        return getLoggerFactory().getSystemErrorLogger();
    }
    private static LoggerFactory getLoggerFactory() {
        if (internalFactory == null) 
            internalFactory = new LoggerFactoryImpl();
        return internalFactory;
    }
    public static void setLoggerFactory(LoggerFactory aLoggerFactory) {
        internalFactory = aLoggerFactory;
    }
}
/*
 * Factory interface with methods for getting all types of loggers. 
 */
public interface LoggerFactory {
    public SecurityLogger getSecurityLogger();
    public SystemErrorLogger getSystemErrorLogger();
    // ... 10 additional log types
}
public final class LoggerFactoryImpl implements LoggerFactory {
    private final SecurityLogger securityLogger = new SecurityLoggerImpl();
    private final SystemErrorLogger systemErrorLogger = new SystemErrorLoggerImpl();

    public SecurityLogger getSecurityLogger() {
        return securityLogger;
    }
    public SystemErrorLogger getSystemErrorLogger() {
        return systemErrorLogger;
    }
}

The API is called like this in business code:
LoggerManager.getSystemErrorLogger().log("My really serious error");

I would then mock this in unit tests using a TestLoggerFactory, which creates test loggers that simply keeps track of all logging calls and makes it possible to for example do assertNoSystemErrorLogs():
LoggerManager.setLoggerFactory(new TestLoggerFactory());

Now this works fine, but I still fell as if I'm missing something and it can be made more test friendly.  For example, by using the static setLoggerFactory I'm setting the logger factory for all tests, which means one test can actually affect another.  So my big question here is, what is the standard way of creating this kind of easily mockable API?  Some kind of Dependency Injection? 
Please note that the question has more to do with writing an easy to access and use API that is also easy to mock.  The fact that my example is a logging framework API is beside the point. 

A:

I was asked in the comments to provide a sample using logger injection via CDI.  There are many possible implementations, but in order to show how different qualifiers could be used I opted for this sample where I assume that the loggers share the common Logger interface and where different qualifiers are used.  
However provided with the case of 10+ possible log types, I would opt for a qualifier using an enum property to decide which logger to inject. 
First define your qualifiers (Security, SystemError, ....) to mark which implementation you would want to inject:
@Qualifier
@Retention(RUNTIME)
@Target({TYPE, METHOD, FIELD, PARAMETER})
public @interface Security {
}

Then you have to define how you create the logger implementations.  It is a factory, sort of.  The implementation can depend on the injection point and values given to the qualifiers.  Here for example, I just pass the loggers the class name of the class where it is injected. 
The two methods are used to create the different implementations.  That can be achieved by applying the qualifiers to the methods.  
@Singleton
public class LoggerProducer {

    // here perhaps a cache or environment related flags, ...

    @Security
    @Produces
    public Logger getSecurityLogger(InjectionPoint ip) {
        String key = getKeyFromIp(ip);
        return new SecurityLoggerImpl(key);
    }

    @SystemError
    @Produces
    public Logger getSystemErrorLogger(InjectionPoint ip) {
        String key = getKeyFromIp(ip);
        return new SystemErrorLoggerImpl(key);
    }

    private String getKeyFromIp(InjectionPoint ip) {
        return ip.getMember().getDeclaringClass().getCanonicalName();
    }

}

Now you can inject your desired logger where you want to use it (see CDI configuration file beans.xml)
@Stateless
public class SampleService {

    @Inject
    @Security
    private Logger securityLogger;

    public void doSomething() {
        securityLogger.log("I did something!"); 
    }

}

When unit testing you will still have to mock the logger as you would mock every other injected object, nothing changes using CDI.  When integration testing, you could change how/what loggers are produced. 
Don't take it personal, but I don't get why to use 10+ different loggers and not use the mechanisms provided by most log frameworks and/or mock frameworks.  Perhaps you have good reasons, well, it always helps to know all your options. 

Edit: Add JUnit sample
To unit test the SampleService we create the following test case using Mockito:
@RunWith(MockitoJUnitRunner.class)
public class SampleServiceTest {

    @InjectMocks
    private SampleService sample;

    @Mock
    private Logger securityLogger;

    @Test
    public void testDoSomething() {
        doThrow(new RuntimeException("Fail")).when(securityLogger).log(anyString());

        sample.doSomething(); // will fail 
    }

}

The test is setup up in such a way, that when logger.log is called an exception is thrown.