📄 message.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><!--NewPage--><HTML><HEAD><!-- Generated by javadoc (build 1.4.2_02) on Thu Nov 13 17:20:39 PST 2003 --><TITLE>Message (Java 2 Platform Ent. Ed. v1.4)</TITLE><META NAME="keywords" CONTENT="javax.jms.Message interface"><LINK REL ="stylesheet" TYPE="text/css" HREF="../../stylesheet.css" TITLE="Style"><SCRIPT type="text/javascript">function windowTitle(){ parent.document.title="Message (Java 2 Platform Ent. Ed. v1.4)";}</SCRIPT></HEAD><BODY BGCOLOR="white" onload="windowTitle();"><!-- ========= START OF TOP NAVBAR ======= --><A NAME="navbar_top"><!-- --></A><A HREF="#skip-navbar_top" title="Skip navigation links"></A><TABLE BORDER="0" WIDTH="100%" CELLPADDING="1" CELLSPACING="0" SUMMARY=""><TR><TD COLSPAN=3 BGCOLOR="#EEEEFF" CLASS="NavBarCell1"><A NAME="navbar_top_firstrow"><!-- --></A><TABLE BORDER="0" CELLPADDING="0" CELLSPACING="3" SUMMARY=""> <TR ALIGN="center" VALIGN="top"> <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../overview-summary.html"><FONT CLASS="NavBarFont1"><B>Overview</B></FONT></A> </TD> <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="package-summary.html"><FONT CLASS="NavBarFont1"><B>Package</B></FONT></A> </TD> <TD BGCOLOR="#FFFFFF" CLASS="NavBarCell1Rev"> <FONT CLASS="NavBarFont1Rev"><B>Class</B></FONT> </TD> <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="package-tree.html"><FONT CLASS="NavBarFont1"><B>Tree</B></FONT></A> </TD> <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../deprecated-list.html"><FONT CLASS="NavBarFont1"><B>Deprecated</B></FONT></A> </TD> <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../index-all.html"><FONT CLASS="NavBarFont1"><B>Index</B></FONT></A> </TD> <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../help-doc.html"><FONT CLASS="NavBarFont1"><B>Help</B></FONT></A> </TD> </TR></TABLE></TD><TD ALIGN="right" VALIGN="top" ROWSPAN=3><EM><b>Java<sup><font size=-2>TM</font></sup> 2 Platform<br>Ent. Ed. v1.4</b></EM></TD></TR><TR><TD BGCOLOR="white" CLASS="NavBarCell2"><FONT SIZE="-2"> <A HREF="../../javax/jms/MapMessage.html" title="interface in javax.jms"><B>PREV CLASS</B></A> <A HREF="../../javax/jms/MessageConsumer.html" title="interface in javax.jms"><B>NEXT CLASS</B></A></FONT></TD><TD BGCOLOR="white" CLASS="NavBarCell2"><FONT SIZE="-2"> <A HREF="../../index.html" target="_top"><B>FRAMES</B></A> <A HREF="Message.html" target="_top"><B>NO FRAMES</B></A> <SCRIPT type="text/javascript"> <!-- if(window==top) { document.writeln('<A HREF="../../allclasses-noframe.html"><B>All Classes</B></A>'); } //--></SCRIPT><NOSCRIPT> <A HREF="../../allclasses-noframe.html"><B>All Classes</B></A></NOSCRIPT></FONT></TD></TR><TR><TD VALIGN="top" CLASS="NavBarCell3"><FONT SIZE="-2"> SUMMARY: NESTED | <A HREF="#field_summary">FIELD</A> | CONSTR | <A HREF="#method_summary">METHOD</A></FONT></TD><TD VALIGN="top" CLASS="NavBarCell3"><FONT SIZE="-2">DETAIL: <A HREF="#field_detail">FIELD</A> | CONSTR | <A HREF="#method_detail">METHOD</A></FONT></TD></TR></TABLE><A NAME="skip-navbar_top"></A><!-- ========= END OF TOP NAVBAR ========= --><HR><!-- ======== START OF CLASS DATA ======== --><H2><FONT SIZE="-1">javax.jms</FONT><BR>Interface Message</H2><DL><DT><B>All Known Subinterfaces:</B> <DD><A HREF="../../javax/jms/BytesMessage.html" title="interface in javax.jms">BytesMessage</A>, <A HREF="../../javax/jms/MapMessage.html" title="interface in javax.jms">MapMessage</A>, <A HREF="../../javax/jms/ObjectMessage.html" title="interface in javax.jms">ObjectMessage</A>, <A HREF="../../javax/jms/StreamMessage.html" title="interface in javax.jms">StreamMessage</A>, <A HREF="../../javax/jms/TextMessage.html" title="interface in javax.jms">TextMessage</A></DD></DL><HR><DL><DT>public interface <B>Message</B></DL><P>The <CODE>Message</CODE> interface is the root interface of all JMS messages. It defines the message header and the <CODE>acknowledge</CODE> method used for all messages. <P>Most message-oriented middleware (MOM) products treat messages as lightweight entities that consist of a header and a payload. The header contains fields used for message routing and identification; the payload contains the application data being sent. <P>Within this general form, the definition of a message varies significantly across products. It would be quite difficult for the JMS API to support all of these message models. <P>With this in mind, the JMS message model has the following goals: <UL> <LI>Provide a single, unified message API <LI>Provide an API suitable for creating messages that match the format used by provider-native messaging applications <LI>Support the development of heterogeneous applications that span operating systems, machine architectures, and computer languages <LI>Support messages containing objects in the Java programming language ("Java objects") <LI>Support messages containing Extensible Markup Language (XML) pages </UL> <P>JMS messages are composed of the following parts: <UL> <LI>Header - All messages support the same set of header fields. Header fields contain values used by both clients and providers to identify and route messages. <LI>Properties - Each message contains a built-in facility for supporting application-defined property values. Properties provide an efficient mechanism for supporting application-defined message filtering. <LI>Body - The JMS API defines several types of message body, which cover the majority of messaging styles currently in use. </UL> <H4>Message Bodies</H4> <P>The JMS API defines five types of message body: <UL> <LI>Stream - A <CODE>StreamMessage</CODE> object's message body contains a stream of primitive values in the Java programming language ("Java primitives"). It is filled and read sequentially. <LI>Map - A <CODE>MapMessage</CODE> object's message body contains a set of name-value pairs, where names are <CODE>String</CODE> objects, and values are Java primitives. The entries can be accessed sequentially or randomly by name. The order of the entries is undefined. <LI>Text - A <CODE>TextMessage</CODE> object's message body contains a <CODE>java.lang.String</CODE> object. This message type can be used to transport plain-text messages, and XML messages. <LI>Object - An <CODE>ObjectMessage</CODE> object's message body contains a <CODE>Serializable</CODE> Java object. <LI>Bytes - A <CODE>BytesMessage</CODE> object's message body contains a stream of uninterpreted bytes. This message type is for literally encoding a body to match an existing message format. In many cases, it is possible to use one of the other body types, which are easier to use. Although the JMS API allows the use of message properties with byte messages, they are typically not used, since the inclusion of properties may affect the format. </UL> <H4>Message Headers</H4> <P>The <CODE>JMSCorrelationID</CODE> header field is used for linking one message with another. It typically links a reply message with its requesting message. <P><CODE>JMSCorrelationID</CODE> can hold a provider-specific message ID, an application-specific <CODE>String</CODE> object, or a provider-native <CODE>byte[]</CODE> value. <H4>Message Properties</H4> <P>A <CODE>Message</CODE> object contains a built-in facility for supporting application-defined property values. In effect, this provides a mechanism for adding application-specific header fields to a message. <P>Properties allow an application, via message selectors, to have a JMS provider select, or filter, messages on its behalf using application-specific criteria. <P>Property names must obey the rules for a message selector identifier. Property names must not be null, and must not be empty strings. If a property name is set and it is either null or an empty string, an <CODE>IllegalArgumentException</CODE> must be thrown. <P>Property values can be <CODE>boolean</CODE>, <CODE>byte</CODE>, <CODE>short</CODE>, <CODE>int</CODE>, <CODE>long</CODE>, <CODE>float</CODE>, <CODE>double</CODE>, and <CODE>String</CODE>. <P>Property values are set prior to sending a message. When a client receives a message, its properties are in read-only mode. If a client attempts to set properties at this point, a <CODE>MessageNotWriteableException</CODE> is thrown. If <CODE>clearProperties</CODE> is called, the properties can now be both read from and written to. Note that header fields are distinct from properties. Header fields are never in read-only mode. <P>A property value may duplicate a value in a message's body, or it may not. Although JMS does not define a policy for what should or should not be made a property, application developers should note that JMS providers will likely handle data in a message's body more efficiently than data in a message's properties. For best performance, applications should use message properties only when they need to customize a message's header. The primary reason for doing this is to support customized message selection. <P>Message properties support the following conversion table. The marked cases must be supported. The unmarked cases must throw a <CODE>JMSException</CODE>. The <CODE>String</CODE>-to-primitive conversions may throw a runtime exception if the primitive's <CODE>valueOf</CODE> method does not accept the <CODE>String</CODE> as a valid representation of the primitive. <P>A value written as the row type can be read as the column type. <PRE> | | boolean byte short int long float double String |---------------------------------------------------------- |boolean | X X |byte | X X X X X |short | X X X X |int | X X X |long | X X |float | X X X |double | X X |String | X X X X X X X X |---------------------------------------------------------- </PRE> <P>In addition to the type-specific set/get methods for properties, JMS provides the <CODE>setObjectProperty</CODE> and <CODE>getObjectProperty</CODE> methods. These support the same set of property types using the objectified primitive values. Their purpose is to allow the decision of property type to made at execution time rather than at compile time. They support the same property value conversions. <P>The <CODE>setObjectProperty</CODE> method accepts values of class <CODE>Boolean</CODE>, <CODE>Byte</CODE>, <CODE>Short</CODE>, <CODE>Integer</CODE>, <CODE>Long</CODE>, <CODE>Float</CODE>, <CODE>Double</CODE>, and <CODE>String</CODE>. An attempt to use any other class must throw a <CODE>JMSException</CODE>. <P>The <CODE>getObjectProperty</CODE> method only returns values of class <CODE>Boolean</CODE>, <CODE>Byte</CODE>, <CODE>Short</CODE>, <CODE>Integer</CODE>, <CODE>Long</CODE>, <CODE>Float</CODE>, <CODE>Double</CODE>, and <CODE>String</CODE>. <P>The order of property values is not defined. To iterate through a message's property values, use <CODE>getPropertyNames</CODE> to retrieve a property name enumeration and then use the various property get methods to retrieve their values. <P>A message's properties are deleted by the <CODE>clearProperties</CODE> method. This leaves the message with an empty set of properties. <P>Getting a property value for a name which has not been set returns a null value. Only the <CODE>getStringProperty</CODE> and <CODE>getObjectProperty</CODE> methods can return a null value. Attempting to read a null value as a primitive type must be treated as calling the primitive's corresponding <CODE>valueOf(String)</CODE> conversion method with a null value. <P>The JMS API reserves the <CODE>JMSX</CODE> property name prefix for JMS defined properties. The full set of these properties is defined in the Java Message Service specification. New JMS defined properties may be added in later versions of the JMS API. Support for these properties is optional. The <CODE>String[] ConnectionMetaData.getJMSXPropertyNames</CODE> method returns the names of the JMSX properties supported by a connection. <P>JMSX properties may be referenced in message selectors whether or not they are supported by a connection. If they are not present in a message, they are treated like any other absent property.⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -