If the directory/file paths specified in this guide do not exist in your WSO2 product, see Directory Structure of WSO2 Products to locate the paths applicable to your product.
||
Skip to end of metadata
Go to start of metadata

Users can change the default configurations by editing the <PRODUCT_HOME>/repository/conf/registry.xml file using the information given below. Click on the table and use the left and right arrow keys to scroll horizontally. 

XML Elements 

XML elementAttributeDescriptionData typeDefault valueMandatory/
Optional
Sample
<wso2registry>



Mandatory
<cacheConfig>
When an application requests to use a particular resource stored in the registry or creates/modifies a resource in the registry, the Carbon server will cache the resource for subsequent use. The <cacheConfig> element in this file is used to configure the time period for which a resource can be cached.



<lastAccessedExpirationMillis>
Specifies the time period for which a resource in the registry will be cached after it is read by an application.
15Optional<lastAccessedExpirationMillis>60000</lastAccessedExpirationMillis>
<lastModifiedExpirationMillis>
Specifies the time period for which a resource in the registry will be cached after it is created or modified.
15Optional<lastModifiedExpirationMillis>60000</lastModifiedExpirationMillis>
__<currentDBConfig>

The server can only handle one active configuration at a time. The currentDBConfig parameter defined in the registry.xml is used to specify the database configuration that is active at present. The value of the currentDBConfig parameter should be a valid name of a database configuration defined on the registry.xml file.

Stringwso2registryMandatory<currentDBConfig>wso2registry
</currentDBConfig>
__<readOnly>

To run the registry in read-only mode, set the readOnly element to true. Setting the read-only mode allows you to run an immutable instance of registry repository. This setting is valid on a global level.

BooleanfalseMandatory<readOnly>false</readOnly>
__<enableCache>
To enable registry caching, set the enableCache element to true. Once caching is enabled, repetitive read operations will be executed against the cache instead of the database. This setting is valid on a global level.BooleantrueMandatory<enableCache>true</enableCache>
__<registryRoot>

The registryRoot parameter can be used to define the apparent root of the running instance of the server. This setting is valid on a global level.

String/Mandatory<registryRoot>/</registryRoot>
__<dbConfig>

String
Mandatory<dbConfig name="wso2registry">

name
Stringwso2registry

<validationQuery>N/A

You can configure this parameter under the <dbConfig> element of the <PRODUCT_HOME>/repository/conf/registry.xml file.

When you are maintaining DB connections, it is always recommended to use a validation query to check the health of the TCP connection of the connections that stay in the DB connection pool.

Since opening connections is an expensive and time consuming operation, after a connection is created, it will be kept open for a specific time in the pool. When re-using these connections from the pool, there can be situations that the TCP connection to the DB is interrupted and the connection consumer gets errors such as communication link failures etc.

To avoid that you can use a validation query always as a best practice. It is an SQL statement specific to the DBMS type, which runs before using the connection.

StringN/AOptional<validationQuery>SELECT 1 FROM DUAL</validationQuery>
<testOnBorrow>N/AThis validates the connection objects before borrowign them from the pool. If the object fails to validate, it will be dropped from the pool, and another will be attempted to borrow. This property can be added to the <dbConfig> element in the <PRODUCT_HOME>/repository/conf/registry.xml file.BooleantrueOptional<testOnBorrow>true</testOnBorrow>
__ __<dataSource>

Stringjdbc/WSO2CarbonDBMandatory<dataSource>jdbc/WSO2CarbonDB
</dataSource>
__<handler>

Handlers are pluggable components, that contain custom processing logic for handling resources. All handlers extend an abstract class named Handler, which provides default implementations for resource handling methods as well as a few utilities useful for concrete handler implementations.

Handler implementations can provide alternative behaviors for basic resource related operations, by overwriting one or more methods in the Handler class.

String
Optional

class
String

<handler class="org.wso2.carbon.registry
.extensions.handlers.SynapseRepositoryHandler">
__<filter>

