My application is going to have a configuration file that configures its settings.
I want this to be the only configuration file the application uses,
The application will be run from a jar file, which means that log4j will be started as soon as the application is run.
Is there any way to delay initialization of log4j so i can use information from configuration file to configure log4j and then start log4j?
As Andreas writes, you (or a library you call) obviously use Log4J. But without a short code example, we can't tell you what's going on (Hint: by removing code to get a short example, you might find the culprit yourself).
According to the Documentation it should even be possible (starting from release 2.4) to change the configuration programmatically after Log4J started.
Related
I have an existing application that logs messages using the java.util.logging API. As far as I can see, there are no configuration files for it in the framework, though there is some code to create a file appender. When I run the application, I get log messages to the console and to a file.
Now, I need to incorporate a library that uses Log4j 2. When I do so, I lose the console logging from the main application (though log messages still get written to the file appender that is created programmatically).
I imagine that, since the file appender is working in the original application, that I can solve my problem by also programmatically creating a console appender in the main application. However, I don't know if that's right or a kludge.
So, my question: is there anything general that I need to know about making java.util.logging and Log4j 2 interoperate? If the original application is not coded properly or according to best practices, I can change it.
Now, I need to incorporate a library that uses Log4j 2. When I do so, I lose the console logging from the main application (though log messages still get written to the file appender that is created programmatically).
The
Log4jBridgeHandler will remove handlers if the install method is called from code. You can always print the log tree to see what handlers are attached or attach a tool like JConsole to inspect the logger tree with and without the 3rd party lib.
I imagine that, since the file appender is working in the original application, that I can solve my problem by also programmatically creating a console appender in the main application. However, I don't know if that's right or a kludge.
Programmatic configuration of the logger tree should be done with the LogManager config option:
A property "config". This property is intended to allow arbitrary configuration code to be run. The property defines a whitespace or comma separated list of class names. A new instance will be created for each named class. The default constructor of each class may execute arbitrary code to update the logging configuration, such as setting logger levels, adding handlers, adding filters, etc.
Create a stand alone named class that just installs the handlers in the constructor.
Set the java.util.logging.config.class system parameter to the name of your class.
Otherwise if you have a logging.properties you set config to your class name.
So, my question: is there anything general that I need to know about making java.util.logging and Log4j 2 interoperate? If the original application is not coded properly or according to best practices, I can change it.
The java.util.logging.LogManager can only see classes on the system class loader. In that case log configuration in code is required to gain access to the correct classloader.
It might be easier to remove all JUL configuration and bridge to Log4j2. You can then leverage the configuration needed through that framework.
I read a lot but I couldn't figure out how I could specify for example the log level for specific classes.
Only way I could figure out was in the standalone.xml but why should I configure some application specific setting very general in the server? This complicates the deployment process unnecessary.
Isn't it somehow possible to define the specific log level and the output files somewhere inside the war without touching the server?
Btw. it doesn't matter if log4j or commons-logging or slf4j or whatever is used.
Using a logging.properties file or a log4j configuration file in your deployment will work in JBoss EAP 6.x and WildFly (formerly JBoss AS). Note though that a log4j configuration would only work if you use log4j for your logging facade.
That said I agree with Marko that this should probably be done in the server configuration. I would also encourage you to use the CLI or web interface rather than editing the raw XML as well. You can get some more information on the documentation.
I am sorry for not providing a direct answer, but consider this: the application being in charge of logging levels is a bad idea most of the time as this is something an AS admin should be able to change at any time. For example, the point of the DEBUG or TRACE log levels is to be able to place a lot of such statements in the code without hurting the production server's performance. However, once a bug is detected, you want to be able to lower the logging level without rebuilding the application. This should be a purely administrative task.
On the other hand, I do recognize the need to at least have a decent starting point for the logging configuration and I don't know of any architecture which would allow the application to provide defaults which are overridable by the server configuration.
I am bit confused so, thought to ask experts.
I have written small java application. I have function which reads properties files which contains the path of the directory where to write the log and exceptions. Lets say I get exception while reading the properties file since logger wouldn't have been initialized by that time, how can I know that there was an error or exception? If I have written e.printStackTrace() in catch block where it will be printed? I am running this application through windows scheduler.
Thanks for advice.
BR
SC
Forget about Log4j. That was useful when logging capabilites were not embbeded inside JRE itself. You can configure the logging properties by a means of a logging.properties file (which is provided at JVM start point). Inside the application you can log messages with different levels of severity with or without nested exceptions.
Here is a useful page with example of basic configuration and logging capabilites use.
Use log4j configure it [here it will configure it self by using log4j.properties or .xml from the classpath ] , initialize it in app startup and use it app wide.
If you want to know for sure that the exception was thrown, don't catch it :) The printStackTrace() writes to stderr. You could run your app though console to read it. If you want to log no matter what without any config or extra libs, you can use java-util.logging which is bundled with the jdk and writes to stdout by default
It seems a Log4j rolling appender stopped logging because it hit the MaxBackupIndex limit. I've moved the old log files out of the way but Log4j doesn't seem to start logging again.
Is there a way to restart Log4J logging via JMX?
I'd like to leverage this insteaed of restarting a Tomcat instance.
Thanks.
Logback, log4j's successor can be reloaded via JMX. It also supports (in thread) automatic reloading of the configuration file if it is modified.
I don't think that's what log4j does. The MaxBackupIndex parameter tlle it how many old files to keep around before it starts deleting them, it has no effect on the logging itself. I suspect your problem lies elsewhere.
I have some jar files that will be distributed to clients that are using log4j for logging. My question is should I include a log4j.xml configuration in the jar file or have the client provide one if they want logging?
My feeling is to leave the log4j.xml configuration file out of the client jars, since the apache jar files all come with log4j logging, but sans log4j.xml.
Yes, leave it out. It's an utter nuisance when your log4j configuration file is ignored because one of the 60 third-party libraries of your app contains its own.
The good thing about log4j in your case is that your jar really shouldn't have to worry about it. The basic use case of log4j is:
Obtain a logger object for the current class
Call one of the methods on that logger, such as debug("some message");
If the jars you are shipping are to be used by a larger application, then ideally your code will only do the two steps listed above. In this way, your code will simply obtain logger objects from the already-configured log4j instance in the client's application. Your production code is then decoupled from having to know how to configure log4j.
Any logging you need to see for your development of the jars can be accomplished by configuring a log4j instance in unit test setUp() methods or something similar that won't get bundled with the production code going to the client.
I would put a default log4j configuration that you expect will be useful to your clients in the documentation. This way interested people can see what logging options you have (usually certain classes have more interesting log messages, from the user's perspective). I find it annoying when I have a third-party lib using log4j and it has no documentation, and there are log messages filling my screen and I have to try to figure out how to enable or suppress certain log messages.
If you are using log4j in your application then you include it in your project. If you are not, then why would you put it in there? What if client A wants log4j version 1.2 and client B wants log4j version 1.3.
Let them decide what they need for their projects and worry about what you need for yours.
I would add the configuration xml and load it up with instruction for the user showing different configuration and options. This will make it easier for either them or support to enable addition logging.