JMS CTS: The JMS Compliance Test Suite

selector.null

A null message selector indicates that there is no message selector for the message consumer.

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

org.exolab.jmscts.test.selector.EmptySelectorTest.testNull

selector.empty

If the value of a message selector is an empty string, the value is treated as a null and indicates that there is no message selector for the message consumer.

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

org.exolab.jmscts.test.selector.EmptySelectorTest.testEmpty

selector.evaluation.order

The order of evaluation of a message selector is from left to right within precedence level. Parentheses can be used to change this order.

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

A string literal is enclosed in single quotes, with an included single quote represented by doubled single quote; for example, 'literal' and 'literal''s'.

String literals use the Unicode character encoding.

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

org.exolab.jmscts.test.selector.StringTest.testCaseComparison1
org.exolab.jmscts.test.se lector.StringTest.testCaseComparison2
org.exolab.jmscts.test.selector.StringTest.testCaseComparison3
org.exolab.jmscts.test.selector.StringTest.testCheckSingleQuotes1
org.exolab.jmscts.test.selector.StringTest.testCheckSingleQuotes2
org.exolab.jmscts.test.selector.StringTest.testEquals
org.exolab.jmscts.test.selector.StringTest.testEqualsProperty

selector.literal.exactnumeric

An exact numeric literal is a numeric value without a decimal point, such as 57, -957, +62; numbers in the range of Java long are supported. Exact numeric literals use the Java integer literal syntax.

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

selector.literal.approxnumeric

An approximate numeric literal is a numeric value in scientific notation, such as 7E3 and -57.9E2, or a numeric value with a decimal, such as 7., -95.7, and +6.2; numbers in the range of Java double are supported. Approximate literals use the Java floating-point literal syntax.

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

org.exolab.jmscts.test.selector.FloatTest.testEquals1
org.exolab.jmscts.test.selector.FloatTest.testEquals2
org.exolab.jmscts.test.selector.FloatTest.testEquals3
org.exolab.jmscts.test.selector.FloatTest.testEquals4
org.exolab.jmscts.test.selector.FloatTest.testEquals5
org.exolab.jmscts.test.selector.FloatTest.testEquals6
org.exolab.jmscts.test.selector.FloatTest.testEqualsProperty
org.exolab.jmscts.test.selector.FloatTest.testGreaterEquals1
org.exolab.jmscts.test.selector.FloatTest.testGrea terEquals2
org.exolab.jmscts.test.selector.FloatTest.testGreaterThan1
org.exolab.jmscts.test.selector.FloatTest.testGreaterThan2
org.exolab.jmscts.test.selector.FloatTest.testLessEquals1
org.exolab.jmscts.test.selector.FloatTest.testLessEquals2
org.exolab.jmscts.test.selector.FloatTest.testLessThan1
org.exolab.jmscts.test.selector.FloatTest.testLessThan2
org.exolab.jmscts.test.selector.FloatTest.testNotEquals1
org.exolab.jmscts.test.selector.FloatTest.testNotEquals2
org.exolab.jmscts.test.selector.FloatTest.testNotEquals3
org.exolab.jmscts.test.selector.FloatTest.testNotEqualsProperty
org.exolab.jmscts.test.selector.FloatTest.testNumericRange
org.exolab.jmscts.test.selector.FloatTest.testUnaryMinus1
org.exolab.jmscts.test.selector.FloatTest.testUnaryMinus2
org.exolab.jmscts.test.selector.FloatTest.testUnaryMinus3

selector.literal.boolean

A boolean literal is one of TRUE or FALSE.

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

org.exolab.jmscts.test.selector.BooleanTest.testFalse
org.exolab.jmscts.test.selector.BooleanTest.testFalseCase
org.exolab.jmscts.test.selector.BooleanTest.testTrue
org.exolab.jmscts.test.selector.BooleanTest.testTrueCase

selector.identifier.name

An identifier is an unlimited-length character sequence that must begin with a Java identifier start character; all following characters must be Java identifier part characters. An identifier start character is any character for which the method Character.isJavaIdentifierStart returns true. This includes '_' and '$'. An identifier part character is any character for which the method Character.isJavaIdentifierPart returns true.

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

org.exolab.jmscts.test.selector.IdentifierTest.testDollars
org.exolab.jmscts.test.selector.IdentifierTest.testInvalid1
org.exolab.jmscts.test.selector.IdentifierTest.testInvalid2
org.exolab.jmscts.test.selector.IdentifierTest.testUnderscores

selector.identifier.case

Identifiers are case sensitive.

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

org.exolab.jmscts.test.selector.IdentifierTest.testUserIdentifierCase
org.exolab.jmscts.test.selector.JMSPriorityTest.testJMSPriorityCase

selector.reservedwords

Identifiers cannot be the words NULL, TRUE, FALSE, NOT, AND, OR, BETWEEN, LIKE, IN, IS, or ESCAPE. These are case-insensitive reserved words.

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

selector.reservedwords.case

Reserved words are case-insensitive.

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

org.exolab.jmscts.test.selector.BetweenOperatorTest.testBetween3
org.exolab.jmscts.test.selector.BetweenOperatorTest.testNotBetween4
org.exolab.jmscts.test.selector.AndOperatorTest.testAndCase
org.exolab.jmscts.test.selector.BooleanTest.testFalse
org.exolab.jmscts.test.selector.BooleanTest.testF alseCase
org.exolab.jmscts.test.selector.BooleanTest.testTrue
org.exolab.jmscts.test.selector.BooleanTest.testTrueCase

selector.property.conversion

The conversions that apply to the get methods for properties do not apply when a property is used in a message selector expression. For example, suppose you set a property as a string value, as in the following:

myMessage.setStringProperty("NumberOfOrders", "2");

The following expression in a message selector would evaluate to false, because a string cannot be used in an arithmetic expression: "NumberOfOrders > 1"

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

selector.identifier.header

Message header field references are restricted to JMSDeliveryMode, JMSPriority, JMSMessageID, JMSTimestamp, JMSCorrelationID, and JMSType. JMSMessageID, JMSCorrelationID, and JMSType values may be null and if so are treated as a NULL value. TODO - need to test some of these in code

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

org.exolab.jmscts.test.selector.JMSTimestampTest.testJMSTimestamp1
org.exolab.jmscts.test.selector.JMSTimestampTest.testJMSTimestamp2
org.exolab.jmscts.test.selector.JMSTimestampTest.testJMSTimestamp3
org.exolab.jmscts.test.selector.JMSPriorityTest.testJMSPriority
org.exolab.jmscts.test.selector.JMSDeliveryModeTest.testJMSDeliveryMode

selector.properties.JMSprefixed

Any name beginning with 'JMSX' is a JMS defined property name .

Any name beginning with 'JMS_' is a provider-specific property name.

Any name that does not begin with 'JMS' is an application-specific property name.

NOTE: cannot realistically test JMS_ properties.

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

selector.whitespace

Whitespace is the same as that defined for Java: space, horizontal tab, form feed and line terminator.

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

selector.expression

A selector is a conditional expression; a selector that evaluates to true matches; a selector that evaluates to false or unknown does not match.

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

