Sun Java System Message Queue 4.2 Release Notes

Schema Validation of XML Payload Messages

This new feature in Message Queue 4.2 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. The location of the XML schema (XSD) is specified as a property of a Message Queue destination. 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 new feature should upgrade Java SE version to JRE 1.5 or above.

To enable XML schema validation, you set the following physical destination properties:

Table 1–5 Physical Destination Properties for XML Schema Validation



Default Value 





XML schema validation is enabled? 

If set to false or not set, then XML schema validation is not enabled for the destination.




Space separated list of XML schema document (XSD) URI strings  

The URIs point to the location of one or more XSDs to use for XML schema validation, if enabled.  

Use double quotes around this value if multiple URIs are specified. 



If this property is not set or null and XML validation is enabled, XML validation is performed using a DTD specified in the XML document. 




Reload XML schema on failure enabled? 

If set to false or not set, then the schema is not reloaded if validation fails. 

When XML validation is enabled, the Message Queue client runtime will attempt to validate an XML message against the specified XSDs (or against the DTD, if no XSD is specified) before sending it to the broker. If the specified schema cannot be located or the message cannot be validated, the message is not sent, and an exception is thrown.

The XML validation properties 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.

Note –

If an XSD is not accessible at runtime, it might be necessary to modify the XMLSchemaURIList while a destination is active.

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 SXD.