String
Optional

class
String

<filter class="org.wso2.carbon.registry.core.jdbc
.handlers.filters.MediaTypeMatcher">
__<remoteInstance>

In order to mount an external registry, you have to define the remote instance. This could use either the JDBC-based configuration, the Atom-based configuration model or the WebService-based configuration model.



Optional

urlThe URL of the remote instance.Stringhttps://localhost:9443/registry
remoteInstance url="https://localhost:9443/registry">
__<ID>
Remote instance ID.StringinstanceidOptional<id>instanceid</id>
__<username>
Username of the remote registry login.StringusernameOptional<username>username</username>
__<password>
Password of the remote registry login.StringpasswordOptional<password>password</password>
__<dbConfig>
The database configuration to use.Stringwso2registryOptional<dbConfig>wso2registry</dbConfig>
__<readOnly>

To run the registry in read-only mode set the readOnly element to true. Setting the read-only mode allows you to run an immutable instance of registry repository. This setting is valid only for the specific remote instance.

StringfalseOptional<readOnly>false</readOnly>
__<enableCache>
To enable registry caching, set the enableCache element to true. Once caching is enabled, repetitive read operations will be executed against the cache instead of the database. This setting is valid only for the specific remote instance.StringtrueOptional<enableCache>true</enableCache>
__<registryRoot>

The registryRoot parameter can be used to define whether the apparent root of the running instance of the server. This setting is valid only for the specific remote instance.

String/Optional<registryRoot>/</registryRoot>
__<mount>

Once a remote instance has been defined, a collection on the remote registry can be mounted to the local instance.



Mandatory<mount path="/_system/config" overwrite="true|false|virtual">

pathThe path to which the mount will be added to.String/_system/config


overwriteWhether an existing collection at the given path would be overwritten or not.
true|false|virtual

__<instanceID>
Remote instance ID.
instanceidMandatory<instanceId>instanceid</instanceId>
__<targetPath>
The path on the remote registry.String/_system/nodesMandatory<targetPath>/_system/nodes</targetPath>
__<versionResourcesOnChange>
You can configure whether you want to auto-version the resources (non-collection) by setting versionResourcesOnChange element to true. In this configuration it will create a version for the resources whenever it is updated.BooleanfalseMandatory<versionResourcesOnChange>false
</versionResourcesOnChange>
__<staticConfiguration>

While most configuration options can be changed after the first run of the WSO2 Governance Registry, changing the Static Configuration (configuration details under the staticConfiguration parameter), will not be fully effective. If you need to change any Static Configuration and expect it to take effect, you will have to erase the contents of the database, and restart the server passing the -Dsetup system property which will re-generate the database.

Deprecation of -DSetup

When proper Database Administrative (DBA) practices are followed, the systems (except analytics products) are not granted DDL (Data Definition) rights on the schema. Therefore, maintaining the -DSetup option is redundant and typically unusable. As a result, from January 2018 onwards WSO2 has deprecated the  -DSetup option. Note that the proper practice is for the DBA to run the DDL statements manually so that the DBA can examine and optimize any DDL statement (if necessary) based on the DBA best practices that are in place within the organization.

You are supposed to change the static configuration section only before loading any data to the registry (That is before the first start-up).



Mandatory<staticConfiguration><versioningProperties>true</versioningProperties> <versioningComments>true</versioningComments><versioningTags>true</versioningTags><versioningRatings>true</versioningRatings></staticConfiguration>
__ __<versioningProperties>
Whether the properties are versioned when a snapshot is created.BooleantrueMandatory
__ __<versioningComments>
Whether the comments are versioned when a snapshot is created.BooleantrueMandatory
__ __<versioningTags>
Whether the tags are versioned when a snapshot is created.BooleantrueMandatory
__ __<versioningRatings>
Whether the ratings are versioned when a snapshot is created.BooleantrueMandatory
  • No labels