org.exolab.jmscts.test.selector.JMSTimestampTest.testJMSTimestamp1
org.exolab.jmscts.test.selector.JMSTimestampTest.testJMSTimestamp2
org.exolab.jmscts.test.selector.JMSTimestampTest.testJMSTimestamp3
org.exolab.jmscts.test.selector.IdentifierTest.testDollars
org.exolab.jmscts.test.selector.IdentifierTest.testUnderscores
org.exolab.jmscts.test.selector.IdentifierTest.testUserIdentifierCase
org.exolab.jmscts.test.selector.StringTest.testCaseComparison1
org.exolab.jmscts.test.selector.StringTest.testCaseComparison2
org.exolab.jmscts.test.selector.StringTest.testCaseComparison3
org.exolab.jmscts.test.selector.StringTest.testCheckSingleQuotes1
org.exolab.jmscts.test.selector.StringTest.testCheckSingleQuotes2
org.exola b.jmscts.test.selector.StringTest.testEquals
org.exolab.jmscts.test.selector.StringTest.testEqualsProperty
org.exolab.jmscts.test.selector.JMSPriorityTest.testJMSPriority
org.exolab.jmscts.test.selector.JMSPriorityTest.testJMSPriorityCase
org.exolab.jmscts.test.selector.BetweenOperatorTest.testBetween1
org.exolab.jmscts.test.selector.BetweenOperatorTest.testBetween2
org.exolab.jmscts.test.selector.BetweenOperatorTest.testBetween3
org.exolab.jmscts.test.selector.BetweenOperatorTest.testBetween4
org.exolab.jmscts.test.selector.BetweenOperatorTest.testBetween5
org.exolab.jmscts.test.selector.BetweenOperatorTest.testBetween6
org.exolab.jmscts.test.selector.BetweenOperatorTest.testNotBetween1
org.exolab.jmscts.test.selector.BetweenOperatorTest.testNotBetween2
org.exolab.jmscts.test.selector.BetweenOperatorTest.testNotBetween3
org.exolab.jmscts.test.selector.BetweenOperatorTest.testNotBetween4
org.exolab.jmscts.test.selector.BetweenOperatorTest.testNotBetween5
org.exolab.jmscts.test.selector.BetweenOperatorTest.testUnsetProperty1
org.exolab.jmscts.test.selector.BetweenOperatorTest.testUnsetProperty2
org.exolab.jmscts.test.selector.BetweenOperatorTest.testUnsetProperty3
org.exolab.jmscts.test.selector.FloatTest.testDivisionByZero
org.exolab.jmscts.test.selector.FloatTest.testDoubleNaN1
org.exolab.jmscts.test.selector.FloatTest.testDoubleNaN2
org.exolab.jmscts.test.selector.FloatTest.testEquals1
org.exolab.jmscts.test.selector.FloatTest.testEquals2
org.exolab.jmscts.test.selector.FloatTest.testEquals3
org.exolab.jmscts.test.selector.FloatTest.testEquals4
org.exolab.jmscts.test.selector.FloatTest.testEquals5
org.exolab.jmscts.test.selector.FloatTest.testEquals6
org.exolab.jmscts.test.selector.FloatTest.testEqualsProperty
org.exolab.jmscts.test.sel ector.FloatTest.testFloatNaN1
org.exolab.jmscts.test.selector.FloatTest.testFloatNaN2
org.exolab.jmscts.test.selector.FloatTest.testGreaterEquals1
org.exolab.jmscts.test.selector.FloatTest.testGreaterEquals2
org.exolab.jmscts.test.selector.FloatTest.testGreaterThan1
org.exolab.jmscts.test.selector.FloatTest.testGreaterThan2
org.exolab.jmscts.test.selector.FloatTest.testLessEquals1
org.exolab.jmscts.test.selector.FloatTest.testLessEquals2
org.exolab.jmscts.test.selector.FloatTest.testLessThan1
org.exolab.jmscts.test.selector.FloatTest.testLessThan2
org.exolab.jmscts.test.selector.FloatTest.testNotEquals1
org.exolab.jmscts.test.selector.FloatTest.testNotEquals2
org.exolab.jmscts.test.selector.FloatTest.testNotEquals3
org.exolab.jmscts.test.selector.FloatTest.testNotEqualsProperty
org.exolab.jmscts.test.selector.FloatTest.testNumericRange
org.exolab.jmscts.test.selector.FloatTest.testUnaryMinus1
org.exolab.jmscts.test.selector.FloatTest.testUnaryMinus2
org.exolab.jmscts.test.selector.FloatTest.testUnaryMinus3
org.exolab.jmscts.test.selector.FloatTest.testUnsetProperty1
org.exolab.jmscts.test.selector.FloatTest.testUnsetProperty2
org.exolab.jmscts.test.selector.FloatTest.testUnsetProperty3
org.exolab.jmscts.test.selector.FloatTest.testUnsetProperty4
org.exolab.jmscts.test.selector.FloatTest.testUnsetProperty5
org.exolab.jmscts.test.selector.FloatTest.testUnsetProperty6
org.exolab.jmscts.test.selector.FloatTest.testUnsetProperty7
org.exolab.jmscts.test.selector.FloatTest.testUnsetProperty8
org.exolab.jmscts.test.selector.JMSDeliveryModeTest.testJMSDeliveryMode
org.exolab.jmscts.test.selector.AndOperatorTest.testAnd1
org.exolab.jmscts.test.selector.AndOperatorTest.testAnd2
org.exolab.jmscts.test.selector.AndOperatorTest.testAnd3
org.exolab.jmscts.test.selector.AndOperatorTest.testAnd4
org.exolab.jmscts.test.selector.AndOperatorTest.testAndCase
org.exolab.jmscts.test.selector.AndOperatorTest.testUnsetProperty1
org.exolab.jmscts.test.selector.AndOperatorTest.testUnsetProperty2
org.exolab.jmscts.test.selector.AndOperatorTest.testUnsetProperty3
org.exolab.jmscts.test.selector.AndOperatorTest.testUnsetProperty4
org.exolab.jmscts.test.selector.AndOperatorTest.testUnsetProperty5
org.exolab.jmscts.test.selector.BooleanTest.testEquals1
org.exolab.jmscts.test.selector.BooleanTest.testEquals2
org.exolab.jmscts.test.selector.BooleanTest.testFalse
org.exolab.jmscts.test.selector.BooleanTest.testFalseCase
org.exolab.jmscts.test.selector.BooleanTest.testNotEquals1
org.exolab.jmscts.test.selector.BooleanTest.testNotEquals2
org.exolab.jmscts.test.selector.BooleanTest.testTrue
org.exolab.jmscts.test.selector.BooleanTest.testTrueCase

selector.expression.arithmetic

Arithmetic expressions are composed of themselves, arithmetic operations, identifiers with numeric values, and numeric literals.

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

selector.expression.condition

Conditional expressions are composed of themselves, comparison operations, logical operations, identifiers with boolean values, and boolean literals.

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

selector.operator.logical.precedence

Logical operators in order of precedence:

NOT
AND
OR

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

selector.operator.comparison.precedence

Comparison operators in order of precedence:

=
>
> =
<
< =
< > (not equal)

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

selector.operator.arithmetic.precedence

Arithmetic operators in order of precedence are:

+, - (unary)
*, / (multiplication and division)
+, - (addition and subtraction)

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

selector.operator.comparison.types

Only like type values can be compared. One exception is that it is valid to compare exact numeric values and approximate numeric values (the type conversion required is defined by the rules of Java numeric promotion). If the comparison of non-like type values is attempted, the value of the operation is false. If either of the type values evaluates to NULL, the value of the expression is unknown.

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

selector.comparison.boolean

Boolean comparison is restricted to = and < >

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

org.exolab.jmscts.test.selector.BooleanTest.testEquals1
org.exolab.jmscts.test.selector.BooleanTest.testEquals2
org.exolab.jmscts.test.selector.BooleanTest.testGreaterEquals
org.exolab.jmscts.test.selector.BooleanTest.testGreaterThan
org.exolab.jmscts.test.selector.BooleanTest.testLessEquals
org.exolab.jmscts.test.selector.BooleanTest.testLessThan
org.exolab.jmscts.test.selector.BooleanTest.testNotEquals1
org.exolab.jmscts.test.selector.BooleanTest.testNotEquals2

selector.comparison.string

String comparison is restricted to = and < > Two strings are equal if and only if they contain the same sequence of characters.

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

org.exolab.jmscts.test.selector.StringTest.testCaseComparison1
org.exolab.jmscts.test.selector.StringTest.testCaseComparison2
org.exolab.jmscts.test.selector.StringTest.testCaseComparison3
org.exolab.jmscts.test.selector.StringTest.testCheckSingleQuotes1
org.exolab.jmscts.test.selector.StringTest.testCheckSingleQuotes2
org.exolab.jmscts.test.selector.StringTest.testEquals
org.exolab.jmscts.test.selector.StringTest.testEqualsProperty
org.exolab.jmscts.test.selector.StringTest.testGreaterEquals1
org.exolab.jmscts.test.selector.StringTest.testGreaterEquals2
org.exolab.jmscts.test.selector.StringTest.testGreaterEquals3
org.exolab.jmscts.test.selector.StringTest.testGreaterThan1
org.exolab.jmscts.test.selector.St ringTest.testGreaterThan2
org.exolab.jmscts.test.selector.StringTest.testGreaterThan3
org.exolab.jmscts.test.selector.StringTest.testLessEquals1
org.exolab.jmscts.test.selector.StringTest.testLessEquals2
org.exolab.jmscts.test.selector.StringTest.testLessEquals3
org.exolab.jmscts.test.selector.StringTest.testLessThan1
org.exolab.jmscts.test.selector.StringTest.testLessThan2
org.exolab.jmscts.test.selector.StringTest.testLessThan3

selector.operator.between

BETWEEN expressions are of the form: arithmetic-expr1 [NOT ] BETWEEN arithmetic-expr2 and arithmetic-expr3

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

org.exolab.jmscts.test.selector.BetweenOperatorTest.testBetween1
org.exolab.jmscts.test.selector.BetweenOperatorTest.testBetween2
org.exolab.jmscts.test.selector.BetweenOperatorTest.testBetween3
org.exolab.jmscts.test.selector.BetweenOperatorTest.testBetween4
org.exolab.jmscts.test.selector.BetweenOperatorTest.testBetween5
org.exolab.jmscts.test.selector.BetweenOperatorTest.testBetween6
org.exolab.jmscts.test.selector.BetweenOperatorTest.testNotBetween1
org.exolab.jmscts.test.selector.BetweenOperatorTest.testNotBetween2
org.exolab.jmscts.test.selector.BetweenOperatorTest.testNotBetween3
org.exolab.jmscts.test.selector.BetweenOperatorTest.testNotBetween4
org.exolab.jmscts.test.selector.BetweenOperatorTest.testNotBetween5
org.exolab.jmscts.test.selector.BetweenOperatorTest.testUnsetProperty1
org.exolab.jmscts.test.selector.BetweenOperatorTest.testUnsetProperty2
org.exolab.jmscts.test.selector.BetweenOperatorTest.testUnsetProperty3

selector.operator.in

IN expressions are of the form: identifier [NOT ] IN (string-literal1, string-literal2, ...) where identifier has a String or NULL value. If identifier is NULL, the value of the operation is unknown. TODO - add tests where identifier is known to be a non-string value

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

selector.operator.like

LIKE expressions are of the form: identifier [NOT ] LIKE pattern-value [ESCAPE escape-character ] where identifier has a String value; pattern-value is a string literal where '_' stands for any single character; '%' stands for any sequence of characters, including the empty sequence, and all other characters stand for themselves. The optional escape-character is a single-character string literal whose character is used to escape the special meaning of the '_' and '%' in pattern-value.

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

selector.operator.is

IS expressions are of the form: identifier IS [NOT ] NULL The IS NULL form tests for a null header field value or a missing property value. The IS NOT NULL form tests for the existence of a non-null header field value or property value The IS NULL and IS NOT NULL operators convert an unknown header or property value into the respective TRUE and FALSE values.

See:

Section 3.8.1.1, Message Selector Syntax
Section 3.8.1.2, Null Values

Test cases:

