Chapter 3 Destinations : Inheritance

Inheritance
This section describes the inheritance of properties and permissions. For more information on wildcards, refer to Wildcards. For more information on destination properties, refer to Destination Properties. For more information on permissions, refer to Chapter 8, Authentication and Permissions.
Inheritance of Properties
All destination properties are inheritable for both topics and queues. This means that a property set for a "wildcarded" destination is inherited by all destinations with matching names.
For example, if you have the following in your topics.conf file:
foo.* secure
foo.bar
foo.bob
Topics foo.bar and foo.bob are secure topics because they inherit secure from their parent, foo.*. If your EMS server were to dynamically create a foo.new topic, it too would have the secure property.
The properties inherited from a parent are in addition to the properties defined for the child destination.
For example, if you have the following in your topics.conf file:
foo.* secure
foo.bar sender_name
Then foo.bar has both the secure and sender_name properties.
In the above example, there is no way to make topic foo.* secure without making foo.bar secure. In other words, EMS does not offer the ability to remove inherited properties. However, for properties that are assigned values, you can override the value established in a parent.
For example, if you have the following in your queues.conf file:
foo.* maxbytes=200
foo.bar maxbytes=2000
The foo.bar queue has a maxbytes value of 2000.
When there are multiple ancestors for a destination, the destination inherits the properties from all of the parents. For example:
> sender_name
foo.* secure
foo.bar trace
The foo.bar topic has the sender_name, secure and trace properties.
When there are multiple parents for a destination that contain conflicting property values, the destination inherits the smallest value. For example:
> maxbytes=2000
foo.* maxbytes=200
foo.bar
The foo.bar topic has a maxbytes value of 200.
Property inheritance is powerful, but can be complex to understand and administer. You must plan before assigning properties to topics and queues. Using wildcards to assign properties must be used carefully. For example, if you enter the following line in the topics.conf file:
> store=mystore
you make every topic store messages, regardless of additional entries. This might require a great deal of memory for storage and greatly decrease the system performance.
Inheritance of Permissions
Inheritance of permissions is similar to inheritance of properties. If the parent has a permission, then the child inherits that permission. For example, if Bob belongs to GroupA, and GroupA has publish permission on a topic, then Bob has publish permission on that topic.
Permissions for a single user are the union of the permissions set for that user, and of all permissions set for every group in which the user is a member. These permission sets are additive. Permissions have positive boolean inheritance. Once a permission right has been granted through inheritance, it can not be removed.
All rules for wildcards apply to inheritance of permissions. For example, if a user has permission to publish on topic foo.*, the user also has permission to publish on foo.bar and foo.new.
For more information on wildcards, refer to Wildcards. For more information on permissions, refer to User Permissions.