| Summary | In this article we discuss Orbix scope, what they are, where they are defined and which variables are visible to a scope. |
|---|---|
| Article Number | 29563 |
| Environment | Orbix All platforms 6.3.X |
| Question/Problem Description |
What is a Configuration Scope? |
| Clarifying Information | |
| Error Message | |
| Defect/Enhancement Number | |
| Cause | |
| Resolution |
An Orbix configuration is divided into configuration scopes. Applications can have their own configuration scopes, and specific parts of applications (specific ORBs) can have ORB-specific scopes.
Scopes are typically organized into a hierarchy of scopes, whose fully-qualified names map directly to ORB names. By organizing configuration variables into various scopes, you can provide different settings for individual ORBs, or common settings for groups of ORBs.
An initializing ORB maps to a configuration scope through its ORB name. For example, if an initializing ORB is supplied with a command-line -ORBname argument of company.operations, it uses all variable settings in that scope, and the parent company and root scopes. Settings at narrower scopes such as company.operations.finance, and settings in unrelated scopes such as company.production, are unknown to this ORB and so have no effect on its behavior. There are a variety of ways to associate an ORB to an orb name. Discussing this is outside the bounds of this article.
It is possible to view the entire Orbix configuration with the command: itadmin config dump In the returned configuration a scope is defined by its name followed by a sub configuration enclosed in curly brackets, { }. For example: event_log:filters = ["IT_CORE=FATAL"]; demos
{
orbix_ws
{
event_log:filters = ["IT_CORE=*", "*=FATAL ERROR"];
cxx_server
{
event_log:filters = ["*=*"]; orb_plugins = ["local_log_stream", "iiop_profile", "giop", "giop_snoop", "iiop", "bus_loader", "routing"];
binding:client_binding_list = ["GIOP IIOP"];
plugins:routing:wsdl_url = "echo.wsdl";
};
cxx_client
{
orb_plugins = ["local_log_stream", "iiop_profile", "giop", "giop_snoop", "iiop", "bus_loader", "routing"];
binding:client_binding_list = ["GIOP IIOP"];
plugins:routing:wsdl_url = "echo.wsdl";
};
};
In this example, event_log:filters = ["IT_CORE=FATAL"]; is in the root scope. The scope demos is a scope containing no variables and one sub scope demos.orbix_ws. The scope demos.orbix_ws contains one variable event_log:filters = ["IT_CORE=*", "*=FATAL ERROR"]; and two scopes, cxx_server and cxx_client. Inside the demos.orbix_ws.cxx_server, the variable event_log:filters has the value ["*=*"]. Inside the scope demos.orbix_ws.cxx_client the variable event_log:filters inherits the value for event_log:filters as ["IT_CORE=*", "*=FATAL ERROR"].
Use the command itadmin variable show -scope <<your scope>> <<your variable name>> to view the value of a variable inside of a specific scope. For example: itadmin variable show -scope test.application.server variable:test This command returns the variable and its value if it exists, or an error message if the variable was not set inside that scope. If the variable is not present in that scope it may still inherit a value from a parent scope. We need to check each parent scope in broadening order to check if the variable is defined. In the example we would then check the scope test.application. itadmin variable show -scope test.application.server variable:test If the variable is not defined inside test.application.server but is defined inside test.application then the scope test.application will inherit the value. If the variable was defined in both scopes then value is overridden by the most specific scope, in the example test.application.server. |
| Workaround | |
| Notes |
Related Documentation:
“Related KB Article(s):” 000029243, "How to list configurable plugins used by an ORB" |
| Attachment |
| Created date: | 06 March 2012 |
|---|---|
| Last Modified: | 13 February 2013 |
| Last Published: | 14 March 2012 |
| First Published date: | 14 March 2012 |
#KnowledgeDocs
#Orbix
