I know it is possible to reload log4j's xml configuration while the application is running, but the searching I've done only shows how to do this when the XML config file is edited manually via a text editor.
I want to be able to dynamically change the level of the root logger in my application via a web page and persist that change to the log4j XML configuration, so I won't have to change the log level again if I restart the application. Is it possible to do this, or can the log4j XML file only be updated manually?
I am using log4j 1.2 in my application.
Many thanks in advance!
for any chump who finds themselves stuck dealing with this, it is possible to write out the data as properties using
org.apache.log4j.config.PropertyPrinter;
You can acheive this by PropertyConfigurator configure and watch.
Read the configuration file configFilename if it exists. Moreover, a thread will be created that will periodically check if configFilename has been created or modified. The period is determined by the delay argument. If a change or file creation is detected, then configFilename is read to configure log4j.
Related
I have an application running in Wildfly 8.2.1. In addition to the server.log file in the log directory, my application creates and uses other log files too (also in the log directory). They all end in .log. This is dynamic and programmatic using org.apache.log4j.FileAppender, since the names, contents, and number of files differs from one client to the next.
What I'd like is for Wildfly to automatically rotate these log files too in addition to its own (i.e. server.log). I see in standalone.xml there is a periodic-rotating-file-handler tag with a file subtag that has a path attribute. From reading the Wildfly logging documentation, it seems like I can't use wild cards here? So, path="*.log"? Is this true? If so, how can I achieve the end goal of Wildfly automatically rotating my log files instead of doing it myself?
If you'd like to rotate log files you'd need to use a rotating file handler. The periodic-rotating-file-handler will only rotate it's own file not other files associated with other file handlers.
Since you seem to be creating a log4j file appender have a look at the org.apache.log4j.RollingFileAppender.
My app deployed on Tomcat uses log4j to write a log file. If I delete that file, then the app does not recreate it. I also tried to recreate it manually, but it remains always empty. Is there any way to delete the log file (not from the app), create a new one in the same path with the same name, and that it can be written by the application?
Is there any way to delete the log file (not from the app), create a new one in the same path with the same name, and that it can be written by the application?
Nope. You need to get the application itself to restart logging.
The problem is that the log4j appender still has a handle for the deleted file, and will continue to write to it ... unaware that it has been deleted.
A better approach would be to have the application itself take care of "rotating" the logfile. Look at the classes that implement the log4j Appender interface for some ideas.
I've been given the requirement that the first line of my log files must begin with a specific header. This header should specify that this current file is newly created. Even when log files are automatically rotated.
It seems odd but it is in the specification for the project.
Environment info:
App Server: Glassfish V2
Logging: SL4J
I think you're going to have to subclass the relevant appender and add your own code to do this.
The log file is not written by slf4j. It is written by the logging system behind the facade. The solution will depend on what that logging system is.
Unless that logging system has an existing log file appender that does this, you will need to write a custom appender (using the appropriate API, etc) that writes the header each time it opens a new log file.
What is the purpose of Web Service Deployment Descriptor (wsdd) configuration file.
If I didn't configure this file explicitly it doesn't create any issue in my application (as I am using a .jws file to do some web service related processes). But, for the first time the application runs, an error is logged in the error log file. The error is as follows:
"Unable to find config file. Creating new servlet engine config file: /WEB-INF/server-config.wsdd". And when the page refreshes or even the application is re-logged in (still the server is running), there won't be any such error log further times. When I use a sample wsdd file in my application, the error is not at all logged in the error log file. I want to know the purpose of this wsdd file and how to configure it based on our application.
Any suggestions would be appriciated.
Marshal.
Just do a google on "server-config.wsdd".
e.g. http://axis.apache.org/axis/java/integration-guide.html
It looks like your container or framework is generating a default file if you don't specify one, which is useful, but if you wish to add additional customisations such as handlers, security and logging (etc) then you can specify your own file.
It might be best to use a "bare minimum" file so you can customise it later.
As I understand it, JBoss* monitors a variety of file types in /deploy and performs certain actions when the file changes. For example, JBoss will redeploy an EAR when its last-modified time changes.
Therefore, I could use some really nasty code to make an EAR redeploy itself, like this:
URL url = this.getClass().getClassLoader().getResource("../RavenWeb.ear");
String path = url.getPath();
File ear = new File(path);
ear.setLastModified(System.currentTimeMillis());
But what I really want to do is just have JBoss redeploy the webapp when an external config file changes. Say the config file lives at C:/foo/bar.properties.
Is there an MBean or some other way getting this done that won't get me mauled by velociraptors?
*I'm using JBoss 5.1.0, if it matters.
I think your best shot is having a MBean that will reload your config file whenever you call a function on it. If you wan't this to happen automatically, you can also consider having a MBean handling the configuration file for you. This way, you can just update MBean properties instead of changing a configuration file.
I've copied the Log4JService implementation and put it in a .sar.
It just simply polls the configuration file, parse it and put a Configuration object in the JNDI, so that I can retrieve it in my application. In this way you don't have to redeploy the entire application, and you can use the new configuration in the app.
If you have to do something else than simply reloading the app, you can do it in this service.