Essentials Overview Features License Installation FAQ Sample Sites Resources Todo Changes Download Binaries Source Code Supporting Projects Documentation Configuration Guide Javadocs Development Portlet Howto Portlet Catalog Jetspeed Trailmap Components Registry Security Syndication WAP Customization Cache PSML Get Involved Contributors CVS Repository CVS Branches Coding Spec Bug Database |
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
> Option | Descrption
> 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
Copyright © 1999-2002, Apache Software Foundation