Configure deployment properties for a JCA 1.5-compliant message-driven bean
Configuring deployment properties for a JCA 1.5-compliant message-driven bean
Use this task to configure the message-driven bean deployment properties for a JCA 1.5-compliant enterprise bean, to override the deployment properties defined within the application EAR file.
Why and when to perform this task
You can configure the deployment attributes of an application by using an
assembly tool such as the Application Server Toolkit (AST) or Rational Web Developer.
This task description assumes that you have an EAR file, which contains
an application enterprise bean developed as a message-driven bean, that can be deployed in WebSphere Application Server. For more details about assembling applications, see assembling applications.
Create or edit the application EAR file. For example, to change attributes of an existing application, use the import wizard to import the EAR file into the assembly tool. To start the import wizard:
Click File-> Import-> EAR file
Click Next , then select the EAR file.
Click Finish
In the J2EE Hierarchy view, right-click the EJB
module for the message-driven bean , then click Open With > Deployment Descriptor Editor . A property dialog notebook for the message-driven bean is displayed in the property pane.
Use the EJB deployment descriptor editor to review and, if needed, change the deployment properties.
In the property pane, select the Beans tab.
Under Activation Configuration, review the following properties:
Acknowledge mode
How the session acknowledges any messages it receives.
This property applies only to message-driven beans that uses bean-managed transaction demarcation (Transaction type is set to Bean).
Auto Acknowledge
The session automatically acknowledges a message when it has either successfully returned from a call to receive, or the message listener it has called to process the message successfully returns.
Dups OK Acknowledge
The session lazily acknowledges the delivery of messages. This is likely to result in the delivery of some duplicate messages if JMS fails, so it should be used only by consumers that are tolerant of duplicate messages.
As defined in the EJB specification, clients cannot use using Message.acknowledge()
to acknowledge messages. If a value of CLIENT_ACKNOWLEDGE is passed on the createxxxSession call, then messages are automatically acknowledged by the application server and Message.acknowledge() is not used.
Destination type
Whether the message bean uses a queue or topic destination.
Queue
The message bean uses a queue destination.
Topic
The message bean uses a topic destination.
Durability
Whether a JMS topic subscription is durable or non-durable.
Durable
A subscriber registers a durable subscription with a unique identity that is retained by JMS. Subsequent subscriber objects with the same identity resume the subscription in the state it was left in by the earlier subscriber. If there is no active subscriber for a durable subscription, JMS retains the subscription's messages until they are received by the subscription or until they expire.
Nondurable
Non-durable subscriptions last for the lifetime of their subscriber object.
This means that a client sees the messages published on a topic only while its subscriber is active. If the subscriber is not active, the client is missing messages published on its topic.
A non-durable subscriber can only be used in the same transactional context (for example, a global transaction or an unspecified transaction context) that existed when the subscriber was created.
For more information about this context restriction, see
The effect of transaction context on non-durable subscribers.
Message selector
The JMS message selector to be used to determine which messages the message bean receives; for example:
JMSType='car' AND color='blue' AND weight>2500
The selector string can refer to fields in the JMS message header and fields in the message properties. Message selectors cannot reference message body values.
Under WebSphere Bindings, select the JCA Adapter option then specify the bindings deployment properties:
ActivationSpec JNDI name
Type the JNDI name of the J2C activation specification that is to be used to deploy this message-driven bean. This name must match the name of a J2C
activation specification that you define to WebSphere Application Server.
The name of a J2C authentication alias used for authentication of connections to the JCA resource adapter. A J2C authentication alias specifies the user ID and password that is used to authenticate the creation of a new connection to the JCA resource adapter.
Destination JNDI name
Type the JNDI name that the message-driven bean uses to look up the JMS
destination in the JNDI name space.
Save your changes to the deployment descriptor.
Close the deployment descriptor editor.
When prompted, click Yes to indicate that you want to save changes to the deployment descriptor.
From the popup menu of the project, click
Deploy to generate EJB deployment code.
Optional: Test your completed module on a WebSphere Application Server installation. Right-click a module, click
Run on Server , and follow the instructions in the displayed wizard. Note that Run on Server works on the Windows, Linux/Intel, and AIX operating systems only; you cannot deploy remotely from the Application Server Toolkit (AST) or Rational Web Developer to a WebSphere Application Server installation on a UNIX operating system such as Solaris.
Important
Note: Use
Run On Server for unit testing only. The Application Server Toolkit (AST)
or Rational Web Developer controls the WebSphere Application Server installation and, when an application is published remotely, the assembly tool overwrites the server configuration file for that server. Do not use on production servers.
What to do next
After assembling your application, use a systems management tool to deploy the EAR file onto the application server that is to run the application; for example, using
the administrative console as described in Deploying and managing applications.