application (type application), clients (type client),

servers (type servers), system (type system)

XML Source

<xs:element name="tc-config"> <xs:complexType> <xs:all> <xs:element minOccurs="0" name="system" type="system"> <xs:annotation> <xs:documentation> The 'system' section contains configuration data that affects the entire Terracotta system as a whole; things like the configuration mode go here. </xs:documentation> </xs:annotation> </xs:element> <xs:element minOccurs="0" name="servers" type="servers"> <xs:annotation> <xs:documentation> This section defines the servers present in your Terracotta system. You can omit this section entirely, in which case it behaves as if there's a single server with all values set at their default. You can include exactly one server entry here (the common case), or, if you're going to run multiple servers for failover, you can include multiple servers here. If you include more than one server here, note that each server will need to know which configuration it should use as it starts up. If you name your servers according to the host that they run on (and no host contains more than one server), then they will find the hostname themselves and work automatically. If you name your servers in any other fashion (and, again, only if there is more than one 'server' element present here), then you will need to pass the command-line option "-n <![CDATA[ <name> ]]> " to the start-tc-server script, passing it the name of a server configuration from this file. </xs:documentation> </xs:annotation> </xs:element> <xs:element minOccurs="0" name="clients" type="client"> <xs:annotation> <xs:documentation> This section contains settings that affect all clients that connect to the system. Note that while these settings are applied uniformly across all clients, this does not prevent you from applying different settings to various clients. There are two ways of doing this: Certain parameters ('logs', below) undergo parameter expansion before being used by the client. This allows you to use various predefined substitutions (like '%h' for host), or a general one (%(myprop) to use the value of Java system property 'myprop'), for these values; expansions are carried out in each client's JVM independently. For each client to have its own configuration you can set 'tc.config' to the configuration file. If the configuration model is production then the 'application' section for all of the clients comes from the application section of the server's config file. </xs:documentation> </xs:annotation> </xs:element> <xs:element minOccurs="0" name="application" type="application"> <xs:annotation> <xs:documentation> This section contains items that affect the core behavior of Terracotta as it relates to your application. This data must be kept consistent across clients and servers in order for Terracotta to function properly, and so the system will enforce this. </xs:documentation> </xs:annotation> </xs:element> </xs:all> </xs:complexType> </xs:element>

Content Element Detail

This section contains items that affect the core behavior of Terracotta as it relates to your application. This data must be kept consistent across clients and servers in order for Terracotta to function properly, and so the system will enforce this.

Type:	application, complex content
Defined:	locally, within this element

XML Source

<xs:element minOccurs="0" name="application" type="application"> <xs:annotation> <xs:documentation> This section contains items that affect the core behavior of Terracotta as it relates to your application. This data must be kept consistent across clients and servers in order for Terracotta to function properly, and so the system will enforce this. </xs:documentation> </xs:annotation> </xs:element>

This section contains settings that affect all clients that connect to the system. Note that while these settings are applied uniformly across all clients, this does not prevent you from applying different settings to various clients. There are two ways of doing this: Certain parameters ('logs', below) undergo parameter expansion before being used by the client. This allows you to use various predefined substitutions (like '%h' for host), or a general one (%(myprop) to use the value of Java system property 'myprop'), for these values; expansions are carried out in each client's JVM independently. For each client to have its own configuration you can set 'tc.config' to the configuration file. If the configuration model is production then the 'application' section for all of the clients comes from the application section of the server's config file.

Type:	client, complex content
Defined:	locally, within this element

XML Source

<xs:element minOccurs="0" name="clients" type="client"> <xs:annotation> <xs:documentation> This section contains settings that affect all clients that connect to the system. Note that while these settings are applied uniformly across all clients, this does not prevent you from applying different settings to various clients. There are two ways of doing this: Certain parameters ('logs', below) undergo parameter expansion before being used by the client. This allows you to use various predefined substitutions (like '%h' for host), or a general one (%(myprop) to use the value of Java system property 'myprop'), for these values; expansions are carried out in each client's JVM independently. For each client to have its own configuration you can set 'tc.config' to the configuration file. If the configuration model is production then the 'application' section for all of the clients comes from the application section of the server's config file. </xs:documentation> </xs:annotation> </xs:element>

This section defines the servers present in your Terracotta system. You can omit this section entirely, in which case it behaves as if there's a single server with all values set at their default. You can include exactly one server entry here (the common case), or, if you're going to run multiple servers for failover, you can include multiple servers here. If you include more than one server here, note that each server will need to know which configuration it should use as it starts up. If you name your servers according to the host that they run on (and no host contains more than one server), then they will find the hostname themselves and work automatically. If you name your servers in any other fashion (and, again, only if there is more than one 'server' element present here), then you will need to pass the command-line option "-n <name>" to the start-tc-server script, passing it the name of a server configuration from this file.

Type:	servers, complex content
Defined:	locally, within this element

XML Source

<xs:element minOccurs="0" name="servers" type="servers"> <xs:annotation> <xs:documentation> This section defines the servers present in your Terracotta system. You can omit this section entirely, in which case it behaves as if there's a single server with all values set at their default. You can include exactly one server entry here (the common case), or, if you're going to run multiple servers for failover, you can include multiple servers here. If you include more than one server here, note that each server will need to know which configuration it should use as it starts up. If you name your servers according to the host that they run on (and no host contains more than one server), then they will find the hostname themselves and work automatically. If you name your servers in any other fashion (and, again, only if there is more than one 'server' element present here), then you will need to pass the command-line option "-n <![CDATA[ <name> ]]> " to the start-tc-server script, passing it the name of a server configuration from this file. </xs:documentation> </xs:annotation> </xs:element>

The 'system' section contains configuration data that affects the entire Terracotta system as a whole; things like the configuration mode go here.

Type:	system, complex content
Defined:	locally, within this element

XML Source

<xs:element minOccurs="0" name="system" type="system"> <xs:annotation> <xs:documentation> The 'system' section contains configuration data that affects the entire Terracotta system as a whole; things like the configuration mode go here. </xs:documentation> </xs:annotation> </xs:element>