The `<registry>` element

The <registry> element in file config.xml has the following syntax.

<registry roles="role1, role2, …" >
  <server env="environment1, environment2, …" roles="role1, role2, …" serverid="serverID" />
  <systemproperty name="name" value="value" default="default" />
</registry>

File config.xml contains exactly one required <registry> element. The <registry> element can contain zero to many <server> and <systemproperty> elements.

The attributes on the various elements have the following meanings.

Element	Attribute	Required	Description
`registry`	`roles`	Yes	List of valid cluster roles.
`server`	`env` `serverid` `roles`	No	The `<server>` attribute entries are legacy and not required. These attributes have the following meanings: `env` - The name of the environment in which the server operates. The default is `null`. The value of `env` is immutable while the server is running. `serverid` - Unique server name of a server instance in the cluster. If you do not specify this value explicitly, PolicyCenter sets it to the `hostname` of the PolicyCenter server. `roles` - Specifies role or roles to assign to the server specified by `serverid`. It is a better practice to set these server attributes using JVM options during server startup. For example, the following JVM option sets both the server ID and server roles: `-Dserverid="dev2#messaging,scheduler"` Use the # syntax to indicate the following text is a server role and not a server ID.
`systemproperty`	`name`	Yes	Specifies the name of the Java `-D` system property that you want to redefine. This value can be one of the following: `env` `serverid` If you run multiple server instances on the same host machine, define a `serverid` value for each server instance with a separate `systemproperty` entry.
	`value`	Yes	New name of the system property.
	`default`	Yes	Default property value to use if you do not specify a value at the command prompt.

The following code shows an example <registry> element.

<registry roles="batch, scheduler, workqueue, messaging, startable, ui, custom1">
  <systemproperty name="env" value="my.env" default="production"/>
  <systemproperty name="serverid" value="my.id" default="myDefault"/> 
</registry>

Notice that:

The set of valid server roles includes a custom role (custom1).
There are two system property redefinitions, one for env and one for serverid.

Default server roles

If you run the PolicyCenter application as a single server (not in a clustered environment), Guidewire assigns all of the defined server roles to that server by default.

Property `serverid.noroles`

In standard usage, the value of property serverid includes also the list of server roles defined for that server. If you want to use this property in code, without the list of server roles, use serverid.noroles instead. For example, instead of using gw.pc.serverid, use gw.pc.serverid.noroles to suppress the list of server roles associated with this server ID.

Logging environment

The env property has special significance for logging behavior. If the env value is non-null, PolicyCenter tries to obtain the logging configuration from a config/logging/env-log4j2.xml file. If this file does not exist or if env is null, then the logging configuration is taken from the default log4j2.xml file.

Creating special server roles

It is possible to define new server roles by adding the role to the list of roles specified by the roles attribute on the <registry> element.

Accessing system properties in code

Gosu class gw.api.system.server.ServerUtil contains methods for working with system properties associated with servers.

The <registry> element