I have to disable the log for the application that is at my hands now.
Application is composed of its own source and number of other components imported by means of jars,
It uses hibernate, and when hibernate functionality executes, it prints everything to the console.
Now, I think Log4J is in use there somehow, but only through commons-logging, that comes with hibernate distribution. I see no log4j.properties file anywhere. And there is no xml coniguration for hibernate that has loging settings.
How can I disable the log output going to console, but keeping that going into file.
I got this application to update it's build system, so technically I didn't introduce anything source code works with,- no new properties, no new setting. Just updated some build.xml and other xml files which are part of build process. I am told, that it wasn't directing output to the screen before. Could it be that I included some library that is not needed and that is causing this to happen?
Thanks fo t
Some libraries ship with their own log4j configuration, and that will clash with other libraries. This is specially true in AppServers environments. The only way I have found to override this behavior is to (re)configure log4j in my application.
Related
I am working on a huge application which uses its on property file to set the global variables. I want to use the same one for setting the properties of Log4j log file instead of log4j.properties file due to some problems. How do I do this? Is there any way to set the properties of Log4j at run time?
If you just want to rename your log4j.properties file you can do this using a System Variable in your JVM startup (refer link)
-Dlog4j.configuration=test.properties
The Log4j API also allows configuration changes to the Loggers from within an application. Theoretically you could read your own property file and call the appropriate API calls. I'm not sure this approach is recommended - you might end up spending a lot of time getting it working that you could better use developing your application functionality.
Note: I dont know the nature of the huge application, but it if its running in an application server such as JBoss they often have their own dynamic logging configuration
I'm running two Java programs from within MATLAB, which means they both share the same JVM instance with MATLAB. This is a problem when trying to use Log4J, because it's statically configured. If I run PROG1 (and it configures Log4J), then run PROG2 (which also tries to configure Log4J), then PROG2 subsequently fails to log its output to the correct place in certain versions of MATLAB.
I want to somehow configure PROG1's project in Eclipse to forever forbid the use of Log4J, but it should still be allowed in PROG2. Just removing log4j.jar from the PROG1 project's classpath doesn't solve the problem, because there's no way to prevent it from being re-added as a direct or indirect dependency.
Ideally, it would be nice if I could configure the project so Eclipse will always check for this at compile-time and add markers (like its existing compile warnings & errors), and tag any Log4J accesses (including our own utility classes for configuring Log4J) in that project with a brief message explaining this problem.
The next best thing I can think of is to further complicate the Ant script, but that still leaves open the possibility that I or someone else in the future might add Log4J logging to the PROG1 project and not realize the consequences until after spending a significant amount of time and later running a build.
Any ideas how I can forever forbid the use of Log4J in a specific project, such that it's also adequately protected from the same problem in the future?
This is a follow-up (somehow of my Third-party dependencies to an OSGi application) where it was suggested that some libraries e.g. log4j are already available as bundles.
In Eclipse Indigo I could not find a log4j bundle available to Import Package as part of my installation and so I created a Plugin Project from JAR archive to bundle log4j and also a Feature Project to bundle the log4j.xml configuration following this post.
To be honest I don't understand why the fragment project is needed but this process works.
So my question now is:
Since the log4j.xml is delivered in the export as part of the feature jar, it requires some "effort" for someone to find it and update the debug levels, so I was wondering is this indeed the correct process?
I had in mind that the final exported product would deliver the log4j configuration in an easy to find location, but now (although the logging works) I am concerned whether what I do, is indeed correct.
Any help here?
If you really need to expose the file, you could put it anywhere you want, and then make sure your program calls one of these methods at startup:
org.apache.log4j.xml.DOMConfigurator.configure(String filename)
org.apache.log4j.PropertyConfigurator.configure(String
configFilename)
Or use the "configureAndWatch"-variants if you would like to make changes to the config without restarting your application.
Edit: I write "If you really need to", because I have experienced that I never need to turn on debug-logging after deployment, because it is always turned on! This is OK for applications where I have normal (but not extreme) requirements on response-time and throughput. Logging to an UDP-appender is fast (and does not fill up the disk). Or using rolling file appender is quite safe, and fast enough for my use. Always having the debug-log available is a life-saver when nailing down those hard-to-reproduce bugs.
I suggest take a look at Pax-Logging this will give you all kinds of logging frameworks for usage in a OSGi environment. And you're able to use an external configuration file (no extender needed) to configure your logging.
The fragment is one option to extend the log4j bundles classpath to include the required configuration file. It is probably the simplest way of configuring application wide properties.
This is not meant to be altered after deployment though as it will be embedded within a jar file. You will have to come up with a different approach if you expect to make it configurable after deployment.
NOTE:
I am afraid you misunderstood the answer about the jars that are already available as bundles. This does not mean that they are part of your OSGi platform of choice (Indigo), only that they are ready to be deployed to an OSGi platform as is. Your creation of a plugin project was unnecessary, you simply needed to add the jar to your target platform to resolve your missing imports.
I'm trying to configure logging for my web application (WAR), in log4j.properties:
log4j.rootCategory=WARN, RF
log4j.appender.RF=org.apache.log4j.RollingFileAppender
log4j.appender.RF.File=???/my-app.log
What file path I should specify for my-app.log? Where to keep this file? Currently I'm deploying my application to Tomcat6, but who knows what happens in the future. And who knows how exactly Tomcat will be configured/installed on another machine, in the future.
What I finally did is this:
In continuous integration settings.xml I define a property log.dir
In log4j.properties I define: log4j.appender.RF.File=${log.dir}/my-app.log
In pom.xml I instruct Maven to filter .properties files
That's it. Now I can control the location of my log files on the destination container without any changes to the source code.
Logging is a deployment configuration descriptor so you really cannot generalize. Configuration depends on the host machine and other, non functional requirements of the project.
Generally in tomcat I log into ${catalina.home}/logs/myapp.log but as you can imagine if I deploy in weblogic there isn't any catalina.home so the log will go to c:\logs\myapp.log.
I agree with #cherouvim. In general, you should put the log file outside of the webapp, and preferably in the same place that the container puts its log file.
You don't want to put them in the webapp tree, because they will get clobbered if your webapp is redeployed.
What file path I should specify for my-app.log? Where to keep this file?
If the question is about your personal machine, it doesn't really matter. Put them where it's handy for you (e.g. next to the server logs).
If the question is about a development, IST, UAT, etc environment, logs should typically be written to a separate/dedicated partition. But you should ask this question to the sysadmins, many companies have exploitation standard, standardized layouts.
Currently I'm deploying my application to Tomcat6, but who knows what happens in the future.
This is a shot in the dark since but here is a normalized path I've used in the past: /var/log/tomcat/<PROJECTNAME>/myApp-<instance-#>.log.
And because I'm not better than you at fortune-telling, yeah, who knows what happens in the future :)
And who knows how exactly Tomcat will be configured/installed on another machine, in the future.
That's the beauty of a configuration file, you can configure it as required... and even change it :)
Where I work we use Log4j for web application logging. The log4j.jar is at the application level, not the container level. We're using a daily rolling file appender. Our log4j.properties files define appenders based on the app package name, so only classes in our application's package and below get logged to our app's log file.
In my application, I'm extending our framework with some supporting classes. These classes are not in the application's package, as they are not exclusive to my application and will eventually be made into a jar library for use with other applications. Because of this, my logging statements are not picked up by my application's appender, and are thus not logged to my application's log files.
I want to allow the classes in my jar to log to the log file of the application using the classes. However, if I create an appender in my application's log4j properties file based on my classnames, I suspect that when multiple applications are using my jar, because of the identical class names in the log4j.properties files, only one application log file will receive my jar's logging statements, and that it will receive ALL the logging statements from EVERY application using that jar. I think this is the case, since we're using a static Logger.getLogger() call to retrieve the logger.
I first want to know if my fears are valid, if this is really what would happen when multiple web applications in the same or different containers are using my jar simultaneously.
I'd also like to know if there are "boundaries" on which this behavior changes. For example, does this problem exist regardless of whether log4j.jar is a container-level jar or an app-level jar, or if each container is running in a separate JVM?
Lastly, if this IS the case, I'd like to know what strategies I should use to overcome the problem.
Thanks in advance!
If log4j.jar is only in the web-app then the logs will stay separate so each web-app should have its own log4j.jar and log4j.properties so that all logs stay separate.
The problem is that the preffered pattern for log4j is to use static *Configurator methods, which don't go very well with application containers.
This article solved this problem for me when i came across it ...