I need to have an Custom Wrapper around Log4j2. The basic requirement is that. My application should only use My CustomLogger everywhere. instead of Log4j2 logger so in future if needed i can remove 3rd party library like log4j2 etc dependency easily.
How can i do this ??
Log4j2 comes with a tool for generating custom logger wrappers:
See http://logging.apache.org/log4j/2.0/manual/customloglevels.html#CustomLoggers
This tool was intended for use with custom log levels but you can also use it for your purpose. There are a few methods you may want to remove if you want to completely remove all references to the log4j2 api, but it will still save you a lot of work.
The Log interface
First, you requires an interface to be used in each class of application. e.g.:
public interface Log {
boolean isInfoEnabled();
void info(String str);
void info(String str, Throwable t);
}
The wrapper class
Create a class that implements that interface. It's the wrapper for log4j, e.g.:
class Log4jWrapper implements Log {
private static final String FQCN = Log4jWrapper.class.getName();
private ExtendedLoggerWrapper log;
public Log4jWrapper(Class<?> clazz) {
Logger logger = LogManager.getLogger(clazz);
log = new ExtendedLoggerWrapper((ExtendedLogger) logger,
logger.getName(), logger.getMessageFactory());
}
public boolean isInfoEnabled() {
return log.isInfoEnabled();
}
public void info(String str) {
log.logIfEnabled(FQCN, Level.INFO, null, new SimpleMessage(str), null);
}
public void info(String str, Throwable t) {
log.logIfEnabled(FQCN, Level.INFO, null, new SimpleMessage(str), t);
}
}
The LogFactory class.
To create each Log, use a factory. e.g.:
public class LogFactory {
public static Log getLog(Class<?> clazz) {
return new Log4jWrapper(clazz);
}
}
Usage example
Use this factory for each instance of Log into your application. e.g.:
public class Test {
private static final Log LOG = LogFactory.getLog(Test.class);
public static void main(String[] args) {
LOG.info("This is a test... :-)");
}
}
Related
I'm consuming a soap webservice inside a spring boot application. The response/request logging is too big, because of one attribute which is too large. So I want to intercept that logging and remove the offending attribute.
I've been messing about with SoapEnvelopeLoggingInterceptor, but i think that is just for Server side logging. It will not get picked up.
I have configured my soap logging inside yml as follows:
logging:
pattern:
...
level:
...
org.springframework.ws.client.MessageTracing.sent: TRACE
org.springframework.ws.client.MessageTracing.received: TRACE
org.springframework.ws.server.MessageTracing: DEBUG
That works fine for logging both request and response, but I need to remove a very large problematic attribute from the envelope. Any ideas?
You can extend ClientInterceptorAdapter the abstract implementation ClientInterceptors and oveeride handleRequest and handleResponse to parse, modify and log your custom message.
The below code delegates to AbstractLoggingInterceptor handleRequest and handleResponse and overrides the logMessage to create a custom message.
Something like
public class MyInterceptor extend ClientInterceptorAdapter {
private final Logger logger = LoggerFactory.getLogger(MyInterceptor.class);
private EndpointInterceptor endpointInterceptor = new AbstractLoggingInterceptor() {
#Override
protected Source getSource(WebServiceMessage webServiceMessage) {
// Base logic same as SoapEnvelopeLoggingInterceptor getSource method.You can adjust to your preference.
if(webServiceMessage instanceof SoapMessage) {
SoapMessage soapMessage = (SoapMessage)webServiceMessage;
return soapMessage.getEnvelope().getSource();
} else {
return null;
}
}
#Override
protected void logMessage(String message) {
// You can use your regex to remove the attribute and log the message.
this.logger.debug(message);
}
};
#Override
public boolean handleRequest(MessageContext messageContext) throws WebServiceClientException {
return endpointInterceptor.handleRequest(messageContext, null);
}
#Override
public boolean handleResponse(MessageContext messageContext) throws WebServiceClientException {
return endpointInterceptor.handleResponse(messageContext, null);
}
}
There is no simple way of doing that. You ether implement your own Logger by extending sl4j API or wrap log calls and do the transformations there.
The first way will require some efforts because you'll need to implement batch of classes and make sure that the other parts of log system are not broken.
But second part is pretty strait forward.
You have ti create a logger wrapper which implements Logger interface, could be something like this:
public class LoggerWrapper extends MarkerIgnoringBase {
private final Logger logger;
public LoggerWrapper(Logger logger) {
this.logger = logger;
}
private String transformMessage(String input) {
// do all needed regexp transformations here
}
#Override
public void debug(String msg) {
String transformedMessage = transformMessage(msg);
// delegate log call to inner logger
logger.debug(transformedMessage);
}
// implement the rest of the methods here
}
And in the code you might use it like this:
private static final Logger log = new LoggerWrapper(
LoggerFactory.getLogger(SomeClass.class)
);
You can also wrap the logger without implementing Logger interface (in my case it is MarkerIgnoringBase class). In that case you'll not need to implement number of methods from the interface, however you'll louse interchangeability.
The drawback of this solution is that you have to log the messages in advance on your side (not via MessageTracing) but if it is possible I would go this way. On the other hand the first solution does it out of the box.
I am trying to test something like this:
try {
logger.info("message");
//do something
} catch(Exception e) {
logger.error(errorMessage);
}
I know that it's not a good practice to catch an Exception, but there is some legacy code and there is no time for refactoring.
So, I write an unit test so that a NullPointerException will be thrown inside try block, but now I don't know how to write the assert line(obviously, unit test have to fail all the time).
Please notice that I can`t use:
final Logger logger = LogManager.getLogger(AnaliticsService.class);
final Appender mockAppender = mock(Appender.class);
logger.addAppender(mockAppender);
final ArgumentCaptor<LoggingEvent> captor = ArgumentCaptor.forClass(LoggingEvent.class);
Log4jConfigHelper.getInstance().bufferConfiguration();
verify(mockAppender, times(x)).doAppend(captor.capture());
because I don`t know how many messages are logged when UT is running.
You should try to make a Mock for LoggerFactory.
First annotate your TestClass with:
#RunWith(PowerMockRunner.class)
#PrepareForTest({YourController.class, LoggerFactory.class})
Then make a test, which calls needed method and veryfies errors:
#Test
public void testErrorLogging() throws Exception {
mockStatic(LoggerFactory.class);
Logger logger = mock(Logger.class);
when(LoggerFactory.getLogger(any(Class.class))).thenReturn(logger);
YourController controller = new YourController();
controller.someMethod();
verify(logger).error(anyString());
}
Log messages are part of the user interface of your code. Code that does computations should not make assumptions about the manner in which log messages are made available to the user, the text and language of the log messages, or even whether messages are communicated as text (rather than, say, a graphical means). So computational code should delegate to an associated logger class (in the UI/presentation layer) that hides all those details.
If the computational code only requires that the associated logger conforms to an interface, and uses dependency injection for being associated with a logger class, it is easy to mock the logger to examine whether the computational code has requested logging.
So if the code to be tested is like this::
public class MyService
{
private final MyServiceLogger logger;
MyService(MyServiceLogger logger)
{
this.logger = Objects.requireNonNull(logger);
}
public void processFile(Path path) {
...
try{
...
} catch (EOFException e) {
logger.logUnexpectedEOF(path);
}
}
}
public interface MyServiceLogger
{
public logUnexpectedEOF(Path path);
}
public class MyServiceTextLogger implements MyServiceLogger
{
private final Logger textLogger = LogManager.getLogger(MyService.class);;
#Override
public logUnexpectedEOF(Path path) {
textLogger.error("unexpected EOF for file {}",path);
}
}
You can test it like this:
public class MyServiceTest
{
private static class MockMyServiceLogger implements MyServiceLogger
{
private Path path;
private int nCalls_logUnexpectedEOF;
#Override
public logUnexpectedEOF(Path path) {
++nCalls_logUnexpectedEOF;
this.path = path;
}
void assertCalled_logUnexpectedEOF(int nCalls, Path path) {
assertEquals("Called logUnexpectedEOF, nCalls", nCalls, nCalls_logUnexpectedEOF);
assertEquals("Called logUnexpectedEOF, path", path, this.path);
}
}
#Test
public void processFile_unexpectedEOF() {
Path testPath = ...
...
MockMyServiceLogger mockLogger = new MockMyServiceLogger();
MyService service = new MyService(mockLogger);
service.processFile(testPath);
mockLogger.assertCalled_logUnexpectedEOF(1, testPath);
}
#Test
public void processFile_OK() {
Path testPath = ...
...
MockMyServiceLogger mockLogger = new MockMyServiceLogger();
MyService service = new MyService(mockLogger);
service.processFile(testPath);
mockLogger.assertCalled_logUnexpectedEOF(0, null);
}
}
I write an unit test so that a NullPointerException will be thrown inside try block, but now I don't know how to write the assert line(obviously, unit test have to fail all the time).
You don't need to check for an exception this way. A test which throws an Exception fails.
} catch(Exception e) {
logger.error(errorMessage, e);
throw e; // report the error to the test
}
Note: when to throw an error to the testing framework it will log/print it so I suspect you don't need to be catching it in the first place.
As disscussed in this link : How to create a own Appender in log4j?
For creating a custom appender in log4j 1.x we have to extend the AppenderSkeleton class and implements its append method.
Similarly How we can create a custom appender in log4j2 as we dont have AppenderSkelton class to extend and all other appender extend AppenderBase class .
This works quite differently in log4j2 than in log4j-1.2.
In log4j2, you would create a plugin for this. The manual has an explanation with an example for a custom appender here: http://logging.apache.org/log4j/2.x/manual/extending.html#Appenders
It may be convenient to extend org.apache.logging.log4j.core.appender.AbstractAppender, but this is not required.
When you annotate your custom Appender class with #Plugin(name="MyCustomAppender", ...., the plugin name becomes the configuration element name, so a configuration with your custom appender would then look like this:
<Configuration packages="com.yourcompany.yourcustomappenderpackage">
<Appenders>
<MyCustomAppender name="ABC" otherAttribute="...">
...
</Appenders>
<Loggers><Root><AppenderRef ref="ABC" /></Root></Loggers>
</Configuration>
Note that the packages attribute on the configuration is a comma-separated list of all the packages with custom log4j2 plugins. Log4j2 will search these packages in the classpath for classes annotated with #Plugin.
Here is a sample custom appender that prints to the console:
package com.yourcompany.yourcustomappenderpackage;
import java.io.Serializable;
import java.util.concurrent.locks.*;
import org.apache.logging.log4j.core.*;
import org.apache.logging.log4j.core.config.plugins.*;
import org.apache.logging.log4j.core.layout.PatternLayout;
// note: class name need not match the #Plugin name.
#Plugin(name="MyCustomAppender", category="Core", elementType="appender", printObject=true)
public final class MyCustomAppenderImpl extends AbstractAppender {
private final ReadWriteLock rwLock = new ReentrantReadWriteLock();
private final Lock readLock = rwLock.readLock();
protected MyCustomAppenderImpl(String name, Filter filter,
Layout<? extends Serializable> layout, final boolean ignoreExceptions) {
super(name, filter, layout, ignoreExceptions);
}
// The append method is where the appender does the work.
// Given a log event, you are free to do with it what you want.
// This example demonstrates:
// 1. Concurrency: this method may be called by multiple threads concurrently
// 2. How to use layouts
// 3. Error handling
#Override
public void append(LogEvent event) {
readLock.lock();
try {
final byte[] bytes = getLayout().toByteArray(event);
System.out.write(bytes);
} catch (Exception ex) {
if (!ignoreExceptions()) {
throw new AppenderLoggingException(ex);
}
} finally {
readLock.unlock();
}
}
// Your custom appender needs to declare a factory method
// annotated with `#PluginFactory`. Log4j will parse the configuration
// and call this factory method to construct an appender instance with
// the configured attributes.
#PluginFactory
public static MyCustomAppenderImpl createAppender(
#PluginAttribute("name") String name,
#PluginElement("Layout") Layout<? extends Serializable> layout,
#PluginElement("Filter") final Filter filter,
#PluginAttribute("otherAttribute") String otherAttribute) {
if (name == null) {
LOGGER.error("No name provided for MyCustomAppenderImpl");
return null;
}
if (layout == null) {
layout = PatternLayout.createDefaultLayout();
}
return new MyCustomAppenderImpl(name, filter, layout, true);
}
}
For more details on plugins:
http://logging.apache.org/log4j/2.x/manual/plugins.html
If the manual is not enough, it may be useful to look at the source code for the built-in appenders in log4j-core.
As you pointed out AppenderSkeleton is not available anymore so the solutions in How to create my own Appender in log4j? will not work.
Using Mockito, or similar library to create an Appender with an ArgumentCaptor will not work if you're expecting multiple logging messages because the MutableLogEvent is reused over multiple log messages.
The most generic solution I found for log4j2 is to provide a mock implementation that records all the messages. It does not require any additional libraries like Mockito or JMockit.
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.core.LogEvent;
import org.apache.logging.log4j.core.Logger;
import org.apache.logging.log4j.core.appender.AbstractAppender;
private static MockedAppender mockedAppender;
private static Logger logger;
#Before
public void setup() {
mockedAppender.message.clear();
}
/**
* For some reason mvn test will not work if this is #Before, but in eclipse it works! As a
* result, we use #BeforeClass.
*/
#BeforeClass
public static void setupClass() {
mockedAppender = new MockedAppender();
logger = (Logger)LogManager.getLogger(ClassWithLoggingToTest.class);
logger.addAppender(mockedAppender);
logger.setLevel(Level.INFO);
}
#AfterClass
public static void teardown() {
logger.removeAppender(mockedAppender);
}
#Test
public void test() {
// do something that causes logs
for (String e : mockedAppender.message) {
// add asserts for the log messages
}
}
private static class MockedAppender extends AbstractAppender {
List<String> message = new ArrayList<>();
protected MockedAppender() {
super("MockedAppender", null, null);
}
#Override
public void append(LogEvent event) {
message.add(event.getMessage().getFormattedMessage());
}
}
It looks like plugin appenders are scanned at startup and cannot be added during runtime. Is that true?
to add new appender while running you can use monitorInterval property to update log configuration i.e. every 60 sec:
<Configuration monitorInterval="60">
I'm having issues with a few pointcut signatures inside my aspect.
1.. Messages are entering our system via 2 exposed interfaces(IIncoming, IOutgoing) and then they are processed by a PartsManager component like:
PartsManager pmanager = new PartManagerImpl();
pmanager.process(message);
public class PartManagerImpl implements PartsManager{
public boolean process(Message message){
//do some messsage processing..
return true;
}
}
2.. All processed messages are then logged via the following aspect.
#Aspect
public class OldMessageLogging {
private static final Logger LOGGER = Logger.getLogger(OldMessageLogging.class);
#Before("execution(* org.company.PartManagerImpl.process(..))")
public void processMessageCalled(final JoinPoint joinPoint) throws Throwable {
LOGGER.info("Message processed.");
return;
}
}
3.. But, now I want to log processed messages but with one additional information.
Instead of Message processed. I want the log entry to become Incoming message processed. or Outgoing message processed.
4.. So, I have defined two additional interfaces and changed PartManagerImpl.java like this:
public class PartManagerImpl implements PartsManager, IncommingMessageProcessor, OutgoingMessageProcessor {
public boolean process(Message message){
//do some messsage processing..
return true;
}
}
public interface IncommingMessageProcessor {
boolean process(Message message);
}
public interface OutgoingMessageProcessor {
boolean process(Message message);
}
5.. Now, message processing is performed like this:
IncommingMessageProcessor inProcessor = new PartManagerImpl();
inProcessor.process(message);
OutgoingMessageProcessor outProcessor = new PartManagerImpl();
outProcessor.process(message);
6.. A new aspect was created to reflect my new logging needs.
#Aspect
public class NewMessageLogging {
private static final Logger LOGGER = Logger.getLogger(NewMessageLogging.class);
#Before("execution(* org.company.IncommingMessageProcessor.process(..))")
public void processIncomingCalled(final JoinPoint joinPoint) throws Throwable {
LOGGER.info("Incoming message processed.");
return;
}
#Before("execution(* org.company.OutgoingMessageProcessor.process(..))")
public void processOutgoingCalled(final JoinPoint joinPoint) throws Throwable {
LOGGER.info("Outgoing message processed.");
return;
}
}
THE CATCH:
Whenever I'm processing a message like IncommingMessageProcessor inProcessor = new PartManagerImpl(); inProcessor.process(message); the message is being logged twice, once as an incoming and once as an outgoing message.
I have expected only a call to the processIncomingCalled method.
But both of my pointcuts were called!
My pointcut signatures are obviously wrong :/
I tried various approaches but to no avail.
Any suggestions?
SOLUTION
Changing the Message class was not an option in my case, but was an viable solution!
I took a different approach to make code changes minimal.
The method public boolean process(Message message) in both interfaces was renamed to processIncoming(Message message) and processOutgoing(Message message).
public interface IncommingMessageProcessor {
boolean processIncoming(Message message);
}
public interface OutgoingMessageProcessor {
boolean processOutgoing(Message message);
}
PartsManager interface now extends both interfaces class PartsManager extends IncommingMessageProcessor, OutgoingMessageProcessor {...}
And the process(Message message) method is now private but invoked by calls to the inherited methods processIncoming(...) and processOutgoing(...)
so my pointcuts now target calls to that methods.
Altered aspect (changed method names)
#Aspect public class NewMessageLogging {
private static final Logger LOGGER = Logger.getLogger(NewMessageLogging.class);
#Before("execution(* org.company.PartsManager.processIncoming(..))")
public void processIncomingCalled(final JoinPoint joinPoint) throws Throwable {
LOGGER.info("Incoming message processed.");
return;
}
#Before("execution(* org.company.PartsManager.processOutgoing(..))")
public void processOutgoingCalled(final JoinPoint joinPoint) throws Throwable {
LOGGER.info("Outgoing message processed.");
return;
}
}
I assume that incoming messages implement IIncoming and outgoing ones implement IOutgoing. Then you can try:
#Before("execution(* org.company.PartManagerImpl.process(..)) && args(message)")
public void processIncomingCalled(final JoinPoint joinPoint, IIncoming message)
and
#Before("execution(* org.company.PartManagerImpl.process(..)) && args(message)")
public void processOutgoingCalled(final JoinPoint joinPoint, IOutgoing message)
A class implementing two interfaces which both define the same method signature seems very iffy to me and you probably should not do that. If both incoming and outgoing messages are handled by the same message handler (and even the same method) there should only be one interface for the handler. The distinguishing factor should be the messages and their hierarchy/interfaces. That's what the args-part of my suggested pointcut is supposed to check for (I don't have access to a compiler with AspectJ at the moment, so I haven't been able to test it myself yet).
could anybody explain to me, how to set up java Logger for various classes from a concrete package ?
for example:
if I get this one and set it up
Logger logger = Logger.getLogger("com.google.api.client.*");
logger.setLevel(Level.CONFIG);
logger.addHandler(new Handler() {
#Override
public void close() throws SecurityException {
}
#Override
public void flush() {
}
#Override
public void publish(LogRecord record) {
// default ConsoleHandler will take care of >= INFO
if (record.getLevel().intValue() < Level.INFO.intValue()) {
System.out.println(record.getMessage());
}
}
});
there are conditions like this
Logger.getLogger(HttpTransport.class.getName()).isLoggable(Level.CONFIG);
in the library where HttpTransport is part of com.google.api.client.*
But the problem is, that
Logger.getLogger(HttpTransport.class.getName()).isLoggable(Level.CONFIG);
is false ... like if a different logger was obtained
How else should I set it for all classes from the same package? if there are conditions for loggers for concrete classes like HttpTransport.
You do not want the .* in your package string.
Change
Logger logger = Logger.getLogger("com.google.api.client.*");
to
Logger logger = Logger.getLogger("com.google.api.client");