This is my log4j configuration file, whenever I run the batch file to execute the test case, a number of nulls are printed on the console. I have no experience with log4j, but I guess I have not assigned testAppender to ConsoleAppender, then why it is printing on console.
log4j.logger.com.rbs.rmd_test_suite.util.TestSuiteLogger=DEBUG, testAppender
log4j.appender.testAppender=org.apache.log4j.RollingFileAppender
log4j.appender.testAppender.File= ../log/rmd_test_suite_info.log
log4j.appender.testAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.testAppender.layout.ConversionPattern=%m%n
log4j.appender.testAppender.append=true
#Prevent internal log4j DEBUG messages from polluting the output.
log4j.logger.org.apache.log4j.PropertyConfigurator=INFO
log4j.logger.org.apache.log4j.config.PropertySetter=INFO
log4j.logger.org.apache.log4j.FileAppender=INFO
#Disabling logging of external jars
log4j.rootLogger=Off
log4j.logger.org.openqa = OFF
I am using Selenium Web Driver API to automate test cases for an application. Any help is appreciated.
Logging in the file is perfectly fine. Problem is the nulls that are being printed on console.
One possible reason I can think of is, your log4j.properties file is not in the bin folder of your app.
Edited : Got it your rootLogger is OFF
log4j.rootLogger=Off
Instead use
log4j.rootLogger=ALL
log4j.logger.org.openqa=ALL
log4j.rootLogger=ALL, CA
log4j.appender.CA=org.apache.log4j.ConsoleAppender
log4j.appender.CA.layout=org.apache.log4j.PatternLayout
log4j.appender.CA.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n
Related
When i try to execute my Jmeter (version 5.3) recorded script in Non-GUI mode, using a remote server, it displays a "java.lang.NullPointerException" while generating the dashboard(HTML) report. Also, my CSV file (or jtl report) is creating an empty file without any data.
I have used loop controller to call my http request .
I have added sample variables to my jmeter.properties file so that they can be recorded.
Also , I have set "jmeter.save.saveservice.output_format=csv" in properties file.
The summarizer shows 0 and it shows error in generating report: java.lang.nullpointerexception.
Also, my log file shows the following:
Please let me know if there is any possible way to overcome this issue. Thanks in advance!
You're getting this error because you're trying to generate HTML reporting dashboard from an empty .jtl results file
In its turn the .jtl results file is empty because no Samplers were executed
And finally no samplers were executed because all your Thread Groups are disabled
Open your .jmx script in JMeter GUI
Right click each Thread Group
Choose "Enable" from the context menu
Save the test plan
If for some reason you cannot open JMeter GUI just change this line(s) in the .jmx file:
<ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="Thread Group" enabled="false">
to
<ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="Thread Group" enabled="true">
with your favourite text editor or use Taurus tool which can change any property of any element in the runtime
I re-installed jmeter and the same script worked well for me. Cheers!
I am trying to debug a java application using property - System.setProperty("javax.net.debug", "ssl"); in my main class.
I see debug logs in console when I run application using Eclipse during development. However, when I try to run same application using webstart I am not able to see any debug logs in any directory so far.
Is there a specific location where this logs are stored during execution?
I also tried passing debug option to run the jar from command line as java -Djavax.net.debug=ssl -jar xyz.jar but still cannot find logs generated.
Can anyone please help me understand to obtain SSL debug logs for java application?
Thank you.
They aren't stored anywhere. They are printed to System.out or System.err.
In some cases, from command line you can write debug output directly into a file:
java -Djavax.net.debug=all -jar xyz.jar > out.log
I have been trying to omit logs from console while querying in hive, but still it is showing up.
If you are opening the hive console by typing
> hive
in your terminal and then write queries, you can solve this by simply using
> hive -S
This basically means that you are starting hive in silent mode.
Hope that helps.
You could increase the polling interval to minutes or hours:
SET hive.exec.counters.pull.interval=[millis];
The default is 1000 milliseconds, but you can increase it to anything you like. That should decrease the number of logs written to stdout.
If you don't want any logs on the console while starting the shell you can set the hive.root.logger property
$HIVE_HOME/bin/hive --config hive.root.logger=INFO,DRFA
hive.root.logger specifies the logging level as well as the log
destination. Specifying console as the target sends the logs to the
standard error (instead of the log file).
If you want to see ERROR messages on console you can set this command
$HIVE_HOME/bin/hive --config hive.root.logger=ERROR,console
Start hive in silent mode using
$ hive -S
then Set logger level to Error, which will avoid Warnings/Info from printing.
hive> set logger.PerfLogger.level = ERROR;
If there is "SLF4J: Class path contains multiple SLF4J bindings." in your log, it means that there are multiple log4j jars (different versions, different behaviors) in the class path
I don't know the principle of log4j, but according to the Hadoop configuration file, perform the following steps:
cd $HIVE_HOME/conf
cat > log4j.properties <<EOL
log4j.rootLogger=WARN, CA
log4j.appender.CA=org.apache.log4j.ConsoleAppender
log4j.appender.CA.layout=org.apache.log4j.PatternLayout
log4j.appender.CA.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n
EOL
After starting hive (Hive 3.1.2 Apache), the log is set to WARN level, which may not necessarily work, but you can try it.
Stderr and stdout messages appear in the same console log in IntelliJ IDEA (typically in black and in red). Is there a simple way to suppress either stderr or stdout messages or redirect the two different streams to different console windows?
How I deal with this situation is to redirect stdout to a file, such as stdout.log, when system begins.
Then Configuring IDEA's Run/Debug Configurations - Logs to add a log file that locate stdout.log
Thus, you can get stdin at console you just created and stderr at old output.
There is this plugin called Grep Console which allows you to use regex agasint the console outputs. Thus, it is possible to filter the outputs per your needs.
Below is the code i used to generate the log files using log4j and then roll it based on size. Files are getting generated, however the files are not rolling over based on Max File size. I heard in one post that we have to use apache-log4j-extras and am using apache-log4j-extras-1.2.17. I tried to roll over once 50KB has been reached, but its not rolling over. Can someone please let me know what could have gone wrong?
Am using log4j-1.2.17 and apache-log4j-extras-1.2.17 version of jar.
log4j.appender.Flows=org.apache.log4j.RollingFileAppender
log4j.appender.Flows.File=E:/Logs/Flows.log
log4j.appender.Flows.MaxFileSize=50KB
log4j.appender.Flows.MaxBackupIndex=2
log4j.appender.Flows.layout=org.apache.log4j.PatternLayout
log4j.appender.Flows.layout.ConversionPattern=%d %-5p - %c %x %m%n
If you are using Apache Extras™ for Apache log4j™, you may want to use org.apache.log4j.rolling.RollingFileAppender:
log4j.appender.Flows=org.apache.log4j.rolling.RollingFileAppender
log4j.appender.Flows.rollingPolicy=org.apache.log4j.rolling.FixedWindowRollingPolicy
log4j.appender.Flows.rollingPolicy.maxIndex=2
log4j.appender.Flows.triggeringPolicy=org.apache.log4j.rolling.SizeBasedTriggeringPolicy
log4j.appender.Flows.triggeringPolicy.MaxFileSize=51200
log4j.appender.Flows.rollingPolicy.FileNamePattern=E:/Logs/Flows-%i.log
log4j.appender.Flows.rollingPolicy.ActiveFileName=E:/Logs/Flows.log
log4j.appender.Flows.layout=org.apache.log4j.PatternLayout
log4j.appender.Flows.layout.ConversionPattern=%d %-5p - %c %x %m%n
The problem appears to be caused by having the log4j*.jar in multiple levels of the class loader.
E.g. once provided by Tomcat and a second time provided by a web app directly. Removing log4j from our WAR in a Tomcat installation solved the problem for us.
Doing so, we could avoid the use of log4j extras.