My application is using Spring to handle the interaction with database (Sql Server)
And commons-logging-1.1.1.jar, log4j-1.2.17.jar, slf4j-api-1.6.3.jar and slf4j-log4j12-1.7.6.jar are put into build path for the logging framework of the application.
The last two logging jar (slf4j-api and slf4j-log4j12) are for another component inside the application to use log4j.
Here is my questions:
When Spring-Jdbc runtime excecption happens, the exception is only showed in the console of eclipse with the font color red. The exception is NOT logged into the log file. But the normal log (like log.info(...)) are all in the log file. Why can't the run-time exception be in the log file and how to solve this problem.
When I use SimpleJdbcCall to call the stored procedure with parameters in MapSqlParameterSource, the following log shows up:
14:43:30 [INFO ] Added default SqlReturnUpdateCount parameter named #update-count-1
14:43:30 [INFO ] Added default SqlReturnUpdateCount parameter named #update-count-1
......
It's really annoying because the number of this message is so large. I want to turn off this particular log message without affecting another logging with the same level (INFO)
And my log4j.xml is fine I think because the logging are basically fine except the above issues.
Spring is using commons-logging internally that's why you can see the messages in your eclipse console. To redirect commons-logging to slf4j/log4j you need to remove commons-logging-1.1.1.jar from your classpath and add jcl-over-slf4j.jar from your slf4j version. To get rid of the dublicate red eclipse messages (jul and jcl) you can set the logging level in logging.properties for the console handler to warning:
java.util.logging.ConsoleHandler.level = WARNING
Second issue was solved here.
Related
I got a pecurliar behaviour when we stop a war in Weblogic 12c and then start it again. For some reason beyond my understanding Log4j2 stops writing to the log. It creates a new logfile but no entries are written.
I have debugged and sees that Log4jServletContainerInitializer and Log4jServletContextListener gets called just like they do when installing the war. I didn't notice any differences (unfortunally thats only a test of my attention span).
So do you have any idea of what might differ between install and start in regards of Log4J2 in Weblogic 12c and perhaps where to look for errors?
Your problem:
For some reason beyond my understanding Log4j2 stops writing to the log. It creates a new logfile but no entries are written.
Root Cause Analysis:
It is actually happen for some issues.
If your configuration for log4j is not correctly done in
log4j.properties file.
If your append properties are not made true.
If you use two loggers like Log4J and JUL, which uses the same
appneder(Stdout).
If your log4j jar file is not properly set to your classpath.
Solution:
Ans-1:
In your classpath, there is a setting of library that intercepts Log4J calls and converts them to JUL calls. Then it may cause this issue. So specify correctly that which importing is actually needed. java.util.logging.Logger or org.apache.log4j.Logger
Ans-2:
Properties are case sensitive. so your file name would be same with appender. and don't forget to make the appender to true.
log4j.appender.mainAppender.File=yourLogFile.log
log4j.appender.mainAppender.Append=true
Ans-3:
for Hibernate in particular, include slf4j in order to ensure that all the loggers co-operate with it.
Ans-4:
Sometimes this problem occurs for tomcat. If tomcat security enabled, and there were several permissions missing from the policy files, then this type of issue occurs. After giving permissions, it will work fine.
What Log4J does actually?
Log4J will only print messages which are info and up, and it will print them to both console and file. You can change this behaviour by changing INFO to ALL in log4j.rootLogger. If that doesn't work, add -Dlog4j.debug=true to your JVM arguments - that will make Log4J emit debug messages about itself (to System.out), so you can see what's going on.
Credit goes to #Isaac
Resource Link:
Log4J creates log file but does not write to it
Issue with log4j log not writing to file
UPDATE for log4j2:
Thanks a lot to rgoers for pointing the issue for log4j2. I am updating.
Root cause analysis from P.O.V of wilkinsona
When a restart is triggered, DevTools runs and then clears all registered shutdown hooks. One such hook is Log4J2's DefaultShutdownCallbackRegistry. Log4jContextFactory maintains a reference to the DefaultShutdownCallbackRegistry and LogManager holds a static reference to Log4jContextFactory. Log4J2's classes are loaded by the app classloader which means that there's a single LogManager, Log4jContextFactory, and DefaultShutdownCallbackRegistry shared across restarts.
When DefaultShutdownCallbackRegistry is run as part of a restart it stops the LoggerContext and sets its own state to STOPPED. As the restart proceeds a new LoggerContext is created and an attempt is made to register a shutdown callback for it with the registry. This fails as the registry's state is still STOPPED.
Solution:
Wilkinsona offered a hack method to solve the issue. That is given below. Try to cope with it.
Clearing out the callbacks in the registry before the Restarter runs the JVM's shutdown hooks is better. It prevents the exception from occurring, and logging continues to work after a restart.
private void prepareLog4J2ForRestart() throws Exception {
if (ClassUtils.isPresent("org.apache.logging.log4j.LogManager",
getClass().getClassLoader())) {
LoggerContextFactory factory = LogManager.getFactory();
Field field = ReflectionUtils.findField(factory.getClass(),
"shutdownCallbackRegistry");
ReflectionUtils.makeAccessible(field);
ShutdownCallbackRegistry shutdownCallbackRegistry = (ShutdownCallbackRegistry) ReflectionUtils
.getField(field, factory);
Field hooksField = ReflectionUtils
.findField(shutdownCallbackRegistry.getClass(), "hooks");
ReflectionUtils.makeAccessible(hooksField);
#SuppressWarnings("unchecked")
Collection<Cancellable> state = (Collection<Cancellable>) ReflectionUtils
.getField(hooksField, shutdownCallbackRegistry);
state.clear();
}
}
Resource Link:
Log4j 2.4 breaks rc1 devtools
Call context.close() rather than shutdown hook in DevTools restart
UPDATE2:
What kind of listener to add to my JEE application, to get the
expected behaviour?
For writing a listener, you can follow the tutorials
ServletContextListener Example
Writing a Listener Class
Servlet Listener Example – ServletContextListener,
HttpSessionListener and ServletRequestListener
Following are the requirements,
multiple modules deployed on JBoss AS 7 with individual logging configuration using logback.xml.
all of them request exclusion of default logging-service provided by the Server, using jboss-deployment-structure.xml.
Following are observation,
log.debug statements get printed as INFO on Server log(server.log)
it's because root level of custom-logger(logback.xml) is set to DEBUG
Now questions,
How can I make, DEBUG statements generated by custom logging statement gets printed with appropriate log level?
Conversely, is it possible to get log level of Server without using it's logging service?
In other words, is it possible to achieve uniform log-level configuration across multiple modules that use custom-loggers?
I have an application which is configured on IBM WebSphere 6.0 version.
In that application, where ever the System.out.printlN() Statements, are there
Where do they get printed?
I mean which log files, will get it printed?
In standalone I can check in the console, that application is deployed in windows server box
How to Identify where all the log.debug, log.info statements get printed from the application into the server box.
I tried checking in log4j.properties, but didnot find any useful info about that.
Background, we have a Websphere app server, where we have configured 2 Nodes and I am deploying in the Node 01, on my changes and trying to debug, but no help.
Please guide if any one has past exp on it.
I haven't been using WebSphere 6 lately. I newer versions you have a profile directory and a log directory within where the log file reside.
The second option is to go into the WAS administration console and go to "Troubleshooting > Logs and Trace > server_name " there you can directly view the logs. This way is documented for WAS 6.0 as well.
As others have hinted, by default the SystemOut.log and SystemErr.log files are located in each node's profiles/<profileName>/<serverName>/logs directory. (These locations and file names can be overridden in the Administration Console.)
log4j logs will depend on the appenders in your log4j configuration (could be a log4j.properties or a log4j.xml file), but might also be affected by whether anything in your application uses Jakarta Commons Logging. If it does, you may find all log4j logging also going to SystemOut.log.
It should get logged in Program files/IBM/SDP/profiles/runtimes/baseV6...
something like this .currently am at home and I don't have exact path.But search in profile directory .
You should always define your own path for appenders in your applications logging.xml instead of using default path of WAS.
The log files are resided at C:\Program Files\IBM\SDP\runtimes\base_v7\profiles\was70profile1\logs\server1
I'm running into a weird problem. I have a class that used to use Log4j, and I could do something like:
LOGGER.log(Level.SEVERE, "This is a message");
And I'd get output like this:
SEVERE: This is a message
I replaced it with an SLF4J logger for consistency with the rest of the application:
LOGGER.error("This is a message.");
But now it's logging at INFO level:
INFO: 2012-01-23 16:50:43,306 [http-thread-pool-8080(3)] ERROR com.mycompany.MyClass - This is a message
I was expecting this to be logged at ERROR level (SLF4J doesn't seem to have any levels above that).
Any idea what's going on? Is this the default? The application is fairly complicated, so I wouldn't be surprised if this was changed somewhere, but where would I find that to change it back?
I'm using Glassfish, in case that might be related.
you need to make your SLF4J use the Java Util Logging backend. That's what Glassfish uses internally. Since it's not using that, it's dumping to the console, and GF reports everything on the console as INFO.
So hook up the JUL adapter and you should be all good.
without configuration listing for logging it's only a guess. but I think the logging framework is probably misconfigured. slf4j logs at ERROR level:
ERROR com.mycompany.MyClass - This is a message
then this output is sent into console, which is redirected into general log file at INFO level by glassfish.
previous setup probably used glassfish logging directly inheriting its configuration. after switching to slf4j no config was found so everything is sent to console and then to server.log
I have a server I made in Java that needs to use a database, I chose HSQLDB.
So I have a lot of entries in my server like:
Logger.getLogger(getClass().getName()). severe or info ("Some important information");
When I run my server it goes to System.out which I think its the default configuration of java.util.logging?, so far its ok for me, and later I will make it go to a file ...
But, the problem is, when I start hsqldb it messes up with the default configuration and I can´t read my log entries on System.out anymore..
I already tried to change hsqldb.log_data=false, but it still messes up the default configuration.
Can someone help me??
I dont want to log hsqldb events, just my server ones.
Thanks
This issue was reported and fixed in the latest version 2.2.0 released today.
Basically, you set a system property hsqldb.reconfig_logging to the
string value false.
A system property is normally set with the -D option in the Java startup command for your application:
java -Dhsqldb.reconfig_logging=false ....
See below for details of the change:
http://sourceforge.net/tracker/?func=detail&aid=3195462&group_id=23316&atid=378131
In addition, when you use a fremework logger for your application, you should configure it directly to choose which levels of log to accept and which ones to ignore.
The hsqldb.applog setting does not affect framework logging and only controls the file log.
The hsqldb.log_data=false is for turning off internal data change logging and should not be used for normal databases. Its usage for bulk imports is explained in the Guide.
Try setting hsqldb.applog to 0, that shuts off application logging to the *.app.log file.
Start your server with a property pointing to the location of a dedicated properties file:
-Djava.util.logging.config.file=/location/of/your/hsqldblog.properties"
Which contains the following line to change Java logging for Hsqldb.
# Change hsqldb logging level
org.hsqldb.persist = WARNING
Side note, you can choose from the following levels:
SEVERE WARNING INFO CONFIG FINE FINER FINEST