Develop Reference

Logs are not populating with Log4j 2.17.2

We have older java code which was using log4j 1.17 and application logs were writing to log file properly. As part of vulnerability fixing we have to migrate to log4j 2.17.2 (Mandatory as part of compliance). We have followed the migration plan as per the Apache blog- https://logging.apache.org/log4j/2.x/manual/migration.html
So, now we have added the reference of log4j-1.2-api-2.17.2.jar, log4j-api-2.17.2.jar and log4j-core-2.17.2.jar files instead of log4j-1.17.
But, with log4j-2.17, no logs are populating in the log file....though application is running and functionalities also working....but no logs in the log file.
As soon as we refer the log4j-1.17, log files are starts populating. I am not able to figure out what is going wrong here.
Below is how the logger was instantiated in old code-
static Logger log = Logger.getLogger(SendApproverDetails.class);
Log4j.Properites files details-
Updated the log4j.properites file with
#PiotrP.Karwasz suggestion. Still no luck-

What is the difference between Java Logger and System.out.println

I looked up the api about the logger class(here) and I was looking at the Logger.info method. I was confused when I saw its perimeter as a message displayed as a string public void info(String msg) which is same as System.out.println(). I am wondering what is the different between these two, and why do we use Logger instead of System.out.println when they can print out the same thing.
In Logger.
Logger.info("Hello")
Output:
[INFO ] 2015-08-07 11:18:46.140 [main] ClassName Hello
In System.out.println
`System.out.println("Hello")
Output:
Hello

Usually, because a Logger can be configured to write to a file (and the console). It might also be configured at higher (or lower) granularity as to messaging. For example, you might configure (at runtime) for level of warn. In which case, that logger would not display debug or info messages. It can include information such as the class that is writing, a line number, and a date and time (of the message).

Using a logger allows you to abstract out a lot of details and do a lot more than you could writing to stdout.
You can specify different destinations to write to. Different appenders write to a file, roll the file for given time periods, write to a queue or database, etc.
You can specify a consistent format for log messages instead of having to add it to every line you write to stdout.
You can choose an appender that buffers the output so that multiple threads can log without having the threads contend for the lock on the console object.
You can do a lot with filtering by category (typically package and classname) and log level (trace, debug, info, error, fatal), to make it easy to configure what log messages you want to see and which you want to ignore. With logging you can change the configuration in the logger properties or include a page in your application to change what gets filtered on the fly.
You can mix and match this stuff, for instance, setting up a specific smtp appender to email log messages for logging level of error or higher, in addition to writing the messages to a rolling file or whatever.

The main difference between a Logger and System.out.println is Logger: Prints the text in a file(text file)System.out.println: Prints the output in console
Logger is useful when you are going for any LIVE projects. Because if any project is developed and deployed, then you cannot check the console. At that time Logger will be useful to track the flow of your project also you can find the Error or Exception if you have given the logger in catch{...} block.
Also go through this Logger vs. System.out.println

But when we use any logging mechanism(log4j, slf4j, logback etc) we
configure appenders and corresponding target log files for each
package. By default console appender is turned off unless you
explicitly configure it to log to a destination.
The System.out.println always logs the message to a console appender.
So, it should be used only when we are sure that the console appender
is configured in the logger configuration file. Otherwise we end up
having logs logged on server console which is incorrect. Any log from
inside the application should go to the corresponding application log
and not the server log.
Let me explain with an example.
If we are building an application called Tracker using a logging mechanism to run in a tomcat container, and we configured appenders for application logging with destination log file as tracker-application.log and we did not configure the console appender.
Then if the System.out.println is encountered by the JVM then the log will go to server log of the tomcat server which is wrong because server log should only have information about the server and not the application.
But if we created a console appender with a target log file then it will be logged properly.
Hope I was clear. ;)
For best practices refer Do not use System.out.println in server side code or http://www.vipan.com/htdocs/log4jhelp.html
For differences between both of them please refer
Logger vs. System.out.println

Get messages.log style logging out of embedded neo4j

How can I maximize the log information an embedded neo4j database will give me, so that I can see what's going on?
Recent technical discussion on the google group called for an excerpt of messages.log, but I don't have that log file since I'm running embedded. I have consulted the server configuration docs (http://docs.neo4j.org/chunked/stable/server-configuration.html#_server_logging_configuration) but they don't tell me the actual names of the loggers to use.
I have tried this:
java.util.logging.Logger.getLogger("org.neo4j").setLevel(Level.ALL)
But by default, and also with this line of code, I see no log messages from neo4j at all.
I'm trying to get some of the server message logs to debug why certain read-only transactions are failing and rollback is failing; first I have to figure out how to get neo4j to tell me what's going on in this embedded database.

Actually you have messages.log it is in your graph.db directory.
And there are loads of diagnostic, config, tuning, memory and other information in that file. So very valuable.

Websphere with Logback logging to system out - formatting issue

I am using Logback in my application hosted on Websphere App Server. Logback is configured to log to System Out (and others are hesitant to change to a different file). The issue is that Websphere uses its own format for logging to System Out. Executing logger.debug("test") in my app yields:
[8/7/12 12:27:55:629 CDT] 0000003a SystemOut O DEBUG com.myapp... test
where everything up to the "O" is added by Websphere. The rest is from Logback
I have set up Logback to use the following pattern: %-5level %logger{36} - %msg%n so that I don't repeat timestamp and thread info which Websphere does on its own, but I am still annoyed that I can't fully customize the logging to System Out from within Logback.
I don't know a whole lot about logging best practices. Before, I have logged to separate files by web app, but for this project, I was told the System Out files are monitored by a third party and I should not change from using System Out. Is there any way to get around my issue given these requirements and tell Websphere not to mess with my System Out logging, or is the only solution to start logging to a different file? Thanks!

Your logback is configured to write messages to System.out. However, everything that is written to System.out is redirected by WebSphere and written to the SystemOut.log file with the same format as log messages produced by WebSphere, but with a severity indicator "O". It is not possible to change that.
Note that it is likely that the people who told you to use SystemOut.log actually meant that you should ensure that logging is done using WebSphere's log system so that messages are written with the correct category and severity and that log levels can be changed at runtime. Since WebSphere's log system is build on java.util.logging you should probably just replace logback by slf4j-jdk14 to satisfy their requirement.

I don't think you're going to be able to change the format. And if you could, it might break the current monitoring anyway.
I wonder if anyone would mind if you log to two loggers at the same time, SystemOut for the existing monitoring, and your own for a more readable format.

The problem is that Logback redirects the messages to console output instead of java.util.logging. Console output has no log levels and that's why WebSphere just writes "O".
We solved this by implementing a Logback appender that redirects logs to JUL (java.util.logging) instead. We convert Logback log levels to JUL levels (e.g. Logback "ERROR" is JUL "SEVERE").
We also wanted to use Websphere's trace options. If trace is enabled for a class/package pattern, you will see Logback DEBUG and TRACE messages in Websphere's trace.log. You can also check if the trace is enabled by calling Logback's isDebugEnabled() / isTraceEnabled().
See this answer with a full implementation:
https://stackoverflow.com/a/74386323/395879

Despite my setting up my own logging.properties, everything still also logs to catalina.out. How to stop?

I am using Tomcat version 5.5.x. My WAR sets its own logging properties successfully and logs to $TOMCAT_HOME/logs/.YYYY-MM-DD.log. Everything that is written to my log is also written to catalina.out. Is there a way to stop the redundant logging to catalina.out stop?

Change your application's logging configuration so it doesn't log anything to the console/standard out. Tomcat redirects standard out to the catalina.out file, so if you see output in catalina.out it implies your application is writing to the console.