To elaborate on that, I have a Tomcat server version 7.0.27 running Java 1.6.0_27.
I have two wars, each with their own log4j jar, also using slf4j with slf4j-log4j. Each war has it's own configuration file (log4j.xml).
war 1 should use file log-1.log and war 2 should use file log-2.log but both are logging into log-1.log.
I've checked there are no other log4j jars in the tomcat installation so I'm not sure where the problem is. I've also turned off shared class loading but that made no difference. My next step is to turn on verbose class loader logging and/or start debugging log4j but maybe someone here knows why this is and can save me some time. Thanks for any input on this.
Update:
Ok think I got this one. The log4j xml files are fine. After doing a verbose:class I can see that log4j.jar is only getting loaded once and from neither web application.
I'm working with Documentum. They have a runtime jar required to use their libraries that is an empty jar with a manifest file. The manifest points to a bunch of jars. In other words, they don't use maven... Anyway ... one of those jars happens to be logj4 found in the Documentum installation. So it seems both webapps are using that one. I think this is the problem. To be confirmed...
If you are placing Documentum's runtime jar on your top-level classpath, and that runtime jar is referencing log4j.jar, then it will only load once. You don't have to use that runtime jar, though, or you can use it in just your Documentum .war, if one is non-Documentum.
You didn't post your properties file but i can think of some reasons:
You don't have an appender that writes to the different files, i.e you need appender1 to write to log1.log and appender2 writing to log2.txt
You have the appenders set up right but both the applications are using the same logger, so they both write to the same file.
You have 2 loggers, each with its own appender, but in your code you are not initializing the correct logger:
//there is no logger called com.sample, so it defaults to root logger that has appender that writes to log1.txt
Logger logger = Logger.getLogger(com.sample.MyClass.class);
If you post your properties file and your logger init code it'll be easier to help you.
Related
I am facing a task to put log4j.properties configuration file to the JBoss server instead of putting this configuration to the project as stated in official JBoss documentation here: https://developer.jboss.org/thread/231514
If I got this right, log4j logger finds configuration within classpath automatically, but what is the way (if there is any) of loading this file from server directory (e.g. wildfly/modules/x/y/log4j.properties)?
You can use -Dlog4j.configuration=file:[path-to-your-external-file] while starting the server.
This is the answer I was looking for.
We are doing a maven project which is using datanucleus which logs with log4j so can't use logback. Where can I put the log4j config file outside the application so that the different VM environments have access to it. How can I get the location of the config file without hard coding the classpath?
You could specify the path in log4j.properties.
log4j.appender.file.File=path_to_log_file
For details, please check this example.
I have one application running in WAS8.
we have a jar - commons-logging-1.1.1.jar in WEB-INF/lib
we have one properties file - commons-logging.properties
the content of the file is
priority=1
org.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.LogFactoryImpl
we have org.apache.commons.logging.LogFactory file in WebContent/META-INF/services
the content of the file is
org.apache.commons.logging.impl.Log4jFactory
The log files are created but nothing is written in it. It is not showing any error in the log files in log of appserver.
Please let me know if I am missing something.
Please note: if I keep commons-logging.properties in /opt/IBM/WebSphere/80/AppServer/profiles/AppSrv01/properties, then it works perfectly fine. It is writing in the log files. But as I heard it is not standard practice so I can't keep the file in that place. I have to find some alternative way.
Please help me.
If it is not a requirement to have separate log files for your web application, you can simply remove the commons-log jar and properties from your module (war) and your log statements will write to SystemOut.log according to the log level settings in the WebSphere console (which can be changed at runtime, by the way).
If you must separate application logging, you can refer to this infocenter article that lays out the combination of commons-log jar location, commons-log properties values, and application classloader settings (Parent-First, Parent-Last, commons-log.jar bundled or not, etc) to achieve the desired results.
I would like to deliver jar files with its own logback logging configuration.
The common way to configure logback is with the default file logback.xml that logback library reads from the classpath's root (works for application servers or not).
You could include another files from the main logback config file (didn't try it), but I don't know which jars will be in the classpath and which ones require the log configuration.
Plus, the jars could be used in a command line application or application servers (shared library or not).
I thought that maybe I could get the filepath to the jar and check if there is a config file there, and try to read the configuration programmatically and load it with JoranConfigurator.
// This is the way I find to get the path to the jar
String path = ClassThatWantsALogger.class.getProtectionDomain().getCodeSource()
.getLocation().getPath();
String decodedPath = URLDecoder.decode(path, "UTF-8");// the path to the jar
But this approach could fail because depends on the security restrictions, maybe fails in Linux or in application servers. It's a hard approach for a problem that probably has a better solution.
Do you imagine a way to manage that jars could have its own logback config file that works for any environment?
I will cite myself to answer your question: Logging configuration is the concern (separation of concerns) of the client application. It's his decision to make where, how and what will be logged. You shall not impose anything on it by our library.
I'm deploying 2 ears in Weblogic 10, A and B. In both of them I have a "log4j.properties" file. At the startup, when the first ear is loading, the logs are to the right file "A.log", but when the second ear is loading, all logs are going to the "B.log" file, even logs related to the first ear.
I missed something... any idea ?
Thanks
Edit/Solution :
Classloader issue.
Add to the weblogic-application.xml :
<wls:prefer-application-packages>
<wls:package-name>org.apache.log4j.*</wls:package-name>
</wls:prefer-application-packages>
Thks to everyone :)
It would be my guess that the log4j library that is used by the Weblogic server is used in both your web applications.
If this is the case, both web apps would share a root classloader serving the global libraries loade by Weblogic.
If your web apps each provide a copy of log4j, and if you can choose to load the application classes before the server classes (I don't know Weblogic but for WebSphere the setting is 'classloader mode: parent first / parent last') that might solve your problem.
Honestly it's hard to tell from here but you can try these:
1) check if the logger names in both of your log4j property files are unique.
2) I think that the .properties file are not cached on disk but still deleting the application
deployment directories (should be separate for both the EAR's )