Creating a Java Message-Driven Bean with ActiveMQ in NetBeans

A Java Message-Driven Bean (MDB) is a practical way to process JMS messages asynchronously. Instead of making a web request wait for a long-running operation, an application can place work on an ActiveMQ queue and let an enterprise bean consume it in the background.

NetBeans makes the workflow approachable: create the enterprise project, add the bean, configure the messaging destination, deploy the ActiveMQ resource adapter, and test the producer and consumer. This approach suits Australian systems that process online orders from Sydney, service bookings in Melbourne, or notifications across several time zones.

Choose Compatible Java And Messaging Versions

Before opening NetBeans, decide whether the application uses the older javax.* namespace or the newer jakarta.* namespace. ActiveMQ Classic integrations commonly appear in Java EE 8 examples using javax.jms, while newer Jakarta EE servers require Jakarta-compatible libraries and resource adapters. Mixing these namespaces usually produces deployment errors that look unrelated to the bean itself.

Use a supported JDK, NetBeans version, and application server combination. Payara, GlassFish, and WildFly can host MDBs, but their ActiveMQ setup differs. The NetBeans development hub provides broader IDE and Java background material, while the project documentation for the chosen server should be treated as the authority for connector configuration.

For a small demonstration, ActiveMQ Classic is easy to understand. For a new production system, compare it with ActiveMQ Artemis and confirm that the server, JMS client, and connector all target the same API generation.

Create The Message-Driven Bean

In NetBeans, create a Maven Enterprise Application or an EJB Module, depending on the deployment layout. Add a Message-Driven Bean through the New Enterprise Bean wizard, select JMS as the message destination type, and set the destination lookup name. A queue is appropriate when one consumer should process each message; a topic is better when several subscribers need a copy.

A simple bean might look like this:

import jakarta.ejb.ActivationConfigProperty;
import jakarta.ejb.MessageDriven;
import jakarta.jms.JMSException;
import jakarta.jms.Message;
import jakarta.jms.MessageListener;
import jakarta.jms.TextMessage;

@MessageDriven(
    activationConfig = {
        @ActivationConfigProperty(
            propertyName = "destinationType",
            propertyValue = "jakarta.jms.Queue"
        ),
        @ActivationConfigProperty(
            propertyName = "destinationLookup",
            propertyValue = "java:/jms/queue/orders"
        )
    }
)
public class OrderListener implements MessageListener {

    @Override
    public void onMessage(Message message) {
        try {
            if (message instanceof TextMessage textMessage) {
                System.out.println("Received: " + textMessage.getText());
            }
        } catch (JMSException ex) {
            throw new IllegalStateException("Unable to read JMS message", ex);
        }
    }
}

With a javax.ejb server, replace the jakarta imports and activation property names with the values expected by that platform. An MDB should keep its onMessage method short, pass business work to a service, and avoid creating unmanaged threads.

Connect ActiveMQ To The Application Server

Install ActiveMQ separately and create a queue such as orders. Then install its resource adapter into the application server. The adapter bridges the JMS broker and the server’s managed component environment, allowing the container to control transactions, pooling, security, and delivery retries.

The exact JNDI names depend on the server. A common arrangement is an administered queue bound as java:/jms/queue/orders, with a connection factory such as java:/JmsXA. The bean’s destinationLookup must match the queue binding exactly. If the names differ by one character, deployment may succeed while message delivery fails.

Component	Example value	Purpose
Broker	ActiveMQ Classic	Stores and routes JMS messages
Destination	orders queue	Holds pending order events
JNDI queue	java:/jms/queue/orders	Lookup name used by the MDB
Connection factory	java:/JmsXA	Managed connection to the broker
Consumer	OrderListener	Receives and processes messages

NetBeans is useful for editing descriptors, building the Maven project, viewing server logs, and redeploying quickly. For comparison, a modern Micronaut NetBeans example shows a lighter application style, but Micronaut messaging is configured differently from a container-managed EJB.

Send And Test A JMS Message

Create a producer as a servlet, stateless session bean, command-line client, or test class. It should obtain the managed connection factory and queue through JNDI, create a text message, and send it inside a try-with-resources block. The producer does not call the MDB directly; the broker handles delivery.

For a local test, send a payload such as {"orderId":"AU-1042","state":"paid"} and inspect the application-server log. Test duplicate delivery, malformed JSON, broker restarts, and messages that cannot be processed. Australian deployments should also account for AEST, ACST, and AWST timestamps rather than assuming every event arrives in Sydney time.

Operational checks matter when a team supports customers from Brisbane to Perth. Monitor queue depth, consumer count, redeliveries, and dead-letter messages. If an office relies on a variable NBN connection, the broker must be able to reconnect without silently losing work.

Harden Transactions And Production Behaviour

Use container-managed transactions when message processing updates a database or invokes another transactional service. A failure should roll back the work and allow the broker to redeliver the message, subject to a maximum retry policy. Make the business operation idempotent by recording an event identifier or checking whether an order has already been handled.

Keep credentials outside source control and enable TLS when the broker is remote. Log a correlation ID rather than sensitive customer information, especially when handling names, addresses, or payment-related events under Australian Privacy Principles. Performance tuning should focus on measured queue latency and consumer throughput; broader optimisation comparisons, such as React performance approaches, are a useful reminder that caching or concurrency changes need evidence.

A stateful bean can retain conversational data, but an MDB should generally remain stateless between deliveries. The stateful session bean guide helps clarify that distinction. Treat each message as an independent unit, just as a reliable service desk in Adelaide or Canberra would process each ticket with its own audit trail. Even the progression from a first test to a resilient production consumer benefits from incremental refinement, much like the evolution of groundstrokes over time.

Practical Checks Before Deployment

• Confirm that the JDK, NetBeans, application server, JMS API, and ActiveMQ adapter use compatible namespaces.
• Create the queue and connection factory before deploying the enterprise application.
• Match the MDB destination lookup name with the server’s exact JNDI binding.
• Test successful delivery, rollback, duplicate messages, and dead-letter handling.
• Use managed transactions and make message processing idempotent.
• Monitor queue depth, redeliveries, broker connectivity, and timestamps across Australian time zones.