Configuration

The following three steps have to be carried out on the client side in order to configure the applications to be monitored on the Anyframe Monitoring Tool.

JVM Preparation

InfraRED weaves the code of the application and for this it uses either AspectWerkz or AspectJ internally; hence to integrate InfraRED with an application, one needs to integrate either of them on the JVM on which the application is running. The links provided below details the steps to be followed for preparing the various JVMs. Follow the instructions provided for the JVM - Aspects (AspectJ / AspectWerkz) combination you plan to use.
AspectJ 1.5 - Preparing Sun 1.4 JVMs
AspectJ 1.5 - Preparing Sun 1.5 JVM
AspectJ 1.5 - Preparing BEA JRockit 7 and 8.1 JVM
AspectWerkz 2.0 - Preparing Sun 1.4 JVMs
AspectWerkz 2.0 - Preparing Sun 1.5 JVM
AspectWerkz 2.0 - Preparing BEA JRockit 7 and 8.1 JVM

Customising Application Layers Using AspectsWerks

Create a file META-INF/aop.xml that can be loaded by the Classloader which loads the application. For a WAR web application, this can be put in WEB-INF/classes (so that we have the file WEB-INF/classes/META-INF/aop.xml). For an EAR application in Weblogic, this can be put in APP-INF/classes (so that we have the file APP-INF/classes/META-INF/aop.xml). For an EAR application in JBoss, this has to be put in the META-INF dir in the root of the ear. This is a regular AspectWerkz aspect definition file , but contents of this determine the layers of the application that would be identified by InfraRED. A sample is give below.
<!DOCTYPE aspectwerkz PUBLIC
"-//AspectWerkz//DTD//EN"
"http://aspectwerkz.codehaus.org/dtd/aspectwerkz2.dtd">
 
<aspectwerkz>
    <system id="my.app">      
        <exclude package="net.sf.infared.*"/>        
        
        <!-- 
            All executions in com.my.app.layer1 package and its subpackages
            will be recorded as LayerOne
        -->
        <aspect class="net.sf.infrared.aspects.api.ApiAspect"
                deployment-model="perClass" name="LayerOne"> 
            <param name="layer" value="LayerOne"/>
            <pointcut name="methodExecution" 
                      expression="execution(public * com.my.app.layer1.*...*(..))"/>
            <advice name="collectMetrics(StaticJoinPoint sjp)" type="around" bind-to="methodExecution"/>
        </aspect>
    
        <!-- 
            All executions in com.my.app.layer2 package and its subpackages
            will be recorded as LayerTwo
        -->
        <aspect class="net.sf.infrared.aspects.api.ApiAspect"
                deployment-model="perClass" name="LayerTwo"> 
            <param name="layer" value="LayerTwo"/>
            <pointcut name="methodExecution" 
                      expression="execution(public * com.my.app.layer1.*...*(..))"/>
            <advice name="collectMetrics(StaticJoinPoint sjp)" type="around" bind-to="methodExecution"/>
        </aspect>
    </system>
</aspectwerkz>

Customising Application Layers Using AspectJ

Layers are typically identified by packages. Create an AspectJ aspect extending abstract aspect provided with InfraRED, as:
import net.sf.infrared.aspects.aj.AbstractApiAspect;
                        
public aspect LayerOneAspect extends AbstractApiAspect {
    // This pointcut matches execution of all public APIs in 
    // com.my.app.layer1 and subpackages 
    public pointcut apiExecution():
        execution( public *  com.my.app.layer1.*...*(..) );
    
    // InfraRED will record executions of all public APIs in 
    // com.my.app.layer1 and subpackages as Layer One.
    public String getLayer() {
        return "Layer One"; 
    }
}
Compile this aspect with ajc tool that ships with AspectJ. You will have to add infrared-agent-all-servlet-2.4.1.BETA.jar to the CLASSPATH. Also remember to use ajc that ships with AspectJ 5 or later. Create a file META-INF/aop.xml that can be loaded by the Classloader which loads the application. For a WAR web application, this can be put in WEB-INF/classes (so that we have the file WEB-INF/classes/META-INF/aop.xml). For an EAR application in Weblogic, this can be put in APP-INF/classes (so that we have the file APP-INF/classes/META-INF/aop.xml). For an EAR application in JBoss, this has to be put in the META-INF dir in the root of the ear. The contents of this file should be:
 <aspectj>
    <aspects>
        <aspect name="LayerOneAspect"/>          
    </aspects>
</aspectj>
Layers are typically identified by packages.

web.xml Configuration

Starting with the user requested URL, in order to monitor the methods or queries, we register the listener and filter in the following web.xml.
<!-- omission -->
<listener>
	<listener-class>net.sf.infrared.agent.setup.InfraREDServletContextListener</listener-class>
</listener>		
<filter>
    <filter-name>infrared</filter-name>
    <filter-class>net.sf.infrared.aspects.servlet.InfraREDServletFilter</filter-class>
</filter>    
<filter-mapping>
    <filter-name>infrared</filter-name>
    <url-pattern>*.do</url-pattern>
</filter-mapping>
<!-- omission -->

infrared-agent.properties Configuration

In order to communicate with InfraRED, download the infrared-agent.properties file defining the needed properties in the Web Context/WEB-INF/classes, and by referencing the properties information, we adjust the contents to the appropriate projects.
Property
Description
Default Value
Enable-monitoring This boolean property decides if Infrared should monitor the application. If this property is set to false, no data will be visible on the Infrared web gui.
jdbc-monitoring-enable This boolean property decides if Infrared should monitor the jdbc executions for the application. False
enable-call-tracing This boolean property decides if Infrared should record call traces. A call trace is a sequence of executions in an application and the Infrared web gui makes use of a tree structure to display the call trace. False
prune-threshold The threshold value (in milliseconds) for any execution to be recorded in InfraRED. Executions taking lesser time than this value (in ms) would be pruned by Infrared. 3000
last-invocations-to-trace The number of invocations that need to be displayed in the Last Invocations page of the InfraRED web gui. 0
prepared-statement-monitoring-enable This boolean property decides if Infrared should keep track of the arguments for a SQL query bound to a PreparedStatement. False
mbean-server-provider The class name of the MBean server provider. The legal values are net.sf.infrared.weblogic.configmgmt.WLSMBeanServerProvider for Weblogic server and net.sf.infrared.jboss.configmgmt.JBossMBeanServerProvider for JBoss server. The Infrared MBean can be used to configure the Infrared properties using JMX based tools like MC4J Management Console. The InfraredProperties MBean exposes the following properties as attributes :enable-monitoring, jdbc-monitoring-enable, enable-call-tracing, prune-threshold None
collection-strategy The class name of the strategy that needs to be employed for the collection of the metrics of the application. Infrared currently supports only CentralizedCollectionStrategy and the corresponding class name is net.sf.infrared.agent.transport.impl.CentralizedCollectionStrategy. The default DoNothingCollectionStrategy, as the name indicates, acts as a dummy collection strategy implemetation. net.sf.infrared.agent.transport.impl.DoNothingCollectionStrategy
collection-strategy.ccs.remotehost The hostname of the machine that runs the infrared collector. The collected statistics for the application are flushed to the collector in the remotehost making use of a socket connection. Localhost
collection-strategy.ccs.port The port number on the remotehost where the Infrared collector listens for the flushed statistics 7777
collection-strategy.ccs.flush-frequency The frequency at which the collected statistics for the application need to be flushed to the collector in the remotehost. The flush frequency value needs to be optimised for good performance. The higher the value, the longer the statistics need to be stored at the application end and hence the greater will be the required memory. On the other hand, a lower frequency implies larger network traffic. 30000
collection-strategy.ccs.pool This boolean property decides if the collected statistics need to be maintained using thread pools in the application end before they are flushed to the collector in the remote host. True
collection-strategy.ccs.pool.maxThreads The maximum number of threads permissible in the thread pool.This property is applicable only if the collection-strategy.ccs.pool is set to true. 1
Collection-strategy.ccs.pool.buffer-length The capacity of the pool buffer indicating the number of elements that can be held. This property is applicable only if the collection-strategy.ccs.pool is set to true. 100
For a sample infrared-agent.properties file, refer to the following:
#  The sample infrared-agent.properties

enable-monitoring true
enable-call-tracing true
jdbc-monitoring-enable true
prune-threshold -1
last-invocations-to-trace 5
prepared-statement-monitoring-enable true

collection-strategy net.sf.infrared.agent.transport.impl.CentralizedCollectionStrategy
collection-strategy.ccs.remotehost localhost
collection-strategy.ccs.port 7777  
collection-strategy.ccs.pool false
collection-strategy.ccs.flush-frequency=3000
mbean-server-provider=systemier.common.jmx.InfraRedMBeanServerFactory
#collection-strategy.ccs.pool.maxThreads = 1
#collection-strategy.ccs.pool.buffer-length = 100

Monitoring Service Selection

In order to monitor a specific service using two aspects providing in the Core Framework, we copy in the folder location of the appropriate service’s property definition file the applicationContext-monitoring.xml or applicationContext-monitoring-jdbc.xml file. applicationContext-monitoring.xml file contains the following contents.
 
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:aop="http://www.springframework.org/schema/aop"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.0.xsd">
	<bean id="anyframe_api_profiler" class="anyframe.common.aop.aspects.ApiAspect" >
		<property name="layerName" value="APPLICATION_SERVICE"></property>
	</bean>
	<bean id="anyframe_api_profiler_aop_autowire" class="anyframe.common.aop.ExclusiveBeanNameAutoProxyCreator">
		<property name="beanNames" value="*Service"/>
		<property name="exclusiveBeanNames" value="anyframe_api_profiler"/>
		<property name="interceptorNames">
			<list>
				<value>anyframe_api_profiler</value>
			</list>
		</property>
	</bean>
</beans>
ApiAspect executes the method by the specific service’s proxy. When the specific proxy is created in the Anyframe Core, the appropriate service’s interface is used. Therefore, when ApiAspect is used, the appropriate service has to be composed of interface and implementation classes. applicationContext-monitoring-jdbc.xml file contains the following contents.
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:aop="http://www.springframework.org/schema/aop"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.0.xsd">
	<bean id="anyframe_jdbc_profiler" class="anyframe.common.aop.aspects.JdbcAspect" >
	</bean>
	<bean id="anyframe_jdbc_profiler_aop_autowire" class="anyframe.common.aop.ExclusiveBeanNameAutoProxyCreator">
		<property name="beanNames" value="dataSource"/>
		<property name="exclusiveBeanNames" value="anyframe_jdbc_profiler"/>
		<property name="interceptorNames">
			<list>
				<value>anyframe_jdbc_profiler</value>
			</list>
		</property>
	</bean>
</beans>
JdbcAspect is an aspect for handling the DB connection for checking the execution times of operated queries.. The applicationContext-monitoring-jdbc.xml file has to be put In the same location as the DataSource service’s property definition file.