selector.validation

JMS providers are required to verify the syntactic correctness of a message selector at the time it is presented. A method providing a syntactically incorrect selector must result in a JMS InvalidSelectorException.

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

org.exolab.jmscts.test.selector.JMSTimestampTest.testInvalid1
org.exolab.jmscts.test.selector.JMSTimestampTest.testInvalid2
org.exolab.jmscts.test.selector.JMSTimestampTest.testInvalid3
org.exolab.jmscts.test.selector.IdentifierTest.testInvalid1
org.exolab.jmscts.test.selector.IdentifierTest.testInvalid2
org.exolab.jmscts.test.selector.StringTest.testGreaterEquals1
org.exolab.jmscts.test.selector.StringTest.testGreaterEquals2
org.exolab.jmscts.test.selector.StringTest.testGreaterEquals3
org.exolab.jmscts.test.selector.StringTest.testGreaterThan1
org.exolab.jmscts.test.selector.StringTest.testGreaterThan2
org.exolab.jmscts.test.selector.StringTest.testGreaterThan3
org.exolab.jmscts.test.selector.StringTest.testInvalid1
org.exolab.jmscts.test.selector.StringTest.testInvalid2
org.exolab.jmscts.test.selector.StringTest.testInvalid3
org.exolab.jmscts.test.selector.StringTest.testInvalid4
org.exolab.jmscts.test.selector.StringTest.testInvalid5
org.exolab.jmscts.test.selector.StringTest.testInvalid6
org.exolab.jmscts.test.selector.StringTest.testLessEquals1
org.exolab.jmscts.test.selector.StringTest.testLessEquals2
org.exolab.jmscts.test.selector.StringTest.testLessEquals3
org.exolab.jmscts.test.selector.StringTest.testLessThan1
org.exolab.jmscts.test.selector.StringTest.testLessThan2
org.exolab.jmscts.tes t.selector.StringTest.testLessThan3
org.exolab.jmscts.test.selector.JMSPriorityTest.testInvalid1
org.exolab.jmscts.test.selector.JMSPriorityTest.testInvalid2
org.exolab.jmscts.test.selector.BetweenOperatorTest.testInvalid1
org.exolab.jmscts.test.selector.BetweenOperatorTest.testInvalid2
org.exolab.jmscts.test.selector.BetweenOperatorTest.testInvalid3
org.exolab.jmscts.test.selector.BetweenOperatorTest.testInvalid4
org.exolab.jmscts.test.selector.BetweenOperatorTest.testInvalid5
org.exolab.jmscts.test.selector.BetweenOperatorTest.testInvalid6
org.exolab.jmscts.test.selector.BetweenOperatorTest.testInvalid7
org.exolab.jmscts.test.selector.BetweenOperatorTest.testInvalid8
org.exolab.jmscts.test.selector.BetweenOperatorTest.testInvalid9
org.exolab.jmscts.test.selector.FloatTest.testInvalid1
org.exolab.jmscts.test.selector.FloatTest.testInvalid2
org.exolab.jmscts.test.selector.FloatTest.testInvalid3
org.exolab.jmscts.test.selector.FloatTest.testInvalid4
org.exolab.jmscts.test.selector.FloatTest.testInvalid5
org.exolab.jmscts.test.selector.JMSDeliveryModeTest.testInvalid1
org.exolab.jmscts.test.selector.JMSDeliveryModeTest.testInvalid2
org.exolab.jmscts.test.selector.AndOperatorTest.testInvalidAnd1
org.exolab.jmscts.test.selector.AndOperatorTest.testInvalidAnd2
org.exolab.jmscts.test.selector.AndOperatorTest.testInvalidAnd3
org.exolab.jmscts.test.selector.BooleanTest.testGreaterEquals
org.exolab.jmscts.test.selector.BooleanTest.testGreaterThan
org.exolab.jmscts.test.selector.BooleanTest.testLessEquals
org.exolab.jmscts.test.selector.BooleanTest.testLessThan

selector.operator.arithmetic.promotion

Arithmetic operations must use Java numeric promotion.

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

selector.values.null

Header fields and property values may be NULL. Comparison or arithmetic with an unknown value always yields an unknown value.

See:

Section 3.8.1.2, Null Values

Test cases:

org.exolab.jmscts.test.selector.BetweenOperatorTest.testUnsetProperty1
org.exolab.jmscts.test.selector.BetweenOperatorTest.testUnsetProperty2
org.exolab.jmscts.test.selector.BetweenOperatorTest.testUnsetProperty3
org.exolab.jmscts.test.selector.FloatTest.testUnsetProperty1
org.exolab.jmscts.test.selector.FloatTest.testUnsetProperty2
org.exolab.jmscts.test.selector.FloatTest.testUnsetProperty3
org.exolab.jmscts.test.selector.FloatTest.testUnsetProperty4
org.exolab.jmscts.test.selector.FloatTest.testUnsetProperty5
org.exolab.jmscts.test.selector.FloatTest.testUnsetProperty6
org.exolab.jmscts.test.selector.FloatTest.testUnsetProperty7
org.exolab.jmscts.test.selector.FloatTest.testUnsetProperty8
org.exolab.jmscts.test.selector.AndOperatorTest.testUnsetProperty1
org.exolab.jmscts.test.selector.AndOperatorTest.testUnsetProperty2
org.exolab.jmscts.test.selector.AndOperatorTest.testUnsetProperty3
org.exolab.jmscts.test.selector.AndOperatorTest.testUnsetProperty4
org.exolab.jmscts.test.selector.AndOperatorTest.testUnsetProperty5

selector.operator.and

The AND operator evaluates as follows:

AND	T	F	U
T	T	F	U
F	F	F	F
U	U	F	U

See:

Section 3.8.1.2, Null Values
Table 3-4

Test cases:

org.exolab.jmscts.test.selector.AndOperatorTest.testAnd1
org.exolab.jmscts.test.selector.AndOperatorTest.testAnd2
org.exolab.jmscts.test.selector.AndOperatorTest.testAnd3
org.exolab.jmscts.test.selector.AndOperatorTest.testAnd4
org.exolab.jmscts.test.selector.AndOperatorTest.testAndCase
org.exolab.jmscts.test.selector.AndOperatorTest.testUnsetProperty1
org.exolab.jmscts.test.selector.AndOperatorTest.testUnsetProperty2
org.exolab.jmscts.test.selector.AndOperatorTest.testUnsetProperty3
org.exolab.jmscts.test.selector.AndOperatorTest.testUnsetProperty4
org.exolab.jmscts.test.selector.AndOperatorTest.testUnsetProperty5

selector.operator.or

The OR operator evaluates as follows:

OR	T	F	U
T	T	T	T
F	T	F	U
U	T	U	U

See:

Section 3.8.1.2, Null Values
Table 3-5

Test cases:

selector.operator.not

The NOT operator evaluates as follows:

NOT
T	F
F	T
U	U

See:

Section 3.8.1.2, Null Values
Table 3-6

Test cases:

selector.JMSDeliveryMode

When used in a message selector JMSDeliveryMode is treated as having the values 'PERSISTENT' and 'NON_PERSISTENT'.

See:

Section 3.8.1.3, Special Notes

Test cases:

org.exolab.jmscts.test.selector.JMSDeliveryModeTest.testInvalid1
org.exolab.jmscts.test.selector.JMSDeliveryModeTest.testInvalid2
org.exolab.jmscts.test.selector.JMSDeliveryModeTest.testJMSDeliveryMode

selector.datetime

Date and time values should use the standard Java long millis value. When a date or time literal is included in a message selector, it should be an integer literal for a millis value.

See:

Section 3.8.1.3, Special Notes

Test cases:

org.exolab.jmscts.test.selector.JMSTimestampTest.testInvalid1
org.exolab.jmscts.test.selector.JMSTimestampTest.testInvalid2
org.exolab.jmscts.test.selector.JMSTimestampTest.testInvalid3
org.exolab.jmscts.test.selector.JMSTimestampTest.testJMSTimestamp1
org.exolab.jmscts.test.selector.JMSTimestampTest.testJMSTimestamp2
org.exolab.jmscts.test.selector.JMSTimestampTest.testJMSTimestamp3
org.exolab.jmscts.test.selector.JMSPriorityTest.testInvalid2

connection.authentication

When creating a connection, a client may specify its credentials as a name/password. JMSSecurityException must be thrown when a provider rejects a user name/password submitted by a clie nt

See:

Section 4.3.1, Authentication
Section 7.3, Standard Exceptions

Test cases:

org.exolab.jmscts.test.connection.AuthTest.testInvalidQueueAuth
org.exolab.jmscts.test.connection.AuthTest.testInvalidTopicAuth
org.exolab.jmscts.test.connection.AuthTest.testQueueAuth
org.exolab.jmscts.test.connection.AuthTest.testTopicAuth

connection.clientID.administered

The facility to explicitly set a connection's client identifier is not a mechanism for overriding the identifier that has been administratively configured. It is provided for the case where no administratively specified identifier exists. If one does exist, an attempt to change it by setting it must throw an IllegalStateException.

See:

Section 4.3.2, Client Identifier

Test cases:

org.exolab.jmscts.test.connection.ClientIdentifierTest.testSetOnCreation

connection.method.setClientID

If a client explicitly sets the client identifer it must do this immediately after creating the connection and before any other action on the connection is taken. After this point, setting the client identifier is a programming error that should throw an IllegalStateException.

See:

Section 4.3.2, Client Identifier

Test cases:

