Open ESB & GlassFish: JMS messaging (part 2)

The long awaited follow-up to Open ESB & GlassFish: JMS messaging (part 1) is finally here...well, long awaited for me that is :) I've been waiting since March to get back to OpenESB and GlassFish to implement our business use case. My hope for this post was to have GlassFish working with ActiveMQ embedded in Geronimo but I'm not quite there yet. However, I feel confident that I have a solution that will work.

First a quick review on what I was trying to do in part 1. My initial approach to integrating ActiveMQ embedded in Geronimo, was to configure ActiveMQ's resource adapter in GlassFish in order for my business processes to use a set of queues in Geronimo. One thing I realized is that the configuration for my initial approach was taking me down a path of using ActiveMQ in Geronimo for all queuing which was not what I wanted to do. I just wanted to access a set of queues in Geronimo from business processes deployed in GlassFish and use the embedded queuing support in GlassFish for other JMS activity. So I had to start again with my trusty pal Google and it turned up Ramesh Parthasarathy's Blog GlassFish V2 and ActiveMQ 4.1.

Remesh's post describes how to use the generic JMS resource adapter available in GlassFish make ActiveMQ queues available to components deployed in GlassFish. When you get it working your component (MDB) references the ActiveMQ queue through a typical resource reference as you would for a Datasource or other EJBs. The generic resource adapter provides a "bridge" by using JNDI. Some observations about the generic ra support in GlassFish:

What I like:

• The concept of accessing remote queues as resource references. This is something all J2EE developers understand and can use.
• No coding...this is all configuration based. You do have to code up and configure an MDB to access a remote queue.
  

What I don't like:

• Lots of configuration. I can't pin this on GlassFish, J2EE applications in general have a lot of configuration which lends themselves to delicate deployments. Java EE 5 has made it a lot easier with annotations and dependency injection. However, because of limitations with annotations (i.e. not being able to specify what resource adapter you want to use) I have to use J2EE 1.4.
• The use of com.sun.jndi.fscontext.RefFSContextFactory. This file system-based context factory works fine. However, you need to create and maintain the .bindings file for the generic ra. For example, this means if you create a new queue in ActiveMQ or change a queue name you have to update the .bindings file. I hope to experiment with other context factories within Geronimo but for now I'll continue with the FS context factory.

What concerns me:

• Stability and availability. I've experienced some issues with GlassFish not recovering when ActiveMQ is not available and becomes available again.
• Transactional oddities...I'm currently dealing with some odd container-managed transactional exceptions with my MDB using the ActiveMQ queues that I cannot reproduce. Hopefully this is just a configuration problem.

What is next for me is to work through the transaction exceptions and then test the solution with Geronimo. Initial tests are encouraging which should not be a surprise because ActiveMQ is embedded in Geronimo. After that it's onto building the BPEL processes and supporting components.