XML Registry implementation

This document presents information related to the default XML Registry service configuration and operation.

For a general description of the Registry usage and API, check the default Registry presentation.

For a complete description of the XML syntax of the Registry, check the Registry XML Syntax documentation.

Overview

The XML Registry uses disk based XML files, called "Registry fragments", to store its different entries. Upon startup, it will load all the fragments it can find as referenced by its configuration and populate dynamic memory based Registries of elements taht can be accessed through the Registry Service interface.

It will also periodically monitor the configured directory for any changes in the registry fragments or new fragments to load.

Finally, if any memory based Registries are changed because of some entries are added, set or removed programmatically, it will automatically save these changes before loading any fragments modified on disk. It will also always save the Registry state on shutdown.

Usage recommendation

This registry is very easy to use because you can simply modify the XML files on disk and they will be automatically loaded without stopping Jetspeed. It's also fast because most of the work is entirely done is memory.

However, this implementation has 2 main limitations:

  • it uses a lot of memory, especially if you define many entries through syndication
  • it works only with a granularity of fragments and so may have some issues if you deal with online and offline entry simulatenous modifications that affect the same fragment.

If any of these 2 limitations are a concern for you, we suggest that you use the SQL based OJB implementation.

Configuration

The configuration of this implementation is very simple. Here's a copy of the default configuration values in the JetspeedResources.properties file and a detailed table of configuration options.

#########################################
# Registry Service                      #
#########################################
services.Registry.classname=
  org.apache.jetspeed.services.registry.CastorRegistryService
services.Registry.directory=/WEB-INF/conf/
services.Registry.mapping=/WEB-INF/conf/registry.xml
services.Registry.default.Portlet=local-portlets
services.Registry.default.PortletControl=local-managers
services.Registry.default.PortletController=local-managers
services.Registry.default.MediaType=local-medias
services.Registry.default.Skin=local-skins
services.Registry.default.Security=local-security
services.Registry.default.Client=local-clients
services.Registry.extension=.xreg
# Refresh rate, in seconds.  0 = no refresh.  Min value = 60
services.Registry.refreshRate=300
      
OptionDescrption
services.Registry.classname

Required

The name of the implementation to use for the Registry service
services.Registry.directory

Required

The directory where the registry needs to look for fragments
services.Registry.extension

Optional

Default: .xreg

All fragments that have this extension will be recognized by this instance and loaded by the registry.
services.Registry.refreshRate

Optional

Default: 300

The number of seconds between disk refreshes. A value of 0 would mean that there will be no refresh. A hard coded minimum of 10 seconds has been implemented to avoid unnecessary disk usage.
services.Registry.mapping

Optional

Default: ${webapp}/WEB-INF/conf/mapping.xml

The Castor mapping file that is used to load and save the XML files.

Do not change this file if you are unsure of what you are doing, this may break your Jetspeed installation
services.Registry.default.Portlet

Required

The fragment that will store new Portlet entries that have been added programmatically.
services.Registry.default.PortletControl

Required

The fragment that will store new Control entries that have been added programmatically.
services.Registry.default.PortletController

Required

The fragment that will store new Controller entries that have been added programmatically.
services.Registry.default.Skin

Required

The fragment that will store new skin entries that have been added programmatically.
services.Registry.default.MediaType

Required

The fragment that will store new media type entries that have been added programmatically.
services.Registry.default.Client

Required

The fragment that will store new client entries that have been added programmatically.
services.Registry.default.Security

Required

The fragment that will store new security entries that have been added programmatically.
services.Registry.verbose

Optional

Default: 0

This option controls the amount of debugging output generated by the regsitry if DEBUG logging mode is activated. 0 is minimum level and 3 is maximum verbosity. This is only useful for debugging purposes.

Working with the registry

This section presents some advices, tips and useful info for working with the XML registry implementation.

Do not add new portlets to the standard files

You should always create your own fragments, like the local-* fragments defined in the configuration file. This will guarantee that your changes won't be forgotten if you upgrade your installation.

If you have both online and offline entry creations...

You will save you a lot of headache by creating 2 local fragments, one for storing the entries added online, like the local-* fragments, and the other for manual update, like manual-* fragments. This will greatly minimize the risk of change collisions.

Always shut down properly your application server

Since the registry is auto-saved on shutdown, you should ensure that it completes properly or risk registry corruption and data loss. For production environment, a daily backup of the configuration files through a scheduled job is recommended to mitigate such risks.

Fragments created by the feed daemon

When using OCS syndication, the feed daemon will automatically create and rewrite fragments that with the syndicated entries.

These fragments have the following name convention: feed_<feedname>

Do not edit or modify these files as any changes will be lost when the feed daemon will next update the feed