org.exolab.jmscts.test.connection.ClientIdentifierTest.testSetAfterClose
org.exolab.jmscts.test.connection.ClientIdentifierTest.testSetAfterCreateSession
org.exolab.jmscts.test.connection.ClientIdentif ierTest.testSetAfterListenerRegistration
org.exolab.jmscts.test.connection.ClientIdentifierTest.testSetAfterStart
org.exolab.jmscts.test.connection.ClientIdentifierTest.testSetAfterStop
org.exolab.jmscts.test.connection.ClientIdentifierTest.testSetOnCreation

connection.clientID.duplicate

The client state identified by a client identifier can be in use by only one client at a time. A JMS provider must prevent concurrently executing clients from using it. This prevention may take the form of JMSExceptions thrown when such use is attempted; it may result in the offending client being blocked; or some other solution. A JMS provider must insure that such attempted 'sharing' of an individual client state does not result in messages being lost or doubly processed. TODO - don't handle the blocked scenario

See:

Section 4.3.2, Client Identifier

Test cases:

org.exolab.jmscts.test.connection.ClientIdentifierTest.testDuplicateClientID

connection.creation

When a Connection is created, it is in stopped mode. That means that no messages are being delivered to it.

See:

Section 4.3.3, Connection Setup

Test cases:

org.exolab.jmscts.test.connection.SendReceiveStopTest.testStoppedOnCreation

connection.stopped

No messages are delivered by a connection to its client until it has been started.

See:

Section 4.3.3, Connection Setup

Test cases:

org.exolab. jmscts.test.connection.SendReceiveStopTest.testStop
org.exolab.jmscts.test.connection.SendReceiveStopTest.testStoppedOnCreation

connection.stopped.send

Stopping a connection has no effect on its ability to send messages.

See:

Section 4.3.4, Pausing Delivery of Incoming Messages

Test cases:

org.exolab.jmscts.test.connection.SendReceiveStopTest.testStoppedOnCreation

connection.stop.listeners

A stop method call must not return until delivery of messages has paused. This means a client can rely on the fact that none of its message listeners will be called and all threads of control waiting for receive to return will not return with a message until the connection is restarted. If MessageListeners are running when stop is invoked, stop must wait until all of them have returned before it may return. While these MessageListeners are completing, they must have the full services of the connection available to them. TODO - test behaviour of sending messages while a listener is active, using a different session (i.e, not from the listener - undefined?) TODO - add test where a thread stops a connection and another starts it as the stop is in progress.

See:

Section 4.3.5, Closing a Connection

Test cases:

org.exolab.jmscts.test.connection.ListenerTest.testConnectionStop

connection.stop.receivers

The receive timers for a stopped connection continue to advance, so receives may time out and return a null message while the connection is stopped.

See:

Section 4.3.5, Closing a Connection

Test cases:

org.exolab.jmscts.test.connection.ReceiverTest.testConnectionRestart
org.exolab.jmscts.test.connection.ReceiverTest.testConnectionStop

connection.stop.stopped

Stopping a stopped connection is ignored.

See:

Section 4.3.5, Closing a Connection

Test cases:

org.exolab.jmscts.test.connection.StopStartTest.testStopForStoppedConnection

connection.start.started

Starting a started connection is ignored.

See:

Section 4.3.5, Closing a Connection

Test cases:

org.exolab.jmscts.test.connection.StopStartTest.testStartForStartedConnection

connection.close.receivers

A close terminates all pending message receives on the connection's session's consumers. The receives may return with a message or null depending on whether or not there was a message available at the time of the close.

See:

Section 4.3.5, Closing a Connection

Test cases:

org.exolab.jmscts.test.connection.ReceiverTest.testConnectionClose

connection.close.listeners

If one or more of the connection's session's message listeners is processing a message at the point when connection close is invoked, all the facilities of the connection and its sessions must remain available to those listeners until they return control to the JMS provider.

See:

Section 4.3.5, Closing a Connection

Test cases:

org.exolab.jmscts.test.connection.ListenerTest.testConnectionClose

connection.close

Once a connection has been closed, an attempt to use it or its sessions or their message consumers and producers must throw an IllegalStateException (calls to the close method of these objects must be ignored).

See:

Section 4.3.5, Closing a Connection

Test cases:

org.exolab.jmscts.test.connection.ConnectionCloseTest.testExceptionOnClose

connection.close.resources

If a connection is closed, there is no need to close its constituent objects. The connection close is sufficient to signal the JMS provider that all resources for the connection should be released. TODO: probably the only meaningful way to test this in a provider independent fashion is to attempt to use a temporary destination created by the closed connection, on another connection. This should throw InvalidDestinationException?

See:

Section 4.3.5, Closing a Connection

Test cases:

connection.close.session.transacted

Closing a connection must roll back the transactions in progress on its transacted sessions.

See:

Section 4.3.5, Closing a Connection

Test cases:

org.exolab.jmscts.test.session.transacted.CloseTest.testRo llbackForClosedConnection

connection.close.session.CLIENT_ACKNOWLEDGE

Closing a connection does NOT force an acknowledgement of client-acknowledged sessions.

See:

Section 4.3.5, Closing a Connection

Test cases:

org.exolab.jmscts.test.session.clientack.CloseTest.testConnectionClose

connection.close.message

It is valid to continue to use message objects created or received after a connection has been closed with the exception of a received message's acknowledge method. Invoking the acknowledge method of a received message must throw an IllegalStateException.

See:

Section 4.3.5, Closing a Connection

Test cases:

org.exolab.jmscts.test.message.close.CloseTest.testCloseConnection

connection.close.closed

Closing a closed connection must NOT throw an exception.

See:

Section 4.3.5, Closing a Connection

Test cases:

org.exolab.jmscts.test.connection.ConnectionCloseTest.testCloseForClosedConnection

session.close.transacted

Closing a transacted session must roll back its transaction in progress.

See:

Section 4.4.1, Closing a Session

Test cases:

org.exolab.jmscts.test.session.transacted.CloseTest.testRollbackForClosedSession

session.close.CLIENT_ACKNOWLEDGE

Closing a client-acknowledged session does NOT force an acknowledge.

See:

Section 4.4.1, Closing a Session

Test cases:

org.exolab.jmscts.test.session.clientack.CloseTest.testSessionClose

session.close

Once a session has been closed, an attempt to use it or its message consumers and producers must throw an IllegalStateException (calls to the close method of these objects must be ignored).

See:

Section 4.4.1, Closing a Session

Test cases:

org.exolab.jmscts.test.session.transacted.RollbackTest.testClose
org.exolab.jmscts.test.session.CloseTest.testExceptionOnClose

session.close.message

It is valid to continue to use message objects created or received via the session, with the exception of a received message'acknowledge method. Invoking the acknowledge method of a received message must throw an IllegalStateException.

See:

Section 4.4.1, Closing a Session

Test cases:

org.exolab.jmscts.test.message.close.CloseTest.testCloseSession

session.close.closed

Closing a closed session must NOT throw an exception.

See:

Section 4.4.1, Closing a Session

Test cases:

org.exolab.jmscts.test.session.CloseTest.testCloseForClosedSession

session.close.receivers

A close terminates all pending message receive s on the connection's session's consumers. The receives may return with a message or null depending on whether or not there was a message available at the time of the close.

See:

Section 4.4.1, Closing a Session

Test cases:

org.exolab.jmscts.test.session.ReceiverCloseTest.testSessionClose

session.close.listeners

If one or more of the connection's session's message listeners is processing a message at the point when connection close is invoked, all the facilities of the connection and its sessions must remain available to those listeners until they return control to the JMS provider.

See:

Section 4.4.1, Closing a Session

Test cases:

org.exolab.jmscts.test.session.ListenerCloseTest.testSessionClose

session.transactions

Each transacted session supports a single series of transactions. Each transaction groups a set of produced messages and a set of consumed messages into an atomic unit of work. In effect, transactions organize a session's input message stream and output message stream into series of atomic units. When a transaction commits, its atomic unit of input is acknowledged and its associated atomic unit of output is sent.

See:

Section 4.4.7, Transactions

Test cases:

org.exolab.jmscts.test.session.transacted.CommitTest.testCommit

session.rollback

If a transacted session is rolled back, its produced messages are destroyed and its consumed messages are automatically recovered.

See:

Section 4.4.7, Transactions

Test cases:

org.exolab.jmscts.test.session.transacted.RollbackTest.testRollback

session.DUPS_OK_ACKNOWLEDGE

With the DUPS_OK_ACKNOWLEDGE session acknowledgement mode, 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. Its benefit is the reduction of session overhead achieved by minimizing the work the session does to prevent duplicates.

See:

Section 4.4.11, Message Acknowledgment

Test cases:

org.exolab.jmscts.test.session.DupsAckTest.testDupsOKAcknowledgement

session.AUTO_ACKNOWLEDGE

With the AUTO_ACKNOWLEDGE session acknowledgement mode, the session automatically acknowledges a client's receipt of a message when it has either successfully returned from a call to receive or the MessageListener it has called to process the message successfully returns.

See:

Section 4.4.11, Message Acknowledgment

Test cases:

org.exolab.jmscts.test.session.AutoAckTest.testAutoAcknowledgement

session.CLIENT_ACKNOWLEDGE

With the CLIENT_ACKNOWLEDGE session acknowledgement mode, a client acknowledges a message by calling the message's acknowledge method. Acknowledging a consumed message automatically acknowledges the receipt of all messages that have been delivered by its session.

See:

Section 4.4.11, Message Acknowledgment

Test cases:

org.exolab.jmscts.test.session.clientack.ClientAcknowledgeTest.testClientAcknowledge
org.exolab.jmscts.test.session.clientack.ClientAcknowledgeTest.testPartialClientAcknowledge
org.exolab.jmscts.test.session.clientack.RepublishTest.testRepublish

session.recover

