Creating a JMS Queue With NetBeans and GlassFish

Java Message Service (JMS) provides a reliable way for applications to exchange work asynchronously. Instead of making one component wait for another to finish, a producer places a message on a queue and a consumer processes it when ready.

NetBeans IDE and GlassFish work well together for learning and testing Java EE or Jakarta EE messaging. The main tasks are selecting compatible versions, creating a broker destination, exposing it through JNDI, and deploying a producer or message-driven bean.

The same pattern suits order processing, email dispatch, document conversion, and background jobs. For an Australian development team in Sydney, Melbourne, or Brisbane, it can also help separate customer-facing requests from slower services running in a different availability zone or office.

Choose A Compatible Java EE Stack

Before creating resources, check whether the application uses the older Java EE namespace or the newer Jakarta EE namespace. Java EE applications generally import javax.jms.*, while Jakarta EE applications use jakarta.jms.*. The GlassFish version, JDK, NetBeans project type, and libraries must agree.

GlassFish 5 commonly appears in Java EE tutorials, while newer releases target Jakarta EE and modern JDK versions. Select a supported JDK such as Java 11 or Java 17 according to the server release. A namespace mismatch can produce deployment errors even when the queue configuration appears correct.

Prepare The GlassFish Server

Start the GlassFish domain and open the administrative console, usually at http://localhost:4848. In NetBeans, open the Services window, register the GlassFish server, and verify that the server starts without authentication or port conflicts.

The JMS service should be enabled in the server configuration. GlassFish uses an embedded or configured message broker, commonly OpenMQ, to hold messages. For a local project, the default broker is usually sufficient; a production installation should use deliberate persistence, resource limits, monitoring, and access controls.

Create JMS Resources

In the GlassFish console, open Resources, JMS Resources, and create a connection factory. Give it a JNDI name such as jms/OrdersConnectionFactory, select the appropriate connection-factory type, and save it. The JNDI name is the stable application-facing reference.

Create a destination resource with a name such as jms/OrdersQueue. Set its type to Queue and provide a physical destination name, for example OrdersQueue. A queue has one logical stream of messages: each message is normally delivered to one competing consumer rather than broadcast to every consumer.

Configure The NetBeans Project

Create a Maven or Gradle enterprise application in NetBeans and add the required JMS API through the application server or project dependencies. Avoid packaging a second incompatible JMS implementation inside the application unless the server documentation specifically requires it.

Inject the resources with JNDI lookups, for example @Resource(lookup = "jms/OrdersConnectionFactory"). A producer can obtain a JMSContext, create a producer, and send text or JSON to jms/OrdersQueue. NetBeans’ code completion and deployment integration make it easier to spot incorrect imports and descriptors. For server-side diagnostics, keep this remote debugging guide nearby when the GlassFish instance runs on another host.

Send And Consume Messages

A message-driven bean is the usual JMS consumer in an enterprise application. It listens to the queue and receives messages through an onMessage method. Its activation configuration identifies the destination and destination type, while the container manages pooling, transactions, and invocation.

Use the message-driven bean tutorial when wiring a consumer into the project. Keep the handler short and reliable: validate the payload, call the business service, and allow failures to trigger rollback where appropriate. Long-running work may need a separate job design rather than blocking a JMS delivery thread.

For a simple producer, send a message such as an order number or a JSON document. A text message is easy to inspect during development, but production payloads should have a version field, correlation ID, and enough metadata to support retries and tracing.

Deploy And Test The Queue

Build and deploy the application from NetBeans, then watch the GlassFish server log for resource lookup, authentication, and bean initialisation errors. A missing JNDI name is one of the most common causes of failure, followed by an incorrect javax or jakarta import.

Test both normal processing and failure behaviour. Send several messages, stop the consumer, and confirm that messages remain available according to the broker’s delivery settings. Restart the consumer and verify that pending messages are processed without accidental duplication.

Use the GlassFish monitoring tools or broker administration commands to inspect queue depth and consumer counts. Logs should include correlation IDs rather than private customer details. Teams working across Australian Eastern Standard Time and daylight-saving periods should record timestamps in UTC and convert them only for local displays.

Operate Safely In Australian Environments

A queue can carry names, addresses, payment references, or health-related information, so apply the Australian Privacy Act 1988 and the organisation’s data-handling policy. The law does not automatically require every workload to remain in Australia, but contracts and sector rules may require an Australian cloud region, controlled retention, or documented access procedures.

For businesses serving customers across Australia, design for uneven traffic rather than assuming a constant message rate. A Melbourne retailer may experience a campaign spike while a Brisbane service team is offline, and a queue can absorb that difference. Configure persistence, maximum message size, retry handling, and a dead-letter strategy before moving beyond local testing.

Checks Before Deployment

  • Confirm that the JDK, NetBeans, GlassFish, and JMS namespace are compatible.
  • Verify both JNDI resources from the GlassFish console.
  • Test messages while the consumer is stopped and restarted.
  • Configure transactions, retries, and a dead-letter destination.
  • Remove sensitive payload data from ordinary logs.
  • Review Australian privacy, retention, and cloud-region requirements.