| Skip Navigation Links | |
| Exit Print View | |
|
Oracle GlassFish Server Message Queue 4.5 Developer's Guide for Java Clients |
| Skip Navigation Links | |
| Exit Print View | |
|
|
Oracle GlassFish Server Message Queue 4.5 Developer's Guide for Java Clients |
3. Message Queue Clients: Design and Features
Balancing Reliability and Performance
Thread Allocation for Connections
Advantages and Limitations of Compression
Managing the Dead Message Queue
Managing Physical Destination Limits
Programming Issues for Message Consumers
Using the Client Runtime Ping Feature
Preventing Message Loss for Synchronous Consumers
Synchronous Consumption in Distributed Applications
Delivery Mode (Persistent/Nonpersistent)
Durable vs. Nondurable Subscriptions
Use of Selectors (Message Filtering)
Creating a Consumer Event Listener
Consumer Event Listener Examples
Client Connection Failover (Auto-Reconnect)
Parallel Broker Auto-Reconnect
Clustered-Broker Auto-Reconnect
Handling Exceptions When Failover Occurs
Handling Exceptions in a Transacted Session
Transacted Session: Failover Producer Example
Transacted Session: Failover Consumer Example
Handling Exceptions in a Non-Transacted Session
Logging Name Spaces, Levels, and Activities
Using the JRE Logging Configuration File
Using a Logging Configuration File for a Specific Application
Setting the Logging Configuration Programmatically
4. Using the Metrics Monitoring API
6. Embedding a Message Queue Broker in a Java Client
This Message Queue feature enables validation of the content of a text (not object) XML message against an XML schema at the point the message is sent to the broker.
When XML validation is enabled, the Message Queue client runtime will attempt to validate an XML message against specified XSDs before sending the message to the broker. The location of the XML schema (XSD) is specified as a property of a Message Queue destination. If the specified schema cannot be located or the message cannot be validated, the message is not sent, and an exception is thrown.
If no XSD location is specified, the DTD declaration within the XML document is used to perform DTD validation. (XSD validation, which includes data type and value range validation, is more rigorous than DTD validation.)
Client applications using this feature should upgrade Java SE version to JRE 1.5 or above.
XML schema validation is enabled using the following physical destination properties: validateXMLSchemaEnabled, XMLSchemaURIList, and reloadXMLSchemaOnFailure. These properties are described in Chapter 18, Physical Destination Property Reference, in Oracle GlassFish Server Message Queue 4.5 Administration Guide. The property values can be set at destination creation or update time by using the imqcmd create dst or imqcmd update dst command, respectively. The XML validation properties should be set when a destination is inactive: that is, when it has no consumers and producers, and when there are no messages in the destination.
If any of the XML validation properties are set while a destination is active (for example, if a producer is connected to the destination), the change will not take effect until the producer reconnects to the broker. Similarly, if an XSD is changed, as a result of changing application requirements, all client applications producing XML messages based on the changed XSD must reconnect to the broker.
If the reloadXMLSchemaOnFailure property is set to true and XML validation fails, then the Message Queue client runtime will attempt to reload the XSD before attempting again to validate a message. The client runtime will throw an exception if the validation fails using the reloaded XSD.
|