A session's recover method is used to stop a session and restart it with its first unacknowledged message. In effect, the session's series of delivered messages is reset to the point after its last acknowledged message. The messages it now delivers may be different from those that were originally delivered due to message expiration and the arrival of higher-priority messages.

A session must set the redelivered flag of messages it redelivers due to a recovery.

See:

Section 4.4.11, Message Acknowledgment
Section 3.4.7, JMSRedelivered

Test cases:

org.exolab.jmscts.test.session.clientack.ClientAcknowledgeTest.testClientAcknowledge
org.exolab.jmscts.test.session.clientack.ClientAcknowledgeTest.testPartialClientAcknowledge
org.exolab.jmscts.test.session.clientack.ClientAcknowledgeTest.testRecover

session.transactions.transactioninprogress

A TransactionInProgressException exception is thrown when an operation is invalid because a transaction is in progress. For instance, attempting to call Session.commit() when a session is part of a distributed transaction.

See:

Section 7.3, Standard Exceptions

Test cases:

session.transactions.commitrolledback

A TransactionRolledBackException exception must be thrown when a call to Session.commit() results in a rollback of the current transaction.

See:

Section 7.3, Standard Exceptions

Test cases:

session.ack.closedconsumer

A message can be acknowledged after its message consumer has closed as message acknowledgement is performed at the session level TODO - need to test this for single message acknowledgement via CLIENT_ACKWNOWLEDGE etc

See:

http://java.sun.com/products/jms/faq.html#msg_ack_close

Test cases:

org.exolab.jmscts.test.session.transacted.CommitTest.testCommitForClosedEndpoint

session.listener.serialization

A session serializes all asynchronous delivery of messages. While the session is busy executing one listener, all other messages to be asynchronously delivered to the session must wait.

See:

Section 4.4.14, Serial Execution of Client Code

Test cases:

org.exolab.jmscts.test.session.MessageListenerTest.testSerialInvocation

session.commit.IllegalStateException

Invoking commit() on a non-transacted session should throw IllegalStateException

See:

Section 7.3, Standard Exceptions
http://java.sun.com/products/jms/javadoc-102a/javax/jms/Session.html#commit()

Test cases:

org.exolab.jmscts.test.session.NonTransactedTest.testCommit

session.rollback.IllegalStateException

Invoking rollback() on a non-transacted session should throw IllegalStateException

See:

http://java.sun.com/products/jms/javadoc-102a/javax/jms/Session.html#rollback()

Test cases:

org.exolab.jmscts.test.session.NonTransactedTest.testRollback

session.recover.IllegalStateException

Invoking recover() on a transacted session should throw IllegalStateException

See:

http://java.sun.com/products/jms/javadoc-102a/javax/jms/Session.html#recover()

Test cases:

org.exolab.jmscts.test.session.transacted.RecoverTest.testRecover

producer.ttl.default

If not specified, the default time-to-live for a producer equals 0

See:

Test cases:

org.exolab.jmscts.test.producer.ttl.QueueSenderTest.testDefaultTTL
org.exolab.jmscts.test.producer.ttl.QueueSenderTest.testDefaultTTLForAnonQueue
org.exolab.jmscts.test.producer.ttl.TopicPublisherTest.testDefaultTTL
org.exolab.jmscts.test.producer.ttl.TopicPublisherTest.testDefaultTTLForAnonTopic

producer.ttl.set

A client can specify a default time-to-live for messages sent by a message producer, to be used when a time-to-live isn't specified per message.

Note: the specification doesn't mention min or max values for time-to-live, or if any exceptions will be thrown if an invalid time-to-live is specified.

See:

Test cases:

org.exolab.jmscts.test.producer.ttl.QueueSenderTest.testSetTTL
org.exolab.jmscts.test.producer.ttl.QueueSenderTest.testSetTTLWithAnonQueue
org.exolab.jmscts.test.producer.ttl.TopicPublisherTest.testSetTTL
org.exolab.jmscts.test.producer.ttl.TopicPublisherTest.testSetTTLWithAnonTopic

message.destination

When a message is sent, JMSDestination is ignored. After completion of the send it holds the destination object specified by the sending method. When a message is received, its destination value must be equivalent to the value assigned when it was sent.

See:

Section 3.4.1, JMSDestination
Section 3.4.11, How Message Header Values Are Set

Test cases:

org.exolab.jmscts.test.message.header.JMSDestinationTest.testJMSDestination
org.exolab.jmscts.test.message.header.JMSDestinationTest.testJMSDestinationOnResend

message.identifier

When a message is sent, JMSMessageID is ignored. When the send method returns it contains a provider-assigned value.

See:

Section 3.4.3, JMSMessageID
Section 3.4.11, How Message Header Values Are Set

Test cases:

org.exolab.jmscts.test.message.header.JMSMessageIDTest.testJMSMessageID
org.exolab.jmscts.test.message.header.JMSMessageIDTest.testJMSMessageIDAssignment

message.identifier.prefix

All JMSMessageID values must start with the prefix 'ID:'

See:

Section 3.4.3, JMSMessageID

Test cases:

org.exolab.jmscts.test.message.header.JMSMessageIDTest.testJMSMessageIDPrefix

message.correlation

The JMSCorrelationID header field may be used to link one message with another. It can contain a provider-specific message ID, an application-specific string, or a provider-native byte[ ] value. The application-specific string must not start with the 'ID:' prefix: this is reserved for provider generated messages Ids.

See:

Section 2.10, Request/Reply
Section 3.4.5, JMSCorrelationID
Section 3.4.11, How Message Header Values Are Set

Test cases:

org.exolab.jmscts.test.message.header.JMSCorrelationIDTest.testCorrelationID
org.exolab.jmscts.test.message.header.JMSCorrelationIDTest.testNullCorrelationID

message.correlation.bytes

If a provider supports the native concept of correlation ID, a JMS client may need to assign specific JMSCorrelationID values to match those expected by non-JMS clients. A byte[ ] value is used for this purpose. JMS providers without native correlation ID values are not required to support byte[ ] values - in this case setJMSCorrelationIDAsBytes() and getJMSCorrelationIDAsBytes() may throw java.lang.UnsupportedOperationException.

See:

Section 3.4.5, JMSCorrelationID

Test cases:

org.exolab.jmscts.test.message.header.JMSCorrelationIDTest.testCorrelationIDAsBytes

message.redelivered.receive

If a client receives a message with the JMSRedelivered indicator set, it is likely, but not guaranteed, that this message was delivered but not acknowledged in the past. In general, a provider must set the JMSRedelivered message header field of a message whenever it is redelivering a message.

See:

Section 3.4.7, JMSRedelivered
Section 3.4.11, How Message Header Values Are Set

Test cases:

org.exolab.jmscts.test.session.clientack.SubscriberRedeliveredTest.testJMSRedelivered
org.exolab.jmscts.test.session.clientack.ClientAcknowledgeTest.testPartialClientAcknowledge
org.exolab.jmscts.test.session.clientack.ClientAcknowledgeTest.testRecover

message.redelivered.send

The JMSRedelivered header field has no meaning on send and is left unassigned by the sending method.

See:

Section 3.4.7, JMSRedelivered

Test cases:

message.expiration.send

When a message is sent, its expiration time is calculated as the sum of the time-to-live value specified on the send method and the current GMT value. On return from the send method, the message's JMSExpiration header field contains this value.

See:

Section 3.4.9, JMSExpiration

Test cases:

org.exolab.jmscts.test.producer.ttl.QueueSenderTest.testDefaultTTL
org.exolab.jmscts.test.producer.ttl.QueueSenderTest.testDefaultTTLForAnonQueue
org.exolab.jmscts.test.producer.ttl.QueueSenderTest .testSendWithTTL
org.exolab.jmscts.test.producer.ttl.QueueSenderTest.testSendWithTTLAndAnonQueue
org.exolab.jmscts.test.producer.ttl.QueueSenderTest.testSetTTL
org.exolab.jmscts.test.producer.ttl.QueueSenderTest.testSetTTLWithAnonQueue
org.exolab.jmscts.test.producer.ttl.TopicPublisherTest.testDefaultTTL
org.exolab.jmscts.test.producer.ttl.TopicPublisherTest.testDefaultTTLForAnonTopic
org.exolab.jmscts.test.producer.ttl.TopicPublisherTest.testPublishWithTTL
org.exolab.jmscts.test.producer.ttl.TopicPublisherTest.testPublishWithTTLAndAnonTopic
org.exolab.jmscts.test.producer.ttl.TopicPublisherTest.testSetTTL
org.exolab.jmscts.test.producer.ttl.TopicPublisherTest.testSetTTLWithAnonTopic

message.expiration.receive

When a message is received its JMSExpiration header field contains the expiration as that on send.

See:

Section 3.4.9, JMSExpiration

Test cases:

org.exolab.jmscts.test.producer.ttl.QueueSenderTest.testDefaultTTL
org.exolab.jmscts.test.producer.ttl.QueueSenderTest.testDefaultTTLForAnonQueue
org.exolab.jmscts.test.producer.ttl.QueueSenderTest.testSendWithTTL
org.exolab.jmscts.test.producer.ttl.QueueSenderTest.testSendWithTTLAndAnonQueue
org.exolab.jmscts.test.producer.ttl.QueueSenderTest.testSetTTL
org.exolab.jmscts.test.producer.ttl.QueueSenderTest.testSetTTLWithAnonQueue
org.exolab.jmscts.test.producer.ttl.TopicPublisherTest.testDefaultTTL
org.exolab.jmscts.test.producer.ttl.TopicPublisherTest.testDefaultTTLForAnonTopic
org.exolab.jmscts.test.producer.ttl.TopicPublisherTest.testPublishWithTTL
org.exolab.jmscts.test.producer.ttl.TopicPublisherTest.testPublishWithTTLAndAnonTopic
org.exolab.jmscts.test.producer.ttl.TopicPub lisherTest.testSetTTL
org.exolab.jmscts.test.producer.ttl.TopicPublisherTest.testSetTTLWithAnonTopic

