You can use wildcards when specifying statically created destinations in queues.conf and
topics.conf. The use of wildcards in destination names can be used to define "parent" and "child" destination relationships, where the child destinations inherit the properties and permissions from its parents. You must first understand wildcards to understand the inheritance rules described in
Inheritance.
Some destination properties are disjoint, and the server allows that property to be set only once for each destination. If an existing destination includes a value for a disjoint property and you attempt to assign a different value, the action will fail.
The topic topic.multicast.quotes.tibx would be assigned both channels,
multicast_1 and
multicast_2. Therefore, the wildcard topics
topic.multicast.> and
topic.multicast.quotes.* cannot coexist. Their creation would fail.
You can subscribe to a wildcard topic (for example foo.*), whether or not there is a matching topic in the configuration file (for example,
foo.*,
foo.>, or
foo.bar). However, if there is no matching topic name in the configuration file, no messages will be published on that topic.
TIBCO Enterprise Message Service enables you to use wildcards in queue names in some situations. You can neither send to nor receive from wildcard queue names. However, you can use wildcard queue names in the configuration files.
Messages published to multicast-enabled topics are sent on the multicast channels defined for those topics. A wildcard may cover multiple multicast-enabled topics, each on a different multicast channel.
A message consumer subscribed to topic > will receive messages published to
topic.info and
topic.quotes over TCP, will receive messages published to
topic.multicast.info over the multicast channel
channel-1 and messages published to
topic.multicast.quotes over the multicast channel
channel-2. Note that this means a wildcard consumer may receive messages over both multicast and TCP.
As described in Dynamically Creating Topics and Queues, the EMS server may dynamically create destinations on behalf of its clients. The use of wildcards in the
.conf files can be used to control the allowable names of dynamically created destinations.