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

Virgo/Diagnostics

< Virgo
Revision as of 07:45, 23 July 2010 by Spowell.vmware.com (Talk | contribs) (Simplified the output example.)


This page contains hints and tips for diagnosing problems with Virgo and Virgo applications.

Equinox Console

The Equinox Console is useful for examining either the kernel framework or the user region framework.

Virgo offers shell commands to the user region Equinox Console for slightly more friendly inspection of user region artefacts.

To enable an Equinox console, you need to set a framework property, like this:

osgi.console=2402
identifying the port to use.

In the case of the user region, add this property to the file config/org.eclipse.virgo.kernel.userregion.properties. In the case of the kernel region, add this property to the file lib/org.eclipse.virgo.kernel.launch.properties.

You can even enable an Equinox console in both regions at once, using two different ports of course.

To use the console, telnet in:

> telnet localhost 2402

The most useful commands are ss to list all bundles, bundle <n> to display information about the bundle with bundle id <n>, and help to see other commands.

When running in the user region, the Virgo shell commands are offered via the vsh command. Type vsh help to see a list of the shell commands available.

Precision Debug logging

It is possible to turn on logging at various levels for specific classes (loggers) in Virgo. We illustrate this with a FileSystemChecker debug trace, which is part of the HotDeployer system.

In serviceability.xml in the config directory simply add the following:
<logger level="DEBUG" additivity="false" name="org.eclipse.virgo.kernel.deployer.hot.HotDeployer">
    <appender-ref ref="SIFTED_LOG_FILE" />
</logger>

after the other logger specifications and before the root tag.

This puts debug information in the log.log file in serviceability/logs/virgo-kernel directory.

Alternatively, set appender-ref ref="LOG_FILE" and the debug information goes in the general log.log file in the serviceability/logs directory.

In this case the sort of output you might see is (actual paths have been replaced):
[2010-07-23 12:27:44.599] fs-watcher                   org.eclipse.virgo.kernel.deployer.hot.HotDeployer                 pickup - before check:
	FileList():  [test.configuration.properties]
	Known files: [/path-to-server-home/pickup/test.configuration.properties]
	Monitored:   [/path-to-server-home/pickup/test.configuration.properties] 
[2010-07-23 12:27:44.660] fs-watcher                   org.eclipse.virgo.kernel.deployer.hot.HotDeployer                 pickup - after check:
	Known files: [/path-to-server-home/pickup/test.configuration.properties]
	Monitored:   [] 
[2010-07-23 12:27:45.661] fs-watcher                   org.eclipse.virgo.kernel.deployer.hot.HotDeployer                 pickup - before check:
	FileList():  [test.configuration.properties]
	Known files: [/path-to-server-home/pickup/test.configuration.properties]
	Monitored:   [] 
[2010-07-23 12:27:45.661] fs-watcher                   org.eclipse.virgo.kernel.deployer.hot.HotDeployer                 pickup - after check:
	Known files: [/path-to-server-home/pickup/test.configuration.properties]
	Monitored:   [] 
[2010-07-23 12:27:46.661] fs-watcher                   org.eclipse.virgo.kernel.deployer.hot.HotDeployer                 pickup - before check:
	FileList():  [test.configuration.properties]
	Known files: [/path-to-server-home/pickup/test.configuration.properties]
	Monitored:   [] 
[2010-07-23 12:27:46.662] fs-watcher                   org.eclipse.virgo.kernel.deployer.hot.HotDeployer                 pickup - after check:
	Known files: [/path-to-server-home/pickup/test.configuration.properties]
	Monitored:   [] 

which is pretty verbose, so be aware that the log file may become quite large very quickly. In the standard serviceability.xml file the appenders used here write to "rolling log files" which are based upon size; so the total amount of logged information is bounded, though the log you choose can be swamped with information from one source.

The serviceability.xml file is just a logback configuration file, and all the Logback functionality is available. For more information see the Logback configuration on-line documentation.

Back to the top