message.expiration.zero

If the time-to-live is specified as zero, expiration is set to zero to indicate that the message does not expire.

See:

Section 3.4.9, JMSExpiration

Test cases:

org.exolab.jmscts.test.producer.ttl.QueueSenderTest.testDefaultTTL
org.exolab.jmscts.test.producer.ttl.QueueSenderTest.testDefaultTTLForAnonQueue
org.exolab.jmscts.test.producer.ttl.ExpirationTest.testExpiration
org.exolab.jmscts.test.producer.ttl.ExpirationTest.testExpiration2DiffSubscribers
org.exolab.jmscts.test.producer.ttl.ExpirationTest.testExpiration2Subscribers
org.exolab.jmscts.test.producer.ttl.ExpirationTest.testSingleMessageExpiration
org.exolab.jmscts.test.producer.ttl.TopicPublisherTest.testDefaultTTL
org.exolab.jmscts.test.producer.ttl.TopicPublisherTest.testDefaultTTLForAnonTopic

message.expiration.expired

When GMT is later than an undelivered message's expiration time, the message should be destroyed. Clients should not receive messages that have expired; however, JMS does not guarantee that this will not happen.

See:

Section 3.4.9, JMSExpiration

Test cases:

org.exolab.jmscts.test.producer.ttl.ExpirationTest.testExpiration
org.exolab.jmscts.test.producer.ttl.ExpirationTest.testExpiration2DiffSubscribers
org.exolab.jmscts.test.producer.ttl.ExpirationTest.testExpiration2Subscribers
org.exolab.jmscts.test.producer.ttl.ExpirationTest.testSingleMessageExpiration

message.replyTo

The JMSReplyTo header field contains a Destination supplied by a client when a message is sent. It is the destination where a reply to the message should be sent.

Messages sent with a null JMSReplyTo value may be a notification of some event or they may just be some data the sender thinks is of interest.

See:

Section 2.10, Request/Reply
Section 3.4.6, JMSReplyTo

Test cases:

org.exolab.jmscts.test.message.header.JMSReplyToTest.testReplyTo

message.creation

When a message is created, its message body and properties may be set.

See:

Section 3.3, JMS Messages

Test cases:

org.exolab.jmscts.test.message.readwrite.ReadWriteTest.testBytesReadableOnCreation
org.exolab.jmscts.test.message.readwrite.ReadWriteTest.testReadableOnCreation
org.exolab.jmscts.test.message.readwrite.ReadWriteTest.testStreamReadableOnCreation
org.exolab.jmscts.test.message.readwrite.ReadWriteTest.testWriteableOnCreation

properties.identifier

An identifier is an unlimited-length character sequence that must begin with a Java identifier start character; all following characters must be Java identifier part characters. An identifier start character is any character for which the method Character.isJavaIdentifierStart returns true. An identifier part character is any character for which the method Character.isJavaIdentifierPart returns true.

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

org.exolab.jmscts.test.message.properties.IdentifierTest.testInvalidIdentifiers
org.exolab.jmscts.test.message.properties.IdentifierTest.testValidIdentifiers

properties.identifier.reserved

Identifiers cannot be the words NULL, TRUE, FALSE, NOT, AND, OR, BETWEEN, LIKE, IN, IS, or ESCAPE. These are case-insensitive reserved words.

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

org.exolab.jmscts.test.message.properties.IdentifierTest.testReservedWords

properties.identifier.case

Identifiers are case sensitive.

See:

Section 3.8.1.1, Message Selector Syntax

Test cases:

org.exolab.jmscts.test.message.properties.IdentifierTest.testIdentifierCase

properties.types

Property values can be boolean, byte, short, int, long, float, double, and String.

See:

Section 3.5.2, Property Values

Test cases:

org.exolab.jmscts.test.message.properties.PropertyTypeTest.testPropertyTypes

properties.objects

The setObjectProperty method accepts values of Boolean, Byte, Short, Integer, Long, Float, Double and String. An attempt to use any other class must throw a JMS MessageFormatException.

The getObjectProperty method only returns values of null, Boolean, Byte, Short, Integer, Long, Float, Double and String. A null value is returned if a property by the s pecified name does not exist.

See:

Section 3.5.5, Property Values as Objects
Section 3.5.8, Nonexistent Properties

Test cases:

org.exolab.jmscts.test.message.properties.PropertyTypeTest.testObjectPropertyTypes

properties.integrity

User properties may not be modified by the provider

See:

Section Undefined, An implied requirement

Test cases:

org.exolab.jmscts.test.message.properties.PropertyTest.testPropertyIntegrity

properties.conversion

Properties support the following conversion table. The marked cases must be supported. The unmarked cases must throw the JMS MessageFormatException.

The String to numeric conversions must throw the java.lang.NumberFormatException if the numeric's valueOf() method does not accept the String value as a valid representation. A value set as the row type can be read as the column type.

	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

See:

Section 3.5.4, Property Value Conversion
Table 3-2

Test cases:

org.exolab.jmscts.test.message.properties.PropertyConversionTest.testBoolean
org.exolab.jmscts.test.message.properties.PropertyConversionTest.testByte
org.exolab.jmscts.test.message.properties.PropertyConversionTest.testDouble
org.exolab.jmscts.test.message.properties.PropertyConversionTest.testFloat
org.exolab.jmscts.test.message.properties.PropertyConversionTest.testInt
org.exolab.jmscts.test.m essage.properties.PropertyConversionTest.testLong
org.exolab.jmscts.test.message.properties.PropertyConversionTest.testShort
org.exolab.jmscts.test.message.properties.PropertyConversionTest.testStringBoolean
org.exolab.jmscts.test.message.properties.PropertyConversionTest.testStringByte
org.exolab.jmscts.test.message.properties.PropertyConversionTest.testStringDouble
org.exolab.jmscts.test.message.properties.PropertyConversionTest.testStringFloat
org.exolab.jmscts.test.message.properties.PropertyConversionTest.testStringInt
org.exolab.jmscts.test.message.properties.PropertyConversionTest.testStringLong
org.exolab.jmscts.test.message.properties.PropertyConversionTest.testStringObject
org.exolab.jmscts.test.message.properties.PropertyConversionTest.testStringShort

properties.conversion.null

Attempting to read a null value as a Java primitive type must be treated as calling the primitive's corresponding valueOf(String) conversion method with a null value.

See:

Section 3.5.4, Property Value Conversion
Section 3.5.8, Nonexistent Properties

Test cases:

org.exolab.jmscts.test.message.properties.PropertyConversionTest.testNullToPrimitive

properties.method.getPropertyNames

The order of property values is not defined. To iterate through a message's property values, use getPropertyNames to retrieve a property name enumeration and then use the various property get methods to retrieve their values. The getPropertyNames method does not return the names of the JMS standard header fields.

See:

Section 3.5.6, Property Iteration

Test cases:

org.exolab.jmscts.test.message.properties.PropertyTest.testPropertyIntegrity
org.exolab.jmscts.test.message.properties.PropertyTest.testPropertyNames

message.send

After sending a message, a client may retain and modify it without affecting the message that has been sent. The same message object may be sent multiple times.

See:

Section 3.9, Access to sent messages

Test cases:

org.exolab.jmscts.test.message.copy.MessageCopyTest.testCopyOnSend
org.exolab.jmscts.test.message.readwrite.SendReceiveReadWriteTest.testWriteableOnSend

message.receive

When a message is received its body is read only. If an attempt is made to change them, a MessageNotWriteableException must be thrown. If its properties or body are subsequently cleared, they are in the same state as a newly created message. TODO - need to test in transaction context

See:

Section 3.5.3, Using Properties
Section 3.10, Changing the Value of a Received Message
Section 3.11.2, Read-Only Message Body

Test cases:

org.exolab.jmscts.test.message.readwrite.SendReceiveReadWriteTest.testReadOnlyOnReceipt

message.method.clearBody

The clearBody method of Message resets the value of the message body to the empty initial message value as set by the message type's create method provided by Session. Clearing a message's body does not clear its property entries. When a message is cleared, its message body and properties may be set.

See:

Section 3.11.1, Clearing a message body

Test cases:

org.exolab.jmscts.test.message.readwrite.ReadWriteTest.testWriteableOnClear
org.exolab.jmscts.test.message.clear.RecoverClearTest.testRecover
org.exolab.jmscts.test.message.clear.RollbackClearTest.testRollback
org.exolab.jmscts.test.message.clear.SendReceiveClearTest.testBytesClearBodyOnReceipt
org.exolab.jmscts.test.message.clear.SendReceiveClearTest.testClearBodyOnReceipt
org.exolab.jmscts.test.message.clear.SendReceiveClearTest.testClearOnSend
org.exolab.jmscts.test.message.clear.SendReceiveClearTest.testStreamClearBodyOnReceipt
org.exolab.jmscts.test.message.clear.ClearTest.testBytesClearBody
org.exolab.jmscts.test.message.clear.ClearTest.testBytesClearBodyOnCreation
org.exolab.jmscts.test.message.clear.ClearTest.testClearBody
org.exolab.jmscts.test.message.clear.ClearTest.testClearBodyOnCreation
org.exolab.jmscts.test.message.clear.ClearTest.testStreamClearBody
org.exolab.jmscts.test.message.clear.ClearTest.testStreamClearBodyOnCreation

message.method.clearProperties

