Book Image

Instant Apache ServiceMix How-to

By : Henryk Konsek
Book Image

Instant Apache ServiceMix How-to

By: Henryk Konsek

Overview of this book

<p>Creating reliable integration solution can be easy if you choose the right tools for the job. Apache Camel and ServiceMix are the leading integration technologies dedicated to dealing with the complexity of the messaging solutions. Learn how to efficiently integrate multiple systems with bleeding edge open source Apache software.</p> <p>"Instant Apache ServiceMix How-to" is a practical, hands-on guide that provides you with a number of clear, step-by-step exercises that will help you take advantage of the real power that is behind the leading Apache integration stack.</p> <p>This book guides the reader in how to install ServiceMix and how to get it up and running. It will take you through a number of practical recipes – starting with the basic commands of Apache Karaf container and ending with the deployment of JMS and web service solutions.</p>
Table of Contents (7 chapters)

Adjusting logger settings in the running ServiceMix instance (Should know)


This recipe will guide you through the process of adjusting the configuration of the ServiceMix logging system while the container is up and running.

Getting ready

Usually a static logger configuration defined in the properties file is not flexible enough for real-life deployment scenarios. A detailed level of logging leads to an excessive number of writes to the application log, which obviously leads to a performance penalty. The high number of messages also makes the application log less readable. That is why you usually would like to stick to the course-grained level of logging, such as info or even warning. Switching to the more detailed (fine-grained) logging (such as debug or trace) is useful when you try to spot a bug or want to analyze an unusual behavior in the system. However, due to performance reasons mentioned earlier, you would like the logger to report detailed information only for the time of the debugging session. With the interactive ServiceMix console, you can temporarily change the logging level to fine-grained, and when you are done with the bug, switch back again to the inexpensive brief one.

How to do it...

  1. Connect to your ServiceMix instance with the interactive shell.

  2. Type the log:set LEVEL LOGGER command.

How it works...

The ServiceMix console together with the Pax logging is an excellent tool to adjust the settings of your logger at runtime. In order to change the latter configurations when ServiceMix is running, you need to connect to your container with an interactive Karaf console.

Before you change the logging level of the given logger, you might want to check its current settings. To return to the current level of the given logger, issue the log:get command. The following code listing demonstrates an example of checking the current level of the selected logger.

smx@root> log:get com.example.Logger
Level: INFO

After you check the current level of the logger you are interested in, you can safely change it to the desired value. To change the level of a given logger, use the log:set command. The following code listing demonstrates how to change the logger settings during an interactive ServiceMix console session:

smx@root> log:get com.example.Logger
Level: INFO
smx@root> log:set DEBUG com.example.Logger
smx@root> log:get com.example.Logger
Level: DEBUG

At startup, ServiceMix reads the default settings of the Log4J logger from the SERVICEMIX_HOME/org.ops4j.pax.logging.cfg file. After the default settings are loaded, ServiceMix looks in the SERVICEMIX_HOME/data/cache directory for the changes in the logging configuration that have been made during the runtime of the container. The latter's settings (that is, the cached runtime) overrides the former (read from the static configuration saved in the etc directory). Any changes made to the logger configuration at runtime are immediately applied to ServiceMix and stored in the SERVICEMIX_HOME/data/cache directory.

There's more...

Before you proceed to the next recipe, take a quick look at the following logging-related hints. You may find them useful when working with ServiceMix in a production environment.

Audit logging

When dealing with larger systems, you may encounter a functional requirement called audit logging. When a system provides audit logging functionality, it can store a detailed record of activities that have been performed within its bounds. The recorded data usually includes traced user activity. Such data can then be used by the system administrator to retrieve detailed information about a given user and his/her actions performed on the system. Audit logging is a challenging topic mainly due to the amount of data that is stored and processed by the audit tools. In many cases, audit logging is performed using a standard logging facade (such as SLF4J or Log4J) in conjunction with an asynchronous messaging and persistent data stores. If you use a standard logging facade to handle your audit requirements, you will also additionally benefit from ServiceMix's logger runtime tuning.

JMX

Using the ServiceMix console for tuning the logger is very useful, but it is not the only way to change your logging settings at runtime. A Java tool called JMX (http://en.wikipedia.org/wiki/Java_Management_Extensions) allows you to connect to your JVM instance and configure its runtime settings as well. The majority of the logging frameworks in Java come with built-in support for dynamic configuration via JMX. Note, however, that changes made to the logging configuration using JMX are not persisted between ServiceMix restarts (while configurations modified with the ServiceMix console are cached by a container in order to be available after the restart).

Removing a cached configuration

Sometimes you might feel that you have made too many changes to the runtime configuration of your ServiceMix logger. If you start to lose control over your logging settings, you can delete your cached runtime logging settings from the SERVICEMIX_HOME/data/cache directory. Finding the right directory to delete is not a trivial task, since all subdirectories of the cache are named bundleX (where X is an identifier of the OSGI bundle). To reset the logger settings, you need to remove the bundle directory containing the file named logging.config. If you are using a Linux operating system, try to issue the find data/cache -iname 'logging.config' command, which may be helpful in locating the proper bundle directory.