Configuring Component based logging in OSGi using Log4j

Initialize reading of the log4j xml in any of the core bundles. Ensure that this bundle doesnt get bounced often.Configure the values to include log4j xml and reload delay.The init method can look something similar to the one below.

public void initialize() {
try {
try {
String logConfig = "D://temp//poc_log_config.xml";
long configReloadDelay = (long) (1 * 30 * 1000);
if (logConfig != null && (new java.io.File(logConfig).exists())) {
if (logConfig.endsWith("xml")) {
org.apache.log4j.xml.DOMConfigurator.configureAndWatch(
logConfig, configReloadDelay);
} else {
org.apache.log4j.PropertyConfigurator
.configureAndWatch(logConfig, configReloadDelay);
}
} else {
org.apache.log4j.BasicConfigurator.configure();
}
} catch (Exception initErr) {
initErr.printStackTrace();
}
} catch (Exception err) {
}

}


The log4j xml will look as follows

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">

<appender name="PRODUCT1" class="com.test.anyappender">
<param name="File" value="D:\\temp\\product1\\product1log.log"/>
<param name="MaxFileSize" value="100000000"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d{HH:mm:ss,SSS} - %m%n"/>
</layout>
<param name="Threshold" value="DEBUG"/>
</appender>

<appender name="PRODUCT2" class="com.test.anyAppender">
<param name="File" value="D:\\temp\\product2\\product2.log"/>
<param name="MaxFileSize" value="100000000"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d{HH:mm:ss,SSS} - %m%n"/>
</layout>
<param name="Threshold" value="DEBUG"/>
</appender>

<root>
<level value="OFF" />
</root>

<logger name="test1">
<appender-ref ref="PRODUCT1"/>
<level value="INFO" />
</logger>

<logger name="test2">
<appender-ref ref="PRODUCT2"/>
<level value="DEBUG" />
</logger>

</log4j:configuration>


Now in any bundle code you can access any component logger as follows

static final Logger TEST_LOGGER = Logger.getLogger("test1");

use TEST_LOGGER.debug("any debug message");

By the above approach we can just have a single log4j bundle in the repository and not only avoid issues occuring from static variables but also can take full benefit of log4j API's.

Extending OSGi telnet for custom commands

OSGi telnet command provided by equinox can be easily extended to implement custom commands.

First we need to write a class with which implements the custom commands.the methods should start with _ to be identified as osgi telnet commands.The getHelp command needs to be overwritten ,which will display the command when help is hit on the telnet console.

import org.eclipse.osgi.framework.console.CommandInterpreter;
import org.eclipse.osgi.framework.console.CommandProvider;

public class CustomCommands implements CommandProvider {
@Override
public String getHelp() {
return "***********CUSTOM COMMANDS*******************\n";
}

public void _testcommand(CommandInterpreter ci) {
ci.println("arg 1" + ci.nextArgument());
ci.println("arg 2" + ci.nextArgument());
}
}


Next step is to write a BundleActivator and register the command Provider service.

@Override
public void start(BundleContext ctx) throws Exception {
customCmd = new CustomCommands();
//created a instance of the implementation of our custom commands
ctx.registerService(CommandProvider.class.getName(),customCmd, null);

}

Dont forget to add the bundle activator class to the manifest. Manifest should include the following.

Import-Package: org.eclipse.osgi.framework.console;version="[1.0.0,1.0.0]",
org.osgi.framework;version="[1.4.0,1.4.0]"
Bundle-Activator: com.command.extender.CommandBundleActivator

JMX using Spring

JMX aims to create standard API's for managing and monitoring java applications.

Managing - changing values at runtime.

Monitoring - Reporting certain conditions.

Mbean -is a java bean with a management interface.

Mbean can expose attributes(through getters and setters) or any opertaions.Management interface can be defined statically or at runtime through interfaces.MBean Server acts as a broker between interacting beans or beans and remote clients.

Mbean server maintains a key to all registered means which is called as object name.The default protocol used is RMI , but can be changed to SOAP or Hessian.

Using raw JMX APi's is difficult , spring simplifies this.

Use the following configuration to create a MBeanServer. This will be required normally only if we are running standalone code.Else most of the containers like tomcat or spring dm provide the default MBeanServer which can be used to register the Mbeans.

<bean id="MBeanServer" class="org.springframework.jmx.support.MBeanServerFactoryBean">
<property name="locateExistingServerIfPosssible" value="true">
</bean>

Configuration to register a bean as MBean to MBeanServer.

<bean id="jmsSample" class="com.pg.MonitorService"></bean>

<bean class="org.springframework.jmx.export.MBeanExporter">
<property name="beans">
<util:map>
<entry key="service:name=jmsSample" value-ref="jmsSample" />
</util:map>
</property>

By this all methods and attributes of this can be accesed using jconsole. Sometimes this may not be what we want .we would want to control the set of operations which are visible through JMX.

The Spring MbeanExporter allows the following stratergies

1. ObjectnamingStratergy - this will help in identifying the mbean in the jconsole.

• a. KeyNamingStratergy(Default) - key passed will become the name
• b. IdentityNamingStratergy -generates a object name dynamically
• c. MetaDataNamingStratergy - reads object name from source level meta-data (annotations)

2. MBeanInfoAssembler

When we want to control what we are exposing through JMX this is the better approach

• SimpleReflectiveMbeanInfoAssembler -Default -Exposes all public methods and properties
• MethodNameBasedMbeanInfoAssembler Methods can be configured through spring xmls which will be exposed through JMX.
• MetadataMBeanInfoAssembler what needs to be exposed is controlled using source level annotations.
• InterfaceBasedMBeanInfoAssembler

a. Using managed Interfaces property

<bean class="org.springframework.jmx.export.MBeanExporter">
<property name="beans">
<util:map>
<entry key="service:name=jmsSample" value-ref="jmsSample" />
</util:map>
</property>
<property name="assembler">
<bean
class="org.springframework.jmx.export.assembler.InterfaceBasedMBeanInfoAssembler">
<property name="managedInterfaces">
<value>com.pg.IService</value>
</property>
</bean>
</property>

</bean>

Here the jmsSample bean need not implement teh managedInterface.

b Using interfaceMapping property

<bean class="org.springframework.jmx.export.MBeanExporter">
<property name="beans">
<util:map>
<entry key="service:name=jmsSample" value-ref="jmsSample" />
</util:map>
</property>
<property name="assembler">
<bean
class="org.springframework.jmx.export.assembler.InterfaceBasedMBeanInfoAssembler">
<property name="interfaceMappings">
<util:map>
<entry key="service:name=jmsSampleService" value="com.pg.IService"></entry>
</util:map>
</property>

</property>

</bean>

Thea bean jmsSample must implement the interface mentioned in interfaceMapping property

This API helps in monitoring application using JMX.

http://jamonapi.sourceforge.net/