Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Scout/Concepts/Logging

< Scout‎ | Concepts
Revision as of 12:59, 1 November 2011 by Claudio.guglielmo.gmail.com (Talk | contribs) (New page: {{ScoutPage|cat=Concepts}} In Eclipse Scout, there exists a transparent way for doing logging. Eclipse Scout supports JUL (using java.util.logging) and the Eclipse Log Framework (using IS...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

The Scout documentation has been moved to https://eclipsescout.github.io/.

In Eclipse Scout, there exists a transparent way for doing logging. Eclipse Scout supports JUL (using java.util.logging) and the Eclipse Log Framework (using IStatus). Furthermore, a custom log implementation can be registered to use a different Log Framework, f.e. log4j.

Logger Usage

Project code may use IScoutLogger to abstract from the runtime implementation.
private static IScoutLogger logger = ScoutLogManager.getLogger(MyOwnClass.class);

It is possible to add a code template to quickly add this line in you class. Here is the pattern:

${:import(org.eclipse.scout.commons.logger.IScoutLogger,org.eclipse.scout.commons.logger.ScoutLogManager)}
private static final IScoutLogger logger = ScoutLogManager.getLogger(${enclosing_type}.class);

It should appear in the template proposals list (CTRL+Space).


The IScoutLogger-Interface is implemented by EclipseLogWrapper, JavaLogWrapper or CustomLogWrapper which is returned by the above call to ScoutLogManager.getLogger(Class).

Logger Setup

By default, JUL is used. But it is possible to change that behaviour by setting the config.ini property org.eclipse.scout.log or creating a fragment to the host-Plug-In org.eclipse.scout.commons.

JUL

Insert these lines in the config.ini to activate standard java log.

eclipse.consoleLog=false
org.eclipse.scout.log=java

Using different Log Configurations for Development and Productive Environments in JUL

Logging requirements typically differ depending on the target environment.

In development a more detailed logging is desirable and logging to the console is just fine, where for productive use, logging should be directed to a file and should concentrate on errors and warnings.

See this The Scout documentation has been moved to https://eclipsescout.github.io/. for implementation details of this scenario.

Eclipse Log Framework

This is normally used in workbench ui applications with swt.

eclipse.consoleLog=true
org.eclipse.scout.log=eclipse
org.eclipse.scout.log.level=WARNING

Custom Logger (e.g. Log4J)

A custom log implementation can be registered by creating a fragment to the host-Plug-In org.eclipse.scout.commons. In turn, if the config.ini property org.eclipse.scout.log is not set, the ScoutLogManager looks for a class named org.eclipse.scout.commons.logger.CustomLogManager within its classpath. If found, this class is instantiated and used as logging strategy.

As an example the use of log4j is explained in this The Scout documentation has been moved to https://eclipsescout.github.io/.

Additional Logging Features

It is possible to set dynamically a global log level to all loggers no matter of which log level they currently are logging. Of course, this can be made undone and all loggers have their origin log level again.

Furthermore, it is possible to record log messages for a certain amount of time. When recording is stopped, a file is created containing all log messages since recording was started. The combination of the recording functionality together with the change of the log level at runtime facilitates debugging. This is especially true, if systems are to be maintained to easily get some valuable log output.

See this The Scout documentation has been moved to https://eclipsescout.github.io/. for a detailed example of the additional logging features.

Known issues

When using a profiler such as jvisualvm or jconsole with the system property -Dcom.sun.management.jmxremote then the first class loader to load LogManager cannot load the class contained in the logger fragment (even though it is a fragment to the system bundle). This is because the osgi has not even startet yet.

Back to the top