Clearing a message's properties leaves the message with an empty set of properties. New property entries can then be both created and read. Clearing a message's property entries does not clear the value of its body.

See:

Section 3.5.7, Clearing a Message's Property Values

Test cases:

org.exolab.jmscts.test.message.clear.RecoverClearTest.testRecover
org.exolab.jmscts.test.message.clear.RollbackClearTest.testRollback
org.exolab.jmscts.test .message.clear.SendReceiveClearTest.testClearOnSend
org.exolab.jmscts.test.message.clear.SendReceiveClearTest.testClearPropertiesOnReceipt
org.exolab.jmscts.test.message.clear.ClearTest.testClearProperties
org.exolab.jmscts.test.message.clear.ClearTest.testClearPropertiesOnCreation

message.bytes.creation

When the message is first created, the body of the message is in write-only mode. If a client attempts to read a message in write-only mode, a MessageNotReadableException is thrown.

See:

http://java.sun.com/products/jms/javadoc-102a/javax/jms/BytesMessage.html

Test cases:

org.exolab.jmscts.test.message.readwrite.ReadWriteTest.testBytesReadableOnCreation

message.bytes.eof

MessageEOFException must be thrown when an unexpected end of stream has been reached when a message is being read.

See:

Section 7.3, Standard Exceptions

Test cases:

org.exolab.jmscts.test.message.readwrite.ReadWriteTest.testBytesReadableOnCreation

message.object.method.setObject

The setObject method places a copy of the input in the message.

See:

Section 11.2.21, JMS Source JavaDoc Clarifications

Test cases:

org.exolab.jmscts.test.message.object.ObjectMessageTest.testNull

message.stream.creation

When the message is first created, the body of the message is in write-only mode. If a client attempts to read a message in write-only mode, a MessageNotReadableException is thrown.

See:

http://java.sun.com/products/jms/javadoc-102a/javax/jms/StreamMessage.html

Test cases:

org.exolab.jmscts.test.message.readwrite.ReadWriteTest.testStreamReadableOnCreation

message.stream.eof

MessageEOFException must be thrown when an unexpected end of stream has been reached when a message is being read.

See:

Section 7.3, Standard Exceptions

Test cases:

org.exolab.jmscts.test.message.readwrite.ReadWriteTest.testStreamReadableOnCreation

message.bytes.read

If a read method of a BytesMessage throws a MessageFormatException or NumberFormatException, the current position of the read pointer must not be incremented. A subsequent read must be capable of recovering from the exception by re-reading the data as a different type.

NOTE: With the exception of the readUTF() method, it is difficult to conceive test cases for read methods.

A provider that implements BytesMessage using a DataInputStream or equivalent, is likely to only throw MessageFormatException for the readUTF() method.

The other likely exceptions are MessageEOFException for stream overruns, and JMSException for any other error.
As BytesMessage does not support conversion, NumberFormatException is unlikely to be thrown.

See:

Section 3.11.3, Conversions Provided by StreamMessage and MapMessage

Test cases:

org.exolab.jmscts.test.message.bytes.BytesMessageTest.testReadFailure

message.stream.read

If a read method of a StreamMessage throws a MessageFormatException or NumberFormatException, the current position of the read pointer must not be incremented. A subsequent read must be capable of recovering from the exception by re-reading the data as a different type.

See:

Section 3.11.3, Conversions Provided by StreamMessage and MapMessage
Table 3-7

Test cases:

org.exolab.jmscts.test.message.stream.StreamMessageTest.testReadFailure

message.map

A MapMessage is a message whose body contains a set of name-value pairs where names are Strings and values are Java primitive types. The entries can be accessed sequentially by enumerator or randomly by name. The order of the entries is undefined.

See:

Section 3.11, JMS Message Body

Test cases:

org.exolab.jmscts.test.message.map.MapMessageTest.testMap

message.map.conversion

MapMessage supports the following conversion table. The marked cases must be supported. The unmarked cases must throw a JMS MessageFormatException. The String to numeric conversions must throw a java.lang.NumberFormatException if the numeric's valueOf() method does not accept the String value as a valid representation. MapMessage must implement the String to boolean conversion as specified by the valueOf(Stri ng) method of Boolean as defined by the Java language.

A value written as the row type can be read as the column type.

	boolean	byte	short	char	int	long	float	double	String	byte[ ]
boolean	X								X
byte		X	X		X	X			X
short			X		X	X			X
char				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
byte[ ]										X

See:

Section 3.11.3, Conversions Provided by StreamMessage and MapMessage
Table 3-7

Test cases:

org.exolab.jmscts.test.message.map.MapMessageTest.testConversion
org.exolab.jmscts.test.message.map.MapMessageTest.testInvalidConversion
org.exolab.jmscts.test.message.map.MapMessageTest.testInvalidNumericConversion
org.exolab.jmscts.test.message.map.MapMessageTest.testStringConversion

message.map.null

For MapMessage, attempting to read a null value as a Java primitive type must be treated as calling the primitive's corresponding valueOf(String) conversion method with a null value. Since char does not support a String conversion, attempting to read a null value as a char must throw NullPointerException.

See:

Section 3.11.3, Conversions Provided by StreamMessage and MapMessage

Test cases:

org.exolab.jmscts.test.message.map.MapMessageTest.testNullConversion

message.map.unset

Getting a MapMessage field for a field name that has not been set is handled as if the field exists with a null value.

See:

Section 3.11.3, Conversions Provided by StreamMessage and MapMessage

Test cases:

org.exolab.jmscts.test.message.map.MapMessageTest.testUnset

message.stream.conversion

StreamMessage supports the following conversion table. The marked cases must be supported. The unmarked cases must throw a JMS MessageFormatException. The String to numeric conversions must throw a java.lang.NumberFormatException if the numeric's valueOf() method does not accept the String value as a valid representation. StreamMessage must implement the String to boolean conversion as specified by the valueOf(String) method of Boolean as defined by the Java language.

A value written as the row type can be read as the column type.

	boolean	byte	short	char	int	long	float	double	String	byte[ ]
boolean	X								X
byte		X	X		X	X			X
short			X		X	X			X
char				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
byte[ ]										X

See:

Section 3.11.3, Conversions Provided by StreamMessage and MapMessage
Table 3-7

Test cases:

org.exolab.jmscts.test.message.stream.StreamMessageTest.testConversion
org.exolab.jmscts.test.message.stream.StreamMessageTest.testInvalidNumericConversion
org.exolab.jmscts.test.message.stream.StreamMessageTest.testStringConversion

message.map.case

MapMessage field names are case sensitive.

NOTE: the specification does not explicitly mention this requirement, but it is in keeping with property name requirements.

See:

Section Undefined, An implied requirement

Test cases:

org.exolab.jmscts.test.message.map.MapMessageTest.testCase

message.stream.null

For StreamMessage, attempting to read a null value as a Java primitive type must be treated as calling the primitive's corresponding valueOf(String) conversion method with a null value. Since char does not support a String conversion, attempting to read a null value as a char must throw NullPointerException.

NOTE: the specification is not explicit on the behaviour of invoking writeBytes() or writeString() with a null value, but an acceptable policy is to throw a NullPointerException. This is in keeping with the behaviour of DataOutputStream.

See:

Section 3.11.3, Conversions Provided by StreamMessage and MapMessage

Test cases:

org.exolab.jmscts.test.message.stream.StreamMessageTest.testNull

message.foreign

A provider must be prepared to accept, from a client, a message whose implementation is not one of its own. A message with a 'foreign' implementation may not be handled as efficiently as a provider's own implementation; however, it must be handled.

Note that if the foreign message implementation contains a JMSReplyTo header field that is set to a foreign destination implementation, the provider is not required to handle or preserve the value of this field.

See:

Section 3.12, Provider Implementations of JMS Message Interfaces

Test cases:

org.exolab.jmscts.test.message.foreign.ForeignMessageTest.test

message.copy

The JMS message interfaces provide read/get methods for accessing objects in a message body. All of these methods must be implemented to return a copy of the accessed objects.

See:

Section 3.12, Provider Implementations of JMS Message Interfaces

Test cases:

org.exolab.jmscts.test.message.copy.MapMessageTest.testByteArrayCopy
org.exolab.jmscts.test.message.copy.MapMessageTest.testPartialSetBytesCopy
org.exolab.jmscts.test.message.copy.MapMessageTest.testSetBytesCopy
org.exolab.jmscts.test.message.copy.BytesMessageTest.testPartialWriteBytesCopy
org.exolab.jmscts.test.message.copy.BytesMessageTest.testWriteBytesCopy
org.exolab.jmsct s.test.message.copy.ObjectMessageTest.testByteArrayCopy
org.exolab.jmscts.test.message.copy.ObjectMessageTest.testCopyAtConstruction
org.exolab.jmscts.test.message.copy.ObjectMessageTest.testCustomObjectCopy
org.exolab.jmscts.test.message.copy.StreamMessageTest.testByteArrayCopy
org.exolab.jmscts.test.message.copy.StreamMessageTest.testPartialWriteBytesCopy
org.exolab.jmscts.test.message.copy.StreamMessageTest.testWriteBytesCopy

properties.copy

The JMS message interfaces provide read/get methods for accessing message object properties. All of these methods must be implemented to return a copy of the accessed objects.

See:

Section 3.12, Provider Implementations of JMS Message Interfaces

Test cases:

message.bytes.method.clearBody

When clearBody is called on a BytesMessage, the body of the message is in write-only mode.

If clearBody is called on a message in read-only mode, the message body is cleared and the message is in write-only mode.

See:

http://java.sun.com/products/jms/javadoc-102a/javax/jms/BytesMessage.html

Test cases:

org.exolab.jmscts.test.message.clear.SendReceiveClearTest.testBytesClearBodyOnReceipt
org.exolab.jmscts.test.message.clear.ClearTest.testBytesClearBody
org.exolab.jmscts.test.message.clear.ClearTest.testBytesClearBodyOnCreation

message.bytes.method.readBytes(1)

Refer to javadoc

See:

http://java.sun.com/products/jms/javadoc-102a/javax/jms/BytesMessage.html#readBytes(byte[ ] )

Test cases:

org.exolab.jmscts.test.message.bytes.BytesMessageTest.testReadBytes
org.exolab.jmscts.test.message.bytes.BytesMessageTest.testReadBytesForEmptyStream1

message.bytes.method.readBytes(2)

Refer to javadoc

See:

http://java.sun.com/products/jms/javadoc-102a/javax/jms/BytesMessage.html#readBytes(byte[ ] , int)

Test cases:

org.exolab.jmscts.test.message.bytes.BytesMessageTest.testPartialReadBytes1
org.exolab.jmscts.test.message.bytes.BytesMessageTest.testPartialReadBytes2
org.exolab.jmscts.test.message.bytes.BytesMessageTest.testReadBytesForEmptyStream2
org.exolab.jmscts.test.message.bytes.BytesMessageTest.testReadBytesIndexException

message.bytes.method.writeObject

Refer to javadoc

See:

http://java.sun.com/products/jms/javadoc-102a/javax/jms/BytesMessage.html#writeObject()

Test cases:

org.exolab.jmscts.test.message.stream.StreamMessageTest.testWriteObject
org.exolab.jmscts.test.message.bytes.BytesMessageTest.testInvalidObject
org.exolab.jmscts.test.message.bytes.BytesMessageTest.testWriteObject

message.map.method.setObject

Refer to javadoc

See:

http://java.sun.com/products/jms/javadoc-102a/javax/jms/MapMessage.html#setObject()

Test cases:

org.exolab.jmscts.test.message.map.MapMessageTest.testInvalidObject
org.exolab.jmscts.test.message.map.MapMessageTest.testSetObject

message.map.method.itemExists

Refer to javadoc

See:

http://java.sun.com/products/jms/javadoc-102a/javax/jms/MapMessage.html#itemExists()

Test cases:

org.exolab.jmscts.test.message.map.MapMessageTest.testItemExists

message.map.method.getMapNames

Refer to javadoc

See:

http://java.sun.com/products/jms/javadoc-102a/javax/jms/MapMessage.html#getMapNames()

Test cases:

org.exolab.jmscts.test.message.map.MapMessageTest.testGetMapNames

message.stream.method.clearBody

When clearBody is called on a StreamMessage, the body of the message is in write-only mode.

If clearBody is called on a message in read-only mode, the message body is cleared and the message is in write-only mode.

See:

http://java.sun.com/products/jms/javadoc-102a/javax/jms/StreamMessage.html

Test cases:

org.exolab.jmscts.test.message.clear.SendReceiveClearTest.testStreamClearBodyOnReceipt
org.exolab.jmscts.test.message.clear.ClearTest.testStreamClearBo dy
org.exolab.jmscts.test.message.clear.ClearTest.testStreamClearBodyOnCreation

message.stream.method.writeObject

Refer to javadoc

See:

http://java.sun.com/products/jms/javadoc-102a/javax/jms/StreamMessage.html#writeObject()

Test cases:

org.exolab.jmscts.test.message.stream.StreamMessageTest.testInvalidObject

message.stream.method.writeBytes(1)

Refer to javadoc

See:

http://java.sun.com/products/jms/javadoc-102a/javax/jms/StreamMessage.html#writeBytes(byte[ ] )

Test cases:

org.exolab.jmscts.test.message.stream.StreamMessageTest.testReadWriteBytes
org.exolab.jmscts.test.message.stream.StreamMessageTest.testWriteBytes

message.stream.method.writeBytes(2)

Refer to javadoc

See:

http://java.sun.com/products/jms/javadoc-102a/javax/jms/StreamMessage.html#writeBytes(byte[ ] , int, int)

Test cases:

org.exolab.jmscts.test.message.stream.StreamMessageTest.testReadWriteBytes
org.exolab.jmscts.test.message.stream.StreamMessageTest.testWriteBytes

message.stream.method.readBytes

Refer to javadoc

See:

http://java.sun.com/products/jms/javadoc-102a/javax/jms/StreamMessage.html#readBytes

Test cases:

org.exolab.jmscts.test.message.stream.StreamMessageTest.testFullReadBytes
org.exolab.jmscts.test.message.stream.StreamMessageTest.testIncrementalReadBytes
org.exolab.jmscts.test.message.stream.StreamMessageTest.testPartialReadBytes
org.exolab.jmscts.test.message.stream.StreamMessageTest.testReadBytesClearBody1
org.exolab.jmscts.test.message.stream.StreamMessageTest.testReadBytesClearBody2
org.exolab.jmscts.test.message.stream.StreamMessageTest.testReadBytesReset1
org.exolab.jmscts.test.message.stream.StreamMessageTest.testReadBytesReset2

properties.group

JMSXGroupID and JMSXGroupSeq are standard properties clients should use if they want to group messages. All providers must support them. JMSXGroupID is a string property. JMSXGroupSeq is an int property, starting at 1. @todo - need to verify if the range is applicable

See:

Section 3.5.9, JMS Defined Properties
Table 3-3

Test cases:

org.exolab.jmscts.test.message.properties.JMSXGroupTest.testJMSGroupSeq
org.exolab.jmscts.test.message.properties.JMSXGroupTest.testJMSGroupSeqRange
org.exolab.jmscts.test.message.properties.JMSXGroupTest.testJMSXGroupID

properties.provider

JMS reserves the 'JMSX' property name prefix for JMS defined properties. Unless noted otherwise, support for these properties is optional. The Enumeration ConnectionMetaData.getJMSXPropertyNames() method returns the names of the JMSX properties supported by a connection. Properties that may only be set by the provider include JMSXUs erID, JMSXAppID, JMSXDeliveryCount, JMSXProducerTXID, JMSXConsumerTXID, JMSXRcvTimestamp and JMSXState.

See:

Section 3.5.9, JMS Defined Properties
Table 3-3

Test cases:

org.exolab.jmscts.test.message.properties.IdentifierTest.testJMSXProviderIdentifiers

connection.metadata.properties

ConnectionMetaData provides a list of the JMS defined property names supported by the connection. This must include JMSXGroupID and JMSXGroupSeq

See:

Section 3.5.9, JMS Defined Properties

Test cases:

org.exolab.jmscts.test.connection.MetaDataTest.testMetaData

subscriber.nolocal

In some cases, a connection may both publish and subscribe to a topic. The subscriber NoLocal attribute allows a subscriber to inhibit the delivery of messages published by its own connection.

See:

Section 6.11, Topic Subscriber

Test cases:

org.exolab.jmscts.test.topic.NoLocalTest.testNoLocal

subscriber.durable

If a client needs to receive all the messages published on a topic, including the ones published while the subscriber is inactive, it uses a durable TopicSubscriber. JMS retains a record of this durable subscription and insures that all messages from the topic's publishers are retained until either they are acknowledged by this durable subscriber or they have expired.

See:

Section 6.11.1, Durable Topic Subscriber
Section 6.3, Durable Subscription

Test cases:

org.exolab.jmscts.test.topic.DurableSubscriberTest.testDurableSubscriber

subscriber.durable.clientId

Sessions with durable subscribers must always provide the same client identifier. In addition, each client must specify a name that uniquely identifies (within client identifier) each durable subscription it creates.

See:

Section 6.11.1, Durable Topic Subscriber

Test cases:

subscriber.durable.unique

Only one session at a time can have a TopicSubscriber for a particular durable subscription.

See:

Section 6.11.1, Durable Topic Subscriber
Section 4.3.2, Client Identifier

Test cases:

org.exolab.jmscts.test.topic.DuplicateDurableSubscriberTest.testDuplicateSubscriber
org.exolab.jmscts.test.topic.DuplicateDurableSubscriberTest.testDuplicateSubscriberPerSession

subscriber.durable.changing

A client can change an existing durable subscription by creating a durable TopicSubscriber with the same name and a new topic and/or message selector. Changing a durable subscription is equivalent to deleting and recreating it.

See:

Section 6.11.1, Durable Topic Subscriber

Test cases:

org.exolab.jmscts.test.topic.DurableSubscriberTest.testChangeSubscription

subscriber.durable.unsubscribe

TopicSessions provide the unsubscribe method for deleting a durable subscription created by their client. This deletes the state being maintained on behalf of the subscriber by its provider. It is erroneous for a client to delete a durable subscription while it has an active TopicSubscriber for it or while a message received by it is part of a current transaction or has not been acknowledged in the session. (Note: this last sentence suggests that a provider doesn't need to check that a client can remove a subscription)

See:

Section 6.11.1, Durable Topic Subscriber

Test cases:

org.exolab.jmscts.test.topic.DurableSubscriberTest.testUnsubscribe

asf.connectionconsumer

For application servers, connections provide a special facility for creating a ConnectionConsumer. The messages it is to consume are specified by a destination and a message selector. In addition, a ConnectionConsumer must be given a ServerSessionPool to use for processing its messages. A maxMessages value is specified to limit the number of messages a ConnectionConsumer may load at one time into a ServerSession's session.

See:

Section 8.2.4, ConnectionConsumer

Test cases:

org.exolab.jmscts.test.asf.ConnectionConsumerTest.test

destination.remove

If a destination is removed via the provider's administration interface, and subsequently recreated, all messages to that destination must also be removed.

See:

Section Undefined, An implied requirement

Test cases: