I'm having some trouble configuring proper logging in Eclipse Scout framework. My claims aren't that high as I only want to be able to set different log levels for different parts of my program in a configuration/properties/XML file.
The logging configuration in the config.ini of my Scout server plugin currently looks like this:
eclipse.consoleLog=true
org.eclipse.scout.log=eclipse
org.eclipse.scout.log.level=INFO
So as you can see this is the default logging configuration using Eclipse logging. It works fine for logging at a global level. The only thing I would like to do is to write something like this to set the different log levels:
packagename.ClassName=LOGLEVEL
As this is a very basic logging use case I think there must be some easy way to do this in Scout. Otherwise I would appreciate some help how to configure log4j, JUL or others for the use with Scout. The Eclipse Scout Wiki hasn't helped me so far. I created the example logger fragment to the host plugin 'org.eclipse.scout.commons' and removed the logging configuration lines from my config.ini but nothing happens. I'm also not sure where to put the log4j.poperties or how this is done otherwise.
I'm a bit ashamed for being unable to figure out such a basic problem, but would be very happy about some quick help.
I can tell you how to configure the logging if you choose the java logger (config.ini: org.eclipse.scout.log=java).
For the eclipse logger, I barely found any information at all.
Now, to configure the java (JUL) logging: You can do this in a file called logging.properties.
You can configure the logging by specifying the configuration file in your product:
Create your configuration file - say logging.properties inside the folder where your product file (for server or client respectively) is located. Typically this is in a folder named 'products'.
Open your product file and go to the "Launching" tab and specify your logging configuration file in the "VM Arguments" tab. Use the "java.util.logging.config.file" system property to do so:
-Djava.util.logging.config.file="${resource_loc:/com.yourapp.server/products/logging.properties}"
Now, you should be able to specify the log levels in your new logging.properties file:
### Root level of your application, all below are ignored
.level=INFO
### Handlers
handlers=java.util.logging.ConsoleHandler
### Handler properties
java.util.logging.ConsoleHandler.level=FINEST
### Override the logging level for certain classes
com.yourapp.server.SomeService.level=FINE
Alternatively, you can also use a class to initialize the logging with the java.util.logging.config.class option. See this wiki page for a detailed example.
Also, when building a WAR file, you might be interested in this answer.
Related
Springboot how to rotate log files on the server restart.
I have the below entries
# LOGGING
logging.level.org.springframework.web=WARN
logging.level.org.hibernate=WARN
logging.file=/var/log/apps/myapp.log
I can't find any details here:
https://docs.spring.io/spring-boot/docs/1.5.9.RELEASE/reference/html/common-application-properties.html
As per the following link in application.properties regarding log files, the following are the configurations.
https://docs.spring.io/spring-boot/docs/current/reference/html/common-application-properties.html
logging.file.max-history=0 # Maximum of archive log files to keep. Only supported with the default logback setup.
logging.file.max-size=10MB # Maximum log file size. Only supported with the default logback setup.
Apart from the above, you can also check below the configuration based upon the server configured.
server.tomcat.accesslog.rotate=true # Whether to enable access log rotation.
server.undertow.accesslog.rotate=true # Whether to enable access log rotation.
I would suggest to use Slf4j along with logback. You need to configure logback.xml and you can configure rolling file appender.
You can add the custom log configuration with logback-spring.xml.
The various logging systems can be activated by including the appropriate libraries on the classpath and can be further customized by providing a suitable configuration file in the root of the classpath or in a location specified by the following Spring Environment property: logging.config.
https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-logging.html#boot-features-custom-log-configuration
I got a rotation policy with setting a limit to the log file size and the same for the backup.
logging.file.name=/path/log/file
logging.file.max-size=10MB
logging.file.total-size-cap=10MB
IMPORTANT: it will keep just a backup file.
I dont know your exact scenario but you can do this by passing env_variable when you start a server.. like your build version number and use that in your property file
spring-boot:run -Dbuild.number=1.x
And you may use this like
# LOGGING
logging.level.org.springframework.web=WARN
logging.level.org.hibernate=WARN
logging.file=/var/log/apps/myapp-${build.number}.log
Dont forgot to increment number everytime.
I have the following setup
Version: Openfire 4.0.2
Server Directory: /opt/openfire
Running on a Centos (6) machine.
I have a plugin and I run a lot of debug code when developing. I will get an instance of a Logger using:
private static final Logger Log = LoggerFactory.getLogger(Submitter.class)
but the problem is that when I look at the logs (DEBUG level), I get EVERYTHING that has DEBUG (for example the httpd Apache libraries). I know that in JBOSS (and other systems) I can make a config that allows me to put Log Ouput of just my plugin to a specific location (e.g. a separate file).
Does anyone have any idea how to do this or if this is possible in Openfire?
Many thanks
In Openfire installation, under lib directory, there's a config file named
log4j.xml
just modify this and override default one.
If you need a log4j tutorial, check out at: https://www.mkyong.com/logging/log4j-xml-example
In you case you can:
redirect your own classes in another custom file
redirect all debug in another file and keep your custom class in
default debug log so it will be viable by Openfire webinterface
I have the following log4j.properties file, for an application deployed in WebSphere Portal:
log4j.rootLogger=DEBUG, InfoAppender, DebugAppender
log4j.appender.InfoAppender=org.apache.log4j.RollingFileAppender
log4j.appender.InfoAppender.Threshold=INFO
log4j.appender.InfoAppender.File=C:/info.log
log4j.appender.InfoAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.InfoAppender.layout.ConversionPattern=%d %p [%c] - %m%n
log4j.appender.DebugAppender=org.apache.log4j.RollingFileAppender
log4j.appender.DebugAppender.Threshold=DEBUG
log4j.appender.DebugAppender.File=C:/debug.log
log4j.appender.DebugAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.DebugAppender.layout.ConversionPattern=%d %p [%c] - %m%n
When I code, I define the logger at class level:
private static Logger logger = Logger.getLogger(IWannaLogThis.class);
And I log INFO messages with this:
logger.info(theObjectToLog);
When I deploy my application, the debug.log file gets everything I log with logger.debug() but ignores everything I write with logger.info(). On the other side, the info.log file keeps empty.
The weirdest thing is that in debug.log and info.log appears some INFO and DEBUG messages made by some JARS (like Hibernate Validator) I had in the classpath, but just ignores everything I try to log in my code.
Any ideas?
This is most likely a classloading-related problem. WebSphere Portal uses Log4J internally, so I'm guessing that you end up using WebSphere Portal's provided Log4J JAR file as well as its own Log4J properties.
You can verify that by adding the following to the JVM arguments of the server instance:
-Dlog4j.debug=true
And then inspect the SystemOut.log file. Log4J will spit out lots of tracing information about the configuration file(s) it reads.
The best way to avoid this is to do the following:
Bundle the Log4J JAR file with your application.
Associate a Shared Library with the server. In that Shared Library, place your Log4J configuration file.
As an alternative to step 2, you can bundle your Log4J configuration file with the application itself, however that would carry its own drawbacks (for example, having to repackage your application whenever you perform a Log4J configuration change).
Another common problem is that the JARs you have in your classpath also use log4j and also have their own appenders set. So depending on the settings that they use, and the packages that your classes reside in, this may lead to the problem you describe.
So:
Make sure that your package names are unique and not used by any of the third party libraries.
Check the log4j settings in all libraries in your classpath. They should not contain general settings which override yours.
Make sure your loggers use your log4j.properties (you can be sure if changes you make in your file affect your loggers as expected).
If you can, make sure that your log4j stuff loads last, in case any of the third party libs reset the configuration. They shouldn't, but who can stop them.
Normally, it should be one of these things. Post more explicit example if it doesn't work.
Good luck!
What I have done in the past is set specific logs for the classes I want to log. It sounds like you can try setting your root logger to INFO and see if that gets you the messages you want. Here's a little bit of my log4j property file. I set a logger for each class and assign it to my "data" appender, which defines the log layout. In the loggers I specify specific classes I want to log and set their Log level individually. Any class that logs that is not defined in the Loggers I have use the default log level for the rootCategory.
log4j.rootCategory=INFO, rollingFile, stdout
#GetData Loggers
log4j.logger.com.myapp.data=INFO, data
log4j.logger.com.myapp.data.SybaseConnection=DEBUG, data
log4j.logger.com.myapp.data.GetData=ERROR, data
# data appender
log4j.appender.data=org.apache.log4j.RollingFileAppender
log4j.appender.data.layout=org.apache.log4j.PatternLayout
log4j.appender.data.File=c\:\\Program Files\\MyApp\\logs\\MyApp-data.log
log4j.appender.data.Append=true
log4j.appender.data.layout.ConversionPattern=[%d{ISO8601}]%5p%6.6r[%t]%x - %C.%M(%F:%L) - %m%n
you root logger opens the log properties in the debug mode,
use INFO instead of DEbug in the first line of your properties file.
I'm currently working on a project that uses log4j.
I'm running a testcase (junit) and would like to set the log level to trace so that I can see if all the values are correct. Classes that use logging in the project contain a line like the following:
private static final Log LOG = LogFactory.getLog(MatchTaskTest.class);
and use a like like this to do the actual debugging
LOG.trace("value");
I have never used log4j before, does anybody know how I can change the log level just for the testcase, preferably simply by defining a parameter in eclipse's run configuration dialog.
Using another configuration file
Perhaps you could point to another configuration file.
java -Dlog4j.configuration=config file yourApp
Where:
config, you file of configuration, e.g. log4j.properties or log4j.xml.
file, the log file, e.g. myApp.log
yourApp, you app, e.g. MyAppGUI
Or you can use a class
java -Dlog4j.configurationClass=config class yourApp
Where:
config, you file of configuration, e.g. log4j.properties or log4j.xml.
class, any customized initialization class, like LogManager, should implement
the org.apache.log4j.spi.Configurator
yourApp, you app, e.g. MyAppGUI
You can see more in Apache log4j 1.2 - Short introduction to log4j on Default Initialization Procedure section.
Modifying the level programmatically
Moreover, you can also use the methods that offers the Logger class, like public void setLevel(Level level), e.g.:
Logger.getRootLogger().setLevel(Level.TRACE);
Since you want only for testing purposes, you could use them. But it is recommended not to use in client code because they overwrite the default configuration parameters in hard coded. The best way is to use an external configuration file.
In your junit class put:
Logger.getRootLogger().setLevel(Level.TRACE);
somewhere before the execution of the tested method. It will set the threshold level of the root logger to TRACE.
If you're using Maven, you can have two log4j configuration files:
one in src/main/resources, containing your production logging config
one in src/test/resources, containing your test-time logging config
Maven will automatically use the latter at test time, and bundle the former into your artifact (JAR, WAR, etc) so that it's used in production. You don't have to mess around with command line switches or anything.
I don't think this is possible.
The config file is going to let you configure what log messages actually surface in the log, not what level each message is going be logged at. This makes sense - the config should not affect the level of the message.
The javadoc has a method for each log level and a generic log method, which takes in a priority, so I'm not sure there's even a default to be set.
You can set a config file explictly on the command line via -Dlog4j.configuration=<FILE_PATH>, so you could set up a specific config for that test case.
I have no idea why some of the above didn't work for me. (I don't want to write config file). following works for me
Logger log1 = Deencapsulation.getField(Some.class,"logger");
log1.setLevel(Level.DEBUG);
NB that the log4j2.properties file may include the line
filter.threshold.level = debug
You can waste an entire afternoon trying to figure out why your LOG.trace() statements aren't outputting anything!
I actually put it in the #Before method. But I believe it could (and should) be placed in the #BeforeClass.
If you set it in the class body you'll get compiler errors.
is there a standard configuration regarding logging with log4j in JUnit using Eclipse?
When I create a new JUnit-Test testing a class which uses a Logger I don't have to change the Run Configuration to enable logging. Magically the Junit Test is redirecting the log messages to standard out.
But in my case only messages with importance INFO get printed. Does anybody know how to change this behaviour and where to find the configuration of the JUnit logger.
I could change the Run configurations for every JUnit test but I am more interested in the default behaviour and the logic behind.
This has nothing to do with JUnit, it's just log4j behavior. Sounds like there is a log4j.xml or log4j.properties somewhere on your classpath that is getting picked up (as I believe log4j will log nothing by default, and instead print warnings to standard error about not being configured correctly) - add -Dlog4j.debug to your system VM args to have log4j print out some diagnostic information about where it is loading the configuration from.