Using Log4j MDC (Mapped Diagnostic Context) in an Axis2 module

Mapped Diagnostic Context (MDC) is a thread-local key-value store that can be accessed from a Log4j conversion pattern. It can be used very effectively in web applications where one log serves several clients or users, to differentiate the log statements related to each client or request. In this example, the service a message is destined to, will be logged right next to the time of the log message, as the variable "service" in the MDC (referenced by %X). To make this work, you can put the Service name into the MDC, using the static method MDC.put(key, value).

MDC.put("service",messageContext.getAxisService().toString());

To use the MDC, you have to put a placeholder into the respective Log4j conversion pattern in lib/log4j.properties:

log4j.appender.CARBON_CONSOLE.layout.ConversionPattern=[%d{ISO8601}] [%X{service}] %5p - %c{1} - %m%n

Setting charset of JVM to UTF-8 for WSO2 Products

To set the charset of JVM during startup by passing file.encoding system property add the following line to bin/wso2server.sh under $JAVA_OPTS.

-Dfile.encoding=UTF-8 \

For more info, read: Supported Encodings

Starting OSGi console when WSO2 Carbon runs in daemon mode

In the $CARBON_HOME/repository/conf/wrapper.conf file, add the following line to the 'Java Additional Parameters' section.
wrapper.java.additional.11=-DosgiConsole=<telnet-port>

After starting Carbon with these settings, connect to the OSGi Console using telnet as follows.
telnet <ip address> <telnet-port>

To learn more about using the OSGi Console, refer:

• http://pradeepfernando.blogspot.com/2011/10/debugging-your-osgi-application-using.html
• http://charithaka.blogspot.com/2009/08/remotely-starting-osgi-console-when.html

Quick WSO2 Tip: How to build any WSO2 product from source

Checkout orbit, kernel, and platform.

svn co https://svn.wso2.org/repos/wso2/carbon/orbit/trunk/ orbit
svn co https://svn.wso2.org/repos/wso2/carbon/kernel/trunk/ kernel
svn co https://svn.wso2.org/repos/wso2/carbon/platform/trunk/ platform

Build in the order (orbit -> kernel -> platform), using maven3.

mvn clean install

Hat tip: http://wso2.org

A quick way to append your public keys to a remote server's Authorized Keys File

The basic steps are:

1. Create an RSA key-pair.
2. Copy the public key to the remote server.
3. Add the public key to the authorized_keys file on the remote server. 

For generating the key use the command

ssh-keygen -t rsa

The following command does the steps 2 and 3.

ssh-copy-id user@host

Use ${basedir} in Maven.. ALWAYS!

If you come across different outcomes in your maven build depending on whether you invoked the maven command inside project's directory or its parent directory, you are doing it wrong somewhere. The build should be consistent. If that module is part of a big multi-module project, project should behave the same always even it's built in the command line or as a part of a build scheduled in a continuous integration server.

For example if you refer to a directory like <directory>target/site</directory> it will look for the target directory at the location the command was executed. This will make things inconsistent depending on whether you invoked it inside the sub-module or the parent project. But referring to it like <directory>${basedir}/target/site</directory> will make sure the target directory will always be searched in one location, the directory where the pom.xml lies. For some reason, if you want to point to the directory from which the maven command was executed use ${user.dir}

For a full list of Maven properties read Maven Properties Guide or this chapter on Sonatype's book, 'Maven: The Complete Reference'.

TL;DR : Remember ${basedir} always represents the directory containing the pom.xml

XFCE window borders missing

On one bad day if you find your nice, slick xfce desktop environment is all messed up and there are no window decorations or title bar in the application windows.. it can be because your window manager has crashed. You can start it up by the command

xfwm4 --replace

You don't have to do this every time you log in. It should work automatically if you save your session when you log out. If not, you might want to clear out your sessions cache to reset it and solve the problem. To reset your sessions cache, simply delete the .cache/sessions folder in your home directory.

rm -rf ~/.cache/sessions

You can look at the logs in ~/.xession-errors to figure out the exact problem. Read more at this forum post.