I have some trouble getting rid of debug messages generated by Spring (similiar to the following ones; there are thousands of those entries):
19:58:08.380 [main] DEBUG o.s.b.f.s.DefaultListableBeanFactory - Creating shared instance of singleton bean 'propertyPlaceholderConfigurer'
19:58:08.380 [main] DEBUG o.s.b.f.s.DefaultListableBeanFactory - Creating instance of bean 'propertyPlaceholderConfigurer'
19:58:08.383 [main] DEBUG o.s.b.f.s.DefaultListableBeanFactory - Creating shared instance of singleton bean 'appConfig'
19:58:08.383 [main] DEBUG o.s.b.f.s.DefaultListableBeanFactory - Creating instance of bean 'appConfig'
19:58:08.383 [main] DEBUG o.s.b.f.s.DefaultListableBeanFactory - Eagerly caching bean 'appConfig' to allow for resolving potential circular references
19:58:08.384 [main] DEBUG o.s.b.f.s.DefaultListableBeanFactory - Finished creating instance of bean 'appConfig'
In related questions, there were many suggestions involving log4j, web.xml, ....
However, I am not using any of those - I simply instantiate an AnnotationConfigApplicationContext and start creating beans.
In my pom.xml file, there are no references to any logging framework - I only include the spring dependencies:
<!-- Spring and Transactions -->
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>${spring-framework.version}</version>
</dependency>
<!-- ... -->
<artifactId>spring-tx</artifactId>
<!-- ... -->
<artifactId>spring-boot-starter</artifactId>
<!-- ... -->
<artifactId>spring-web</artifactId>
<!-- ... -->
I read somewhere that Spring seems to use "Commons logging" by default, which I unsuccessfully tried to disable using (as shown in Turn Off Apache Common Logging ):
System.setProperty("org.apache.commons.logging.Log", "org.apache.commons.logging.impl.NoOpLog");
In addition, I tried to exclude the commons logging in my pom.xml by adding:
<exclusions>
<!-- Exclude Commons Logging in favor of SLF4j -->
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
Still no luck, however.
Next, I tried including a dependency to log4j, hoping this would override the default logging. As the format of the messages stayed the same, it seems that this attempt was also not successfull.
What could I try next?
First: Is slf4j on classpath?
SLF4J is another log abstraction for Java, which also could be used together with Spring framework. Many libraries / products have switched to slf4j.
Are there any dependencies with 'slf4j' in its name? Try mvn dependency:tree -Dverbose=true, and look if slf4j appears. If so, look at slf4j website for more information about its setup.
Second: which log4j config file is used?
Hint to detect if log4j is used, and if a log4j config file is somewhere on the classpath:
Try to set property log4j.debug to 'true'.
When using mvn exec:java, simply add -Dlog4j.debug=true to command line.
If this is a Junit test with the maven surefire plugin, try set systemProperties in Surefire plugin itself: http://maven.apache.org/surefire/maven-surefire-plugin/examples/system-properties.html
Related
In a Spring MVC server I have this warning every time I use docx4j to generate a docx. The server functions well, but I have a huge log with this warning
2022-04-27 18:00:46.241 [http-nio-8080-exec-3] WARN org.docx4j.XmlUtils - default SAXParserFactory property : null
Please consider using Xerces.
2022-04-27 18:00:46.248 [http-nio-8080-exec-3] WARN org.docx4j.XmlUtils - default DocumentBuilderFactory property: null
Please consider using Xerces.
My pom.xml is:
<!-- Doc4j -->
<dependency>
<groupId>org.docx4j</groupId>
<artifactId>docx4j-JAXB-ReferenceImpl</artifactId>
<version>8.3.4</version>
</dependency>
<dependency>
<groupId>org.docx4j</groupId>
<artifactId>docx4j-core</artifactId>
<version>8.3.4</version>
</dependency>
<dependency>
<groupId>org.docx4j</groupId>
<artifactId>docx4j-export-fo</artifactId>
<version>8.3.4</version>
</dependency>
<dependency>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
<version>2.12.2</version>
</dependency>
What am I missing?
If you get ...
[main] WARN org.docx4j.XmlUtils - default SAXParserFactory property : null
Please consider using Xerces.
[main] WARN org.docx4j.XmlUtils - default DocumentBuilderFactory property: null
Please consider using Xerces.
... you need xerces on the CP and you need to set the property in docx4j.properties for sax parser to xerces
From docx4j.properties [JAXP factories] section uncomment ... [javax.xml.parsers.SAXParserFactory=com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl]
*** NOTE you will have a different package name for SaxParserFactoryImpl based on the version of xerces
The version of docx4j will have the dependencies needed to be on the CP in /dependencies
if you get ...
[main] WARN org.docx4j.utils.ResourceUtils - Couldn't get resource: docx4j.properties
[main] WARN org.docx4j.Docx4jProperties - Couldn't find/read docx4j.properties; docx4j.properties not found via classloader.
... you have not deployed docx4j.properties - docx4j has defaults, so you first need to deploy docx4j.properties before you can affect those defaults
you need to create (or copy from source ~/resources/) [docx4j.properties]
org.docx4j.Docx4jProperties.java loads docx4j.properties on init() to overwrite the defaults
I have to use spring-boot-devtools & axon in spring-boot application. I have included both of them in pom.xml. It is not working. Application fails to start.
I have tried to run application without using spring-boot-devtools then it works perfectly as expected but not with spring-boot-devtools. I have read document of axon on https://docs.axoniq.io/reference-guide/setting-up/spring-boot where it is suggested not to use devtools with axon. I also refereed issue https://github.com/AxonFramework/AxonFramework/issues/976 where it is stated, removing the devtools dependency did the trick. I don't want to remove devtools as it is useful in development mode. Pom.xml content:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.axonframework</groupId>
<artifactId>axon-spring-boot-starter</artifactId>
<version>4.0.3</version>
</dependency>
I expect application to start but got error :
Description:
The bean 'commandBus', defined in class path resource [org/axonframework/springboot/autoconfig/AxonAutoConfiguration.class], could not be registered. A bean with that name has already been defined in class path resource [org/axonframework/springboot/autoconfig/AxonServerAutoConfiguration.class] and overriding is disabled.
Action:
Consider renaming one of the beans or enabling overriding by setting spring.main.allow-bean-definition-overriding=true
I have tried spring.main.allow-bean-definition-overriding=true but not working.
When I run .war file in tomcat, the logs show
ERROR [com.configleon.configurer.WebPropertyConfigurer] - The 'configLocation' variable is not specified in the JVM settings!
ERROR [org.springframework.web.context.ContextLoader] - Context initialization failed
And this my code :
<!-- configlion property configurator -->
<bean class="com.configleon.configurer.WebPropertyConfigurer">
<property name="propertyResources">
<bean class="com.configleon.resource.WebPropertyResources"/>
</property>
</bean>
Anyone can help me please ?
for first one ERROR [com.configleon.configurer.WebPropertyConfigurer]
see the here
and for second one
ERROR [org.springframework.web.context.ContextLoader] - Context initialization failed
in deployment environment, just make sure your server classpath has included the Spring jar library (e.g spring-2.5.6.jar).
For Spring3, ContextLoaderListener is moved to spring-web.jar, you can get the library from Maven central repository.
Markup
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
<version>3.0.5.RELEASE</version>
</dependency>
After adding quartz-scheduler to a project, Tomcat's server log is being spammed with the following message:
[INFO] [talledLocalContainer] 12:15:06.319
[DefaultQuartzScheduler_QuartzSchedulerThread] DEBUG
o.quartz.core.QuartzSchedulerThread - batch acquisition of 0 triggers
I'm trying to disable that log message, which repeats every 25-seconds or so. I've been through a number of other answers to this same question, such as:
Disable quartz logging
stop quartz debug logging log4j
Disabling Log4J Output in Java
...and none of the approaches suggested are working.
I have the following dependencies declared in pom.xml:
<dependency>
<groupId>org.quartz-scheduler</groupId>
<artifactId>quartz</artifactId>
<version>2.2.1</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.5</version>
</dependency>
And I've added the following log4j.properties settings to my project:
log4j.rootLogger=OFF
log4j.logger.quartz=OFF
log4j.logger.o.quartz=OFF
log4j.logger.org.quartz=OFF
...and also the following simplelogger.properties:
org.slf4j.simpleLogger.defaultLogLevel=error
In addition to attempting the programmatic solution suggested on one of the linked answers, which should disable all logging and goes roughly like:
List<Logger> loggers = Collections.<Logger>list(LogManager.getCurrentLoggers());
loggers.add(LogManager.getRootLogger());
for ( Logger logger : loggers ) {
logger.setLevel(Level.OFF);
}
That seems to disable everything except the log message from quartz when it runs.
Is there a way to get rid of the log message from quartz, short of modifying the quartz source-code to remove it?
The logging entry above doesn't look like Log4J. I think thats ACL or JUL. When you are using Slf4j to Log4J, you also need to redirect these frameworks to Slf4j. Add these dependencies to your project as well:
<!--Redirect Apache Commons Logging to Slf4J -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>1.7.5</version>
</dependency>
<!--Redirect Java Util Logging to Slf4J -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jul-to-slf4j</artifactId>
<version>1.7.5</version>
</dependency>
Read this doc page about redirecting Jul to Slf4J, too. Be sure to exclude any existing commons-logging.jar files from your project, through Maven.
(From the Slf4J documentation page)
And if all else fails, try the following code:
//see if we can find the offending logger through slf4j's LoggerFactory
org.slf4j.Logger logger =
LoggerFactory.getLogger(Class.forName("org.quartz.core.QuartzSchedulerThread"));
if (logger != null && logger instanceof ch.qos.logback.classic.Logger) {
//the slf4j Logger interface doesn't expose any configuration API's, but
//we can cast to a class that does; so cast it and disable the logger
((ch.qos.logback.classic.Logger)logger).setLevel(
ch.qos.logback.classic.Level.OFF);
}
Is it possible to have a typical call to java.util.logging.Logger and have it route to Logback using SLF4J? This would be nice since I wouldn't have to refactor the old jul code line by line.
EG, say we have this line:
private static Logger logger = Logger.getLogger(MahClass.class.getName());
//...
logger.info("blah blah blah");
It would be nice to configure this to call through SLF4J.
It's very easy and not a performance issue anymore.
There are two ways documented in the SLF4J manual. There are also precise examples in the Javadocs
Add jul-to-slf4j.jar to your classpath. Or through maven dependency:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jul-to-slf4j</artifactId>
<version>1.7.0</version>
</dependency>
If you don't have logging.properties (for java.util.logging), add this to your bootstrap code:
SLF4JBridgeHandler.removeHandlersForRootLogger();
SLF4JBridgeHandler.install();
If you have logging.properties (and want to keep it), add this to it:
handlers = org.slf4j.bridge.SLF4JBridgeHandler
In order to avoid performance penalty, add this contextListener to logback.xml (as of logback version 0.9.25):
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<contextListener class="ch.qos.logback.classic.jul.LevelChangePropagator">
<!-- reset all previous level configurations of all j.u.l. loggers -->
<resetJUL>true</resetJUL>
</contextListener>
...
</configuration>