element <tc-config>
Namespace:
Type:
anonymous complexType
Content:
complex, 5 elements
Defined:
globally in terracotta-7.xsd, see XML source
Includes:
definitions of 5 elements
Used:
never
XML Representation Summary
<tc-config>
   
Content: 
tc-properties? × system? × servers? × clients? × application?
</tc-config>
Content model elements (5):
XML Source (see within schema source)
<xs:element name="tc-config">
<xs:complexType>
<xs:all>
<xs:element minOccurs="0" name="tc-properties" type="tc-properties">
<xs:annotation>
<xs:documentation>
This section defines the tc-properties
which the user wants to set
The order in which the properties would be overridden is the following
tc-properties from the installation jar
tc-properties from the tc-config
tc-properties from local tc.properties file
tc-properties set via system properties
Note that the local tc.properties has higher
preference than this section
</xs:documentation>
</xs:annotation>
</xs:element>
<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
application
Type:
application, complex content
Defined:
locally, within (this) tc-config element
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.
XML Source (see within schema 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>

clients
Type:
client, complex content
Defined:
locally, within (this) tc-config 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.
XML Source (see within schema 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>

servers
Type:
servers, complex content
Defined:
locally, within (this) tc-config 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.
XML Source (see within schema 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>

system
Type:
system, complex content
Defined:
locally, within (this) tc-config element
The 'system' section contains configuration data that affects the entire Terracotta system as a whole; things like the configuration mode go here.
XML Source (see within schema 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>

tc-properties
Type:
tc-properties, complex content
Defined:
locally, within (this) tc-config element
This section defines the tc-properties which the user wants to set The order in which the properties would be overridden is the following tc-properties from the installation jar tc-properties from the tc-config tc-properties from local tc.properties file tc-properties set via system properties Note that the local tc.properties has higher preference than this section
XML Source (see within schema source)
<xs:element minOccurs="0" name="tc-properties" type="tc-properties">
<xs:annotation>
<xs:documentation>
This section defines the tc-properties
which the user wants to set
The order in which the properties would be overridden is the following
tc-properties from the installation jar
tc-properties from the tc-config
tc-properties from local tc.properties file
tc-properties set via system properties
Note that the local tc.properties has higher
preference than this section
</xs:documentation>
</xs:annotation>
</xs:element>

This XML schema documentation has been generated with DocFlex/XML RE 1.7.2 using DocFlex/XML XSDDoc 2.1.0 template set.
DocFlex/XML RE is a reduced edition of DocFlex/XML, which is a tool for programming and running highly sophisticated documentation and reports generators by the data obtained from any kind of XML files. The actual doc-generators are implemented in the form of special templates that are designed visually using a high quality Template Designer GUI basing on the XML schema (or DTD) files describing the data source XML.
DocFlex/XML XSDDoc is a commercial template application of DocFlex/XML that implements a high-end XML Schema documentation generator with simultaneous support of framed multi-file HTML, single-file HTML and RTF output formats. (More formats are planned in the future).
A commercial license for "DocFlex/XML XSDDoc" will allow you:
  • To configure the generated documentation so much as you want. Thanks to our template technology, it was possible to support more than 300 template parameters (working the same as "options" of an ordinary doc-gen), which will give you an unprecedented control over the generated content!
  • To use certain features disabled in the free mode (such as the full documenting of substitution groups).
  • To enable/disable documenting of the initial, imported, included and redefined XML schemas selectively.
  • To document local element components both globally and locally (similar to attributes).
  • To enable/disable reproducing of namespace prefixes.
  • To format your annotations with XHTML tags and reproduce that formatting both in HTML and RTF output.
  • To insert images in your annotations using XHTML <img> tags (supported both in HTML and RTF output).
  • To use PlainDoc.tpl main template to generate all the XML schema documentation in the form of a single HTML file.
  • To use the same template to generate the incredible quality RTF documentation.
  • To document only selected XML schema components specified by name.
  • To remove this very advertisement text
Once having only such a license, you will be able to run the fully-featured XML schema documentation generator both with DocFlex/XML SDK and with DocFlex/XML RE, which is a reduced free edition containing only the template interpretor / output generator. No other licenses will be required!
But this is not all. In addition to it, a commercial license for DocFlex/XML SDK will allow you to modify the XSDDoc templates themselves as much as you want. You will be able to achieve whatever was impossible to do with the template parameters only. And, of course, you could develop any template applications by your own!
Please note: By purchasing a license for this software, you not only acquire a useful tool, you will also make an important investment in its future development, the result of which you could enjoy later by yourself. Every single your purchase matters and makes a difference for us!
To buy a license, please follow this link: http://www.filigris.com/shop/