I have a project which depends on hadoop-core.
hadoop-core has its own log4j configuration.
The default log4j configuration is loaded in my project.
I want my project not to be affected by it.
How do I solve this?
If you do not want the hadoop-core provided log4j configuration to be the one used by log4j you have to provide another configuration file that should be used.
You should have a look at the log4j manual. The section "Default Initialization Procedure" describes how log4j will try to find the initialization file and explains possibilities to match a special configuration (e.g. by setting the system property log4j.configuration).
Related
I have a web application deployed on WildFly 10. After adding a new Maven dependency to my application, logging stopped working. Investigating, I've found that the new dependency includes a log4j.properties in its JAR, and I guess this is causing the logging to screw up.
I cannot delete the file from the JAR, since every time my project compiles it would come back. I need WildFly to manage the logging properties, so adding an additional log4j.properties isn't an option (it would be if it can be configured to fallback to WildFly defaults, but I don't know if this is possibile).
How can I ignore a dependency's log4j.properties or override it with WildFly's settings?
If your app does not use is own log4j properties file or xml, you are best just disabling the per-deployment logging configuration option on wildfly, then any will be ignored
You can exclude Logging module from you jar.
dependencies {
compile group : 'com.chapter1' name: 'common.all', version: '1.0.001'{
exclude( // here u can exclude that module... )
}
In WildFly 10 you can set the use-deployment-logging-config on the logging subsystem to false which will skip processing any logging configuration files. Do note this will skip processing on all deployments.
I'm having a problem properly setting up spring boot for my multi-module maven project.
There is a module "api" that uses another module "core". Api has an application.properties file that contains spring.mail.host=xxx. According to the spring boot documentation this provides you with a default implementation of the JavaMailSender interface, ready to be autowired.
However the class that is responsible for sending out the e-mails resides in the "core" package. When I try to build that module the build fails because no implementation of JavaMailSender can be found.
My guess then was that the mailing config should reside in "core" in a separate application.properties. I created that and moved the spring.mail.host property from the "api" to the "core" property file.
This time the core module builds successfully, but "api" fails to build because of the same exception, so I think I just moved the problem.
I don't understand the required structure for handling this type of situations well enough so I was wondering what the correct way is for having a "core" module containing all the correct configuration for sending mails and having other modules use the mailing code and config that resides in it.
I found the answer in another stack overflow question: How to add multiple application.properties files in spring-boot?
It turns out there can only be 1 application.properties file in the final jar that spring boot creates. To have multiple files you have to rename one of the files to something custom. I named the properties of the core module "core-application.properties".
Then in the API module I added this to the spring boot application class:
#SpringBootApplication
#PropertySource(value = {"core-application.properties", "application.properties"})
Doing this I can correctly use the base properties file and overwrite them in the more specific modules. Also you can still create profile-specific properties file (core-application-production.properties) with this setup, no need to add those to the propertysource manually). Note that #PropertySource does not work for yaml configuration files at this moment.
there is one effective application.properties per project. you just keep 2 properties file for a success build.
when api module use core module, the application.properties in core module is overwrite by api.
Your API's pom.xml must has dependency of CORE module.
the solution is to define properties files as a value of #PropertiesSource in Starter class.
but it is beter to put "classpath:" behind the properties files.
for example in Intellij idea after adding the "classpatch:" word berhind the files name, values become to link. like this:
#SpringBootApplication
#PropertySource(value = {"classpath:core-application.properties", "classpath:application.properties"})
I hope to helped you.
I have configuration the logback with specified custom logback.xml file, but the log it prints is not what I want.
This is my code to initial logback:
private void initLogBack() throws JoranException {
JoranConfigurator configurator = new JoranConfigurator();
configurator.setContext(createLogbackContext());
configurator.doConfigure(mycustomLogbackConf);
}
I think it may read some unexpected "logback.xml" files from somewhere I don't know. Is there any way to print all the configuration information that logback used?
e.g.
The configuration files it uses
The loggers defined
The debug levels defined
Is it possible?
logback 1.0.4 version has a fix with which you can set debug level at jvm level by using a property
-Dlogback.debug=true
Reference: http://jira.qos.ch/browse/LOGBACK-527
Hope it helps.
I'm sure this is easy, but I'm failing to find it.
I have a org.apache.commons.logging.Log instance for logging, and I see that the source code of one of my dependencies has statements like:
if (logger.isDebugEnabled())
logger.debug("Doing stuff.");
I would like to enable debugging, so that I could see these messages. I'm using Maven to build, and run tests. I don't particularly care whether the solution is a command-line argument, adding something to pom.xml, or using code to set the logger itself.
In your log4j.properties specify log4j.logger.com.yourpackage=debug. If you don't have a log4j.properties, get a default one (google it) and place it on the root of your classpath.
(commons-logging will delegate to log4j)
org.apache.commons.logging.Log is not a logging framework. It is an abstract interface which helps you to have any concrete logging implementation under it.
There is a good chance that you are using log4j underneath the org.apache.commons.logging.Log api . If that is the case then place a log4j.properties at the root of your classpath. If you already have one then you just need to change the log level as specified in the file .
If you are using any other logger like jdk logger you need to find the logging configuration file for the same.
Specifically, I use spring only for configuring my project through ApplicationContext. In my spring xml I load some bean properties through PropertyPlaceholderConfigurer. Whenever in the dependencies I swap commons-logging-x.x with jcl-slf4j.jar the loading of the context fails with ClassNotFoundExceptions on the placeholder substitutions. Example:
In my spring.xml there is:
<bean id="testbean" class="${testbean.implementingClass}"/>
where testbean.implementingClass is defined in spring.properties:
testbean.implementingClass=my.implementation.TestClass
If I run the project using commons-logging jar all works perfectly. If I change it to jcl-slf4j then I get ClassNotFoundException that the class [${testbean.implementingClass}] was not found, i.e. it does not do the placeholder substituion. Has anyone observed this?
EDIT: My problem doesnt have to do with the jars because:
From http://www.slf4j.org/legacy.html :
Our JCL over SLF4J implementation will allow you to migrate to SLF4J gradually, especially if some of the libraries your software depends on continue to use JCL for the foreseeable future. You can immediately enjoy the benefits of SLF4J's reliability and preserve backward compatibility at the same time. Just replace commons-logging.jar with jcl-over-slf4j.jar. Subsequently, the selection of the underlying logging framework will be done by SLF4J instead of JCL but without the class loader headaches plaguing JCL. The underlying logging framework can be any of the frameworks supported by SLF4J. Often times, replacing commons-logging.jar with jcl-over-slf4j.jar will immediately and permanently solve class loader issues related to commons logging.
When you use jcl-slf4j, you have to make sure you have excluded all commons-logging dependencies from your project. Make sure there is no commons-logging jar anywhere in the classpath.