Interaction between config files and config repository

Hi everybody,

I was wondering, if I would use local config files and the configuration of the config repository together and both configurations have some common parameters, which of the values will be used? Those from the local configuration file or those from the repository?

Background of the question: I've found out that some of the configuration parameters from the config repository (obtained through itadmin config dump) doesn’t really propagate to the IORs that are using the configuration repository.

Thank you and have a nice day!


  • Thank you for posting this question.

    Which configuration parameters from the CFR don't appear to be used by the server?

    The "itadmin config dump" command will provide the configuration presented to the server, regardless of whether it is from the CFR, or a configuration file. However, it is possible for the server to override these settings using input parameters, or hard-coded values.

    If you provide more specific information around the problem you are seeing, we may be able to help.
  • In reply to Pat Morrissey:

    Hi Pat,

    Well I think it's a more complex question. I have configured some general service parameters using the CFR, and some specific using the local file. I'm sure that I and my team didn't mess up the namespacing at this point. So here is an example:

    CFR contains the general configuration for logging and security. On the other side, the local file contains only the specific part of the configuration, and that is policy setting (i.e. policies:target_secure_invocation_policy:requires or policies:target_secure_invocation_policy:supports).
    If I would check the configuration of the IOR per iordump, it is clear that the local (specific) configuration isn't considered at all. Some default values (I suppose) will be used:

    "Target supports: NoProtect Integrity Confidentiality DetectReplay DetectMisordering EstablishTrustInTarget EstablishTrustInClient
    Target requires: NoProtect"

    You can assume that we're not using any hard-coded values or input parameters.

    So the questions are:
    1) Is there any precedence rule for the CFR and the local files?
    2) Is there any document that describes which defaults are used if the configuration isn't taken into account?

    3) Maybe I've misunderstood something: According to the administration guide, the command "itadmin config dump" shows the content of the configuration repository. Form your previous post I understand it provides the configuration presented to the server. Is there any way to see only the content of the configuration repository without using any GUI-Tools?

    Thank you very much for your time!

  • In reply to cristian_dragnea:

    An Orbix application’s configuration can be defined in either local .cfg file, or in the CFR. We do not recommend mixing the two, as this approach is not tested.

    Can you clarify why you are taking this unusual approach?

    Please try setting the Orbix applications’ configuration in the CFR, and not local .cfg files.

    Thank you and best regards,
    Micro Focus SupportLine
  • For CFR bases domains there are still two text based configuration files referred to as "handler files" of the name <domain>.cfg and cfr-<domain>.cfg. These are essentially used for bootstrap configuration for the CFR boot-orb. Pat is correct that the definitive contents of the configuration are visible with the "itadmin config dump" command. The exception is the substitution variables that are actually identified with subst variable names like %{SUBST_STRING} in the CFR and shown in the config dump which are replaced by the values specified in the handler files at runtime. This is done intentionally since the handler files would be located on the physical machine with machine specific settings for these variables.
  • In reply to Pat Morrissey:

    Thanks for your reply.
    Unfortunately, I cannot clarify this unusual approach better than using the words: >>legacy software<<!!! :)

  • In reply to cristian_dragnea:

    True, but in reality all software deployed to a production environment can really be considered "legacy."