public interface ServerLogging
Smart GWT's server-side classes have extensive built-in diagnostics which are output via the Apache Log4j 2 library (see below for other alternatives).
At startup, Smart GWT will automatically load the file
from the classpath and use it to configure Log4j 2.
log4j2.isc.config.xml is in
XML configuration format,
and sets default log threshold levels for various subsystems to produce output that is
generally appropriate for both development and production systems. Various Smart GWT
documentation may encourage you to enable certain diagnostic logs using this file when
troubleshooting specific problems.
iscLog4jConfiguration JVM argument, which if explicitly set will be used
of the default
log4j2.isc.config.xml configuration file. It should point to an
configuration file using the same Log4j2's standard
XML configuration format:
-DiscLog4jConfiguration=log4j2.custom.config.xmlNote if the
iscLog4jConfigurationis present, but the configuration file could not be loaded, Smartclient will fallback to default
The Server Logs tab of the
Smart GWT Developer
Console provides the
ability to view the most recent 10000 log entries, and change log threshold levels dynamically
Note that the features of the "Server Logs" tab will only be available if using Log4j 2 API with the default Log4j 2 implementation.
If Log4j2 is used and custom loggers are configured in
DataTools.getLoggerContext() method to access them on server side,
Deprecated. Slf4j is intended to be a generic API that you can log to, which can be configured to talk to various logging frameworks. However, Log4j 2 now offers the same capability of plugging in alternate logging frameworks, and the generic logging API is better than Slf4j, making Slf4j support obsolete and deprecated.
Smart GWT server logging can alternatively use the Simple Logging Facade for Java (slf4j), which allows logs to be sent to a variety of different logging frameworks that support Slf4j.
To send all logging to slf4j, the
iscUseSlf4j VM argument must be set to true
on the command line, like this:
It is still possible to use Log4j 1.x via the Slf4j. And even when the Slf4j will not be directly supported by the Smartclient there will be an option to redirect Log4j 2 API to the Slf4j + Log4j 1.x combo by using the Log4j 2.x to Slf4j binding.
Note that the only reason to do this is that you've got heavy logging customizations that depend on Log4j 1.x, so you can't migrate to another logging system yet. However, if you use this setup, you should plan migration as soon as possible.
Logging migration recommendations
on how to move to Log4j 2.x.
Smartclient uses Quartz Scheduler 2.3.1 and also continues to support Hibernate 3, both of which depend on Slf4j for their internal logging. So, we are shipping with the set of dependencies redirecting Hibernate and Quartz logging to the Log4j 2 using the Log4j 2.x Slf4j binding approach, so that the internal logging goes: Hibernate -> Slf4j -> Slf4j to Log4j 2.x binding -> Log4j 2.x.
Used to log slow SQL queries. SQL query is considered "slow" if its execution time exceeds
configured threshold, see the global sql.log.queriesSlowerThan
server.properties SQL setting and more specific
setting for more details.
Set category logging level to "DEBUG" to log all slow queries:
<Logger name="com.isomorphic.SLOW_SQL" level="DEBUG" />or enable logging for specific
<Logger name="com.isomorphic.SLOW_SQL.fetch" level="DEBUG" /> <Logger name="com.isomorphic.SLOW_SQL.add" level="DEBUG" /> <Logger name="com.isomorphic.SLOW_SQL.update" level="DEBUG" /> <Logger name="com.isomorphic.SLOW_SQL.remove" level="DEBUG" /> <Logger name="com.isomorphic.SLOW_SQL.custom" level="DEBUG" />