You’re missing the log4j.properties or log4j.xml in your classpath. You can bypass this by using BasicConfigurator.configure(); But beware this will ONLY log to System.out and is not recommended. You should really use one of the files above and write to a log file. A very simple example of log4j.properties would be #Log to Console as … Read more
Typically, you’d have loggers setup per class because that’s a nice logical component. Threads are already part of the log messages (if your filter displays them) so slicing loggers that way is probably redundant. Regarding application or layer based loggers, the problem is that you have to find a place to stick that Logger object. … Read more
If that’s the entire log4j.properties file it looks like you’re never actually creating a logger. You need a line like: log4j.rootLogger=debug,A1
It finds the log4j.xml using the CLASSPATH. If log4j doesn’t find any config file, it will send an error to the console. If you don’t see any such error then it is likely that it is finding a config file which may not be the one you are editing. There is a command-line option to … Read more
Not Exactly related to the Question, But the below are my learning in log4j2 migration. hope it helps someone. Since the log4j vulnerability which was discovered in late 2021, many organizations have upgraded to log4j2 to overcome it. and many developers needed to understand what exactly is log4j and what is the vulnerability. I recommend … Read more
There are two ways to make log4j2 find your custom plugin: through the packages configuration attribute and through a javac-generated plugin dat file. Option 1: the packages attribute There was an old version of log4j2 where the packages attribute no longer worked, but this was fixed in 2.0.1. This should not be an issue any … Read more
Logback has a special appender called SiftingAppender which provides a very nice solution to the type of problems you describe. A SiftingAppender can be used to separate (or sift) logging according to any runtime attribute, including thread id.
If you create a static Logger within MyLogger class, then you have one Logger instance, with the name set to MyLogger. When you call that logger from other packages, Log4j is not able to determine the origin of those calls, as they all use the same Logger. The best way to handle it, is to … Read more
Spring makes it really easy for us to make use of AOP. Here’s a simple logging example: @Aspect public class MyLogger { private Logger log = Logger.getLogger(getClass()); @After(“execution(* com.example.web.HomeController.*(..))”) public void log(JoinPoint point) { log.info(point.getSignature().getName() + ” called…”); } } Then simply configure your applicationContext.xml (or equivalent): <aop:aspectj-autoproxy> <aop:include name=”myLogger”/> </aop:aspectj-autoproxy> <bean id=”myLogger” class=”com.example.aspect.MyLogger”/> You’ll … Read more
You can use profiles to achieve the desired behavior: <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-resources-plugin</artifactId> <version>2.5</version> <executions> <execution> <id>log4j</id> <phase>process-resources</phase> <goals> <goal>copy-resources</goal> </goals> <configuration> <outputDirectory>output_directory</outputDirectory> <resources> <resource>${log4j.file}</resource> </resources> </configuration> </execution> </executions> </plugin> </plugins> </build> <profiles> <profile> <id>dev</id> <activation> <activeByDefault>true</activeByDefault> </activation> <properties> <log4j.file>path_to_file_A</log4j.file> </properties> </profile> <profile> <id>prod</id> <properties> <log4j.file>path_to_file_B</log4j.file> </properties> </profile> </profiles>