P6Spy is a tool to debug JDBC interaction with a database. It's a wrapper of all JDBC elements ( Connection, PreparedStatement, ResultSet... ) and it has a powerful feature in order to log all informations about those interactions.

JDBC wrapper is described in the "Java Performance Tuning" book of Jack Shirazi ( O'Reilly) in the chapter 16.

All elements wrappers have a constructor with the element to wrap. We can use it but there is another mode for datasource. This last mode must be used to wrap a datasource defined in an application server for example.

However since we can manage our objects ( beans ) in Spring ( and datasources too ), it's possible to add a P6Spy datasource and link it with the real datasource with constructor injection.

<?xml version="1.0" encoding="ISO-8859-1"?>

Moreover a p6spy.log file must be add to the classpath of the application to specify the location of the log file.

module.log=com.p6spy.engine.logging.P6LogFactory

The output can be graphically view with a tool like Iron Track SQL.

The Spring framework offers a great support of JMX. The aims of this support are:

• automatically convert simple beans into MBeans
• automatically register simple beans and MBeans declaratively
• configure an embedded JMX server
• configure JMX connectors to access to the components of the agent layer

At this time, the support doesn't include JMX notifications but it's planned for the version 1.3RC2. See the issue SPR-680 in JIRA: http://opensource2.atlassian.com/projects/spring/browse/SPR-680

I have developped some code to implement this issue. Its aims are:

• provide a way to add/remove JMX listeners on registred MBeans based on their object names
• provide a way to add/remove JMX listeners on simple beans and MBean exported on the JMX server with Spring facilities.
• offer an abstraction to allow bean or MBean exported with to send notifications

Add/remove JMX listeners on registered MBeans

The aim of this part is to add/remove listeners on MBean not registered with Spring facilities. The common example is to listen events triggered by the MBean server delegate. This entity sends notifications on register/unregister MBean events. The following listing shows how to configure it.

<bean id="delegateListeners" class="org.springframework.jmx.export.notifier.NotifierFactoryBean">
  <property name="server"><ref local="mbeanServer"/></property>
  <property name="objectName">
    <value>
      JMImplementation:type=MBeanServerDelegate
    </value>
  </property>
  <property name="notificationListeners">
    <ref local="listener"/>
  </property>
</bean>

The class testNotificationListener is a classic JMX notification listener as shown in the following listing:

public class TestNotificationListener
                 implements NotificationListener {
  public void handleNotification(
                 Notification notification, Object handback) {
    System.out.println("Notification received.");
    System.out.println(" -> "+notification);
  }
}

The listener receives the following notifications for example:

Notification received.
 -> javax.management.MBeanServerNotification
          [source=JMImplementation:type=MBeanServerDelegate]
                       [type=JMX.mbean.registered][message=]
Notification received.
 -> javax.management.MBeanServerNotification
          [source=JMImplementation:type=MBeanServerDelegate]
          [type=JMX.mbean.unregistered][message=]

Add/remove JMX listeners on MBeans registered with Spring

The support distinguishes two possibilities according to the kind of instance to export.

First the bean ot export is a simple bean not tied with JMX. In this case, the JMX support of Spring uses model MBean to convert the bean into an MBean according to different strategies to know attributes and methods to expose. The RequiredModelMBean already implements the NotificationBroadcaster, so there is nothing to do, but the listeners must be added not on the bean but on the created model MBean.

Secondly the bean is a MBean (so tied with JMX). In this case, the support looks if the MBean implements the NotificationBroadcaster. This JMX interface allows MBean to register and unregister notification listeners.

If not, AOP is used to add this interface to the bean with the method introduction feature. The implementation of this interface is the GenericBroadcaster class based on the NotificationBroadcasterSupport of JMX.

The following listing shows an example of use in this case.

<bean id="exporter" class="org.springframework.jmx.export.MBeanExporter">
  <property name="beans">
    <map>
      <entry key="bean:name=testBean1"
                value-ref="testBean"/>
      <entry key="bean:name=testBean2"
                value-ref="testSimpleBean"/>
    </map>
  </property>
  <property name="notificationListeners">
    <ref local="listener"/>
  </property>
  <property name="server" ref="mbeanServer"/>
</bean>

Send notifications from simple beans and MBeans registered with Spring

To send a notification, the simple bean or the MBean needs an abstraction. This abstraction must just have a method to send a notification. I define the Notifier interface as following:

public interface Notifier {
  void notify(NotificationCreator creator,Object handback);
}

One of the challenge is to give an instance of this interface. The simple bean or MBean must tell the JMX support that it can accept this by implementing the NotifierAware interface. It works like the other *Aware interfaces (ApplicationContextAware, BeanFactoryAware) in Spring. If the support detects this interface, it will call the method setNotifier on it.

public interface NotifierAware {
  void setNotifier(Notifier notifier);
}

The following listing shows an example to send a notification.

public class MyBean
  public void test() {
    notifier.notify(new NotificationCreator() {
      public Notification createNotification() {
        return new Notification("test",this,0);
      }
    },null);
  }

Note: I have a doubt about the utility of the NotificationCreator which offers a callback to create the Notification. As a matter of fact, the creation of a notification instance is just a new... I'm thinking of removing it.

Improve the support

An improvement could be the support of filter for notification and the management of the handback instance...

The aim of this article is to describe the use of Jencks (http://jencks.org). It is based on the version 1.1.1 of the project.

This project allows application to use the transaction and connector modules with the JCA support of Spring in order to use JCA in a managed mode outside a J2EE application server. It allows to develop more lightweight applications and to embed XA features into every applications even if they are not deployed in an application server.

JCA support of Spring

The JCA support of Spring provides a dedicated FactoryBean implementation, LocalConnectionFactoryBean, to configure a JCA connector in a non managed mode. You can too use it to configure a connector in a managed mode if you specify an implementation of the JCA ConnectionManager interface in addition to the ManagedConnectionFactort as described in the following code.

<bean id="connectionFactory" class="org.springframework.jca.support.LocalConnectionFactoryBean">
  <property name="managedConnectionFactory"><ref local="managedConnectionFactory"/></property>
  <property name="connectionManager"><ref local="connectionManager"/></property>
</bean>

Note that the LocalConnectionFactoryBean class can be used to expose different interfaces like the JMS ConnectionFactory, the JDBC DataSource, the Hibernate SessionFactory, of course the JCA ConnectionFactory...

When using this feature, you are now able to add your resources in the context of global transactions and use them with JTA.

Jencks

Jencks is very close to the Geronimo and Spring projects. As a matter of fact, it provides dedicated FactoryBean to configure resources of the connector and transaction modules of Geronimo.

The first step to use Jencks is to configure the transaction module as following.

<bean id="connectionTracker"
      class="org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator"/>

The connector module will use the entities in order to be able to use global transactions.

The next step is to configure the ConnectionManager implementation of Geronimo. It provides a pooling mechanism and a contract with the transaction manager. So you must configure a ConnectionManager for each factories (DataSource, SessionFactory, ConnectionManager...).

The configuration of the XA JMS ConnectionFactory of ActiveMQ is described in the following code. It is based on the ActiveMQ JCA connector. Firstly, you must configure the ConnectionManager and then the connector using it. Note that the configuration of ConnectionManager is similar for every connector.

<bean id="transactionSupport"
      class="org.jencks.factory.XATransactionFactoryBean">
  <property name="useTransactionCaching" value="true"/>
  <property name="useThreadCaching" value="false"/>
  </property>
</bean>

Then you need to configure the connector basing the ConnectionManager previously configured. Here is a sample with the connector of ActiveMQ. In this case, you can inject the JMS ConnectionFactory configured which is internally XA compliant. So it can participate in a 2PC transaction.

<bean id="jmsResourceAdapter" class="org.activemq.ra.ActiveMQResourceAdapter">
  <property name="serverUrl" value="tcp://localhost:61616"/>
  </bean>

Transaction demarcation with Spring

With the use of Jencks, you can manage transactions in your application normally with the classic support of Spring. In this case, the implementation of the PlatformTransactionManager interface to use is JtaTransactionManager.

For more information, see the chapter Transaction management in the reference documentation of Spring. The following code shows how to configure the JtaTransactionManager with the previous configured beans.

<bean id="transactionManager" class="org.springframework.transaction.jta.JtaTransactionManager">
  <property name="userTransaction" ref="userTransaction"/>
  <property name="transactionManager" ref="transactionManagerImpl"/>
</bean>

I'm pleased to announce the publishing of the book "Spring par la pratique" (Eyrolles).

I have co-written this book with Julien Dubois and Jean-Philippe Retaillé. Rod Johnson has written a great preface.

The book is the first book dedicated to the Spring framework written in french. It has been added in the list of books on the website of the framework. See the following urls: http://www.springframework.org/books and http://www.springframework.org/bookreview

You can have more details on the book on the website of Eyrolles:
summary, contents and sample chapters. You can reach the page of the book and download the sample chapters at the following url:
http://www.eyrolles.com/Accueil/Livre/9782212117103/

Jencks is a project hosted on the codehaus site which allows to embed the transaction and connection managers of Geronimo in every applications.

In order to simply the configuration of the two different managers, we have developped a dedicated namespace handler for Spring called Jencks. It allows applications to use two tags, transactionManager and connectionManager, which will be described in the following sections.

The XML grammar of these tags is described in the spring-jencks.xsd file. The content of this file is the following:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

Note that this namespace need the version 2.0 M4 of Spring.

Installation

In order to use this namespace handler in Spring, we need to add two files in the META-INF directory of your project.

Firstly, the spring.handlers file specifies the name of implementation of NamespaceHandler. The follwing code describes the content of this file:

http\://www.springframework.org/schema/jencks=org.springframework.jca.config.JencksNamespaceHandler

Secondly, the spring.schemas file specifies the location of the xsd file in the classpath. The follwing code describes the content of this file:

http\://www.springframework.org/schema/jencks=org/springframework/jca/config/spring-jencks.xsd

Configuration of the transaction manager

The tag transactionManager is used to configuration the JTA transaction manager of Geronimo. It internally creates four beans:

• Transaction manager (identified by the value of the id attribute)
• Transaction context manager (identified by the value of the transactionContextManagerId attribute)
• User transaction (identified by the value of the userTransactionId attribute)
• Connection tracker (identified by the value of the connectionTrackerId attribute)

The following code is an example of use of this tag in a application context of Spring:

<jencks:transactionManager id="transactionManager"
               userTransactionId="userTransaction"
               transactionContextManagerId="transactionContextManager"
               connectionTrackerId="connectionTracker"
               defaultTransactionTimeoutSeconds="600">

Configuration of the connection manager

The tag connectionManager is used to configuration the JCA connection manager of Geronimo. It can be used in order to configure a connector for outbound communications. It internally creates one bean:

• Connection manager (identified by the value of the id attribute)

This tag is based on entites configured by the tag described in the previous section:

• Transaction context manager (referenced by the value of the transactionContextManager-ref attribute)
• Connection tracker (referenced by the value of the connectionTracker-ref attribute)

The following code is an example of use of this tag in a application context of Spring:

<jencks:connectionManager id="connectionManager"
          transactionContextManager-ref="transactionContextManager"
          connectionTracker-ref="connectionTracker">

I'm pleased to announce the publishing of the book "JavaScript pour le Web 2.0" (Eyrolles) which I have co-written this book with Arnaud Gougeon.

The book describes the use of JavaScript and different librairies in order to develop rich internet application or web site with a rich user interface.

It covers all the aspects of the JavaScript language (basis, object oriented programming, dom, ajax) and its use and its interactions with (X)HTML and CSS in a web page.

It also covers in depth several JavaScript libraries like Prototype, Dojo, script.aculo.us, Rialto, Behaviour.

To finish, it deals with additional tools in order to develop and test JavaScript applications.

A project has been created for this book and can be reached at the following url: http://jsweb2.sourceforge.net/.

You can have more details on the book on the website of Eyrolles:
summary, contents and sample chapters. You can reach the page of the book and download the sample chapters at the following url:
http://www.eyrolles.com/Accueil/Livre/9782212117103/

Jencks is a project hosted on the codehaus site which allows to embed the transaction and connection managers of Geronimo in every applications.

In order to simply the configuration of the two different managers, we have developped a dedicated namespace handler for Spring called Jencks. It allows applications to use two tags, transactionManager and connectionManager, which will be described in the following sections.

The XML grammar of these tags is described in the spring-jencks.xsd file. The content of this file is the following:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

Note that this namespace need the version 2.0 M4 of Spring.

Installation

In order to use this namespace handler in Spring, we need to add two files in the META-INF directory of your project.

Firstly, the spring.handlers file specifies the name of implementation of NamespaceHandler. The follwing code describes the content of this file:

http\://www.springframework.org/schema/jencks=org.springframework.jca.config.JencksNamespaceHandler

Secondly, the spring.schemas file specifies the location of the xsd file in the classpath. The follwing code describes the content of this file:

http\://www.springframework.org/schema/jencks=org/springframework/jca/config/spring-jencks.xsd

Configuration of the transaction manager

The tag transactionManager is used to configuration the JTA transaction manager of Geronimo. It internally creates four beans:

• Transaction manager (identified by the value of the id attribute)
• Transaction context manager (identified by the value of the transactionContextManagerId attribute)
• User transaction (identified by the value of the userTransactionId attribute)
• Connection tracker (identified by the value of the connectionTrackerId attribute)

The following code is an example of use of this tag in a application context of Spring:

<jencks:transactionManager id="transactionManager"
               userTransactionId="userTransaction"
               transactionContextManagerId="transactionContextManager"
               connectionTrackerId="connectionTracker"
               defaultTransactionTimeoutSeconds="600">

Configuration of the connection manager

The tag connectionManager is used to configuration the JCA connection manager of Geronimo. It can be used in order to configure a connector for outbound communications. It internally creates one bean:

• Connection manager (identified by the value of the id attribute)

This tag is based on entites configured by the tag described in the previous section:

• Transaction context manager (referenced by the value of the transactionContextManager-ref attribute)
• Connection tracker (referenced by the value of the connectionTracker-ref attribute)

The following code is an example of use of this tag in a application context of Spring:

<jencks:connectionManager id="connectionManager"
          transactionContextManager-ref="transactionContextManager"
          connectionTracker-ref="connectionTracker">

The aim of this entry is to describe the way to use the JMS support of Spring in order to develop Java/J2EE applications based on the JMS provider Joram.

Firstly, we will describe the way to configure the ConnectionFactory of Joram in a context of Spring. Then, we will show how to handle the destinations with both JNDI and administration API of Joram. Finally, we will see how to use the JmsTemplate class of Spring in order to send and receive JMS messages basing on Joram.

Configuration of the ConnectionFactory instance

The first thing to do is to configure the ConnectionFactory of Joram in order to inject it in the JmsTemplate class of Spring. Joram offers several implementations of the JMS interface ConnectionFactory. We will see the configurations of the one based on tcp and an other used for embedded server.

Firstly, if you need to access a Joram server with tcp, you must use the TcpConnectionFactory class. This class can be configured as a Bean as following:

<bean id="connectionFactory"
     class="org.objectweb.joram.client.jms.tcp.TcpConnectionFactory">
    <constructor-arg index="0" value="tcp://localhost/"/>
    <constructor-arg index="1" value="16010"/>
</bean>

In the case of the class LocalConnectionFactory, you need to use a static factory method in order to instanciate a ConnectionFactory of this type.

ConnectionFactory connectionFactory=LocalConnectionFactory.create("root","root");

For this class, you can choose to use the support of factory method of Spring or develop a custom FactoryBean as following:

public class LocalConnectionFactoryBean
                  implements FactoryBean,InitializingBean {
    private ConnectionFactory connectionFactory;

This class will be configured in Spring as following:

<bean id="connectionFactory"
         class="test.joram.LocalConnectionFactoryBean"/>

Note that you can too choose to use the JndiObjectFactoryBean in order to get an instance of a ConnectionFactory from JNDI. The following code shows how to configure this strategy:

<bean id="connectionFactory" class="...JndiObjectFactoryBean">
    <property name="jndiName" value="cnf"/>
</bean>

Working with destintations

After having configured your JMS ConnectionFactory for Joram, the strategy to resolve the destinations must be configured. As a matter of fact, the JmsTemplate of Spring can be used both with a parameter 'destination' of type Destionation or a parameter 'destinationName' of type String.

In the first case, the application is entirely responsible to get the instance of the destination. You can use both JNDI or administration API of Joram. Here is an example of the latter:

(...)
JmsTemplate template=createTemplate();

In the second case, the JMS support of Spring delegates the task to get the destination instance basing on the name of destination to an instance of the interface DestinationResolver. There are two implementations provides by the support: DynamicDestinationResolver (based on the method createQueue and createTopic of JMS API) and JndiDestionationResolver (based on Jndi).

By defaut, the template uses the first one, but you can provide your own one with the method setDestinationResolver of this class.

Here is a custom one for Joram named JoramDestinationResolver which looks for the destination thanks to the administration API of the provider. If it doesn't exist, the class uses the same API in order to create it.

public class JoramDestinationResolver
                     implements DestinationResolver,InitializingBean {
    private static final Object JORAM_QUEUE_TYPE = "queue";
    private static final Object JORAM_TOPIC_TYPE = "topic";

Sending JMS messages using the JoramDestinationResolver class

This DestinationResolver implementation can be used as following in order to send JMS messages with the JmsTemplate class.

(...)
JmsTemplate template=createTemplate();
JoramDestinationResolver resolver=new JoramDestinationResolver();
resolver.setHostName("localhost");
resolver.setPort(16010);
resolver.setUserName("root");
resolver.setPassword("root");
resolver.afterPropertiesSet();
template.setDestinationResolver(resolver);

Receiving JMS messages using the JoramDestinationResolver

Since its version 2.0, Spring offers support for JMS asynchronous communications with the classes SimpleMessageListenerContainer and ServerSessionMessageListenerContainer which must be configured with an instance of the class MessageListener of the JMS specification.

These two classes support the mechanism based on the DestinationResolver interface in order to get an instance of a destination using its name.

Here is an example based on a JMS MessageListener:

<bean id="myJmsListener" class="test.joram.MyJmsListener"/>

The second part of the thread describe the end of the support of JMX notifications in Spring. Like the previous one, it describes the patch I have written to address the issue SPR-680 in JIRA.

See the second zip file (SpringJMX_Notification_v1.1.zip) on the issue for the implementation of this patch.

Support of filters

When a JMX notification listener is added to an MBean, you can pass a filter to select notifications the listener will accept. In our case, we use the class NotificationFilterSupport which implements NotificationFilter and allow configure the allow and deny of notifications types.

public class NotificationListenerSupport {
  ...
  public synchronized boolean isNotificationEnabled(
                       Notification notification) {...}
  public synchronized void enableType(String type)
               throws IllegalArgumentException {...}
  public synchronized void disableType(String type) {...}
  public synchronized void disableAllTypes() {...}
  public synchronized Vector getEnabledTypes() {...}
  ...
}

To associate filters with listeners on the MBeanExporter class, you need to set the notificationFilters property which tokens are delimited by the character ','. If the element starts with the character '+', the nofication type is allowed and if it starts with '-', the type is denied. The following listing shows an example of use.

<bean id="exporter" class="org.springframework.jmx.export.MBeanExporter">
  <property name="beans">
    ...
  </property>
  <property name="notificationListeners">
    <list>
      <ref local="listener"/>
    </list>
  </property>
  <property name="notificationFilters">
    <value>DENY_ALL_TYPES,+test</value>
  </property>
</bean>

Note: This feature is supported on the NotifierFactoryBean class too.

Support of handback

Handback is an object specified on the call of addNotificationListener which is then given to the listener when a notification is triggered. The patch supports now this feature with the handback property of the MBeanExporter class. The following listing shows an example of use.

<bean id="exporter" class="org.springframework.jmx.export.MBeanExporter">
  <property name="beans">
    ...
  </property>
  <property name="notificationListeners">
    <list>
      <ref local="listener"/>
    </list>
  </property>
  <property name="notificationFilters">
    <value>DENY_ALL_TYPES,+test</value>
  </property>
  <property name="handback" value="test handback"/>
</bean>