Support bar overrides for policies within a bar file

RFE Review. Thank you for taking the time to raise this enhancement request. Unfortunately on this occasion this is not an idea we plan to take forward on the grounds that we feel such a change would increase complexity for the user in what can already be quite a difficult area for users to understand the precedence of overriding behaviour between environments. The intended concept of a policy file is to be able to abstract away from a message flow a set of configuration parameters which are likely to change as the flow moves from one environment to another. The policy itself just provides the parameters, and essentially isn't "testable" in its own right .. only when a policy is referenced from a flow does an artifact (the flow) exist which can be tested. Policies are intended to vary from one environment to another. Carrying policies in a BAR file gives a developer a quick way to facilitate the provision of connection details into a runtime environment through an easy mechanism (the act of deploying - provides the configuration and code together in a single BAR file) which doesn't require the developer to have direct access to the file system of the runtime. The existing policy mechanism also lets the product administrator (if one exists) to exert additional control over a specific environment by placing policies into the overrides directory of the server's working directory. These local policy files are letting the administrator "override" the policy which is carried in the BAR file (and which is persisted to the "run" directory). If an override xml file (similar to the broker.xml file used by the mqsiapplybaroverride command) were used in addition to this, then the user would need to contend with three different levels of potential override: 1. The initial value in the policy, 2. The override in the BAR file and 3. The override of the policy in the overrides directory in the working directory of the server.

Thinking around the scenario you posed for the way in which you use the ACE product to run your particular current deployments, we wonder if one practice you might wish to consider would be to name your policies separately depending on the environment they are to be used in ... and then direct the message flow to use "Policy_TEST" or "Policy_PRODUCTION" by updating the message flow node property using your existing mqsiapplybaroverride mechanism. On the face of it this would seem to achieve the override capability you are seeking, using existing product capablility and also remaining true to the concept of a policy file being specific to a particular environment.