| ----- |
| Plexus Registry Component |
| ----- |
| Brett Porter |
| ----- |
| 7 February 2007 |
| ----- |
| |
| ~~ Licensed to the Apache Software Foundation (ASF) under one |
| ~~ or more contributor license agreements. See the NOTICE file |
| ~~ distributed with this work for additional information |
| ~~ regarding copyright ownership. The ASF licenses this file |
| ~~ to you under the Apache License, Version 2.0 (the |
| ~~ "License"); you may not use this file except in compliance |
| ~~ with the License. You may obtain a copy of the License at |
| ~~ |
| ~~ http://www.apache.org/licenses/LICENSE-2.0 |
| ~~ |
| ~~ Unless required by applicable law or agreed to in writing, |
| ~~ software distributed under the License is distributed on an |
| ~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY |
| ~~ KIND, either express or implied. See the License for the |
| ~~ specific language governing permissions and limitations |
| ~~ under the License. |
| |
| ~~ NOTE: For help with the syntax of this file, see: |
| ~~ http://maven.apache.org/guides/mini/guide-apt-format.html |
| |
| Plexus Registry |
| |
| The Plexus registry is a single source of external configuration for Plexus components and applications. |
| It can be used by components to source configuration, knowing that it can be used from within applications |
| without the information being hard coded into the component. |
| |
| To facilitate a variety of providers, {{{http://jakarta.apache.org/commons/configuration/} Commons Configuration}} |
| is used to implement the backing storage. |
| |
| This relies on a pull-based (or lookup) mechanism - the applications request specific pieces of configuration at |
| the time they need them, and it is retrieved from the registry. |
| |
| The registry is configurable so that configuration can be placed in any location desired, and is shared container |
| wide. A registry using the same file as other running VMs should operate correctly. |
| |
| <Note:> Inside the application server, this means that the scope is application wide as each application has it's |
| own container. It may be feasible to provide a single registry for the whole server, but this has not yet been |
| tested. This would only be necessary if the server was to dictate configuration locations that the registry was |
| not already configured to use. Of course, such additional locations could be added to the application registry |
| instances programmatically as well. |
| |
| * Example Configuration |
| |
| ----- |
| <component> |
| <role>org.codehaus.redback.components.registry.Registry</role> |
| <implementation>org.codehaus.plexus.registry.CommonsConfigurationRegistry</implementation> |
| <role-hint>commons-configuration</role-hint> |
| <configuration> |
| <properties> |
| <system/> |
| <jndi prefix="java:comp/env" config-optional="true"/> |
| <xml fileName="${user.home}/.m2/archiva.xml" config-optional="true" config-name="org.apache.maven.archiva" |
| config-at="org.apache.maven.archiva" config-forceCreate="true"/> |
| <properties fileName="${user.home}/.m2/security.properties" config-optional="true" |
| config-at="org.codehaus.plexus.security"/> |
| </properties> |
| </configuration> |
| </component> |
| ----- |
| |
| The configuration inside the outer <<<\<properties\>>>> element is equivalent to the |
| {{{http://jakarta.apache.org/commons/configuration/howto_configurationbuilder.html#Using_DefaultConfigurationBuilder} builder syntax}} |
| for Commons Configuration. This maps to similar concepts in the registry. |
| |
| In this example, the precedence is to first look in the system properties, then JNDI, then the given XML file, and |
| finally the given properties file. |
| |
| Registries can have 'sections', which are declared as partitioned areas of the registry. This is done using the |
| <<<config-name>>> attribute in Commons Configuration. While the sections behave normally as a part of the global |
| registry, they can easily be retrieved independently. This is particularly useful for write-back operations so the |
| file the section is stored in can be saved when the registry is modified. |
| |
| Each configuration source can be configured with a given mount-point in the registry using the <<<config-at>>> |
| attribute. This will cause all of the properties to be stored with the given prefix. |
| |
| * Using the Registry |
| |
| The registry can be used as a simple directory, for example: |
| |
| ----- |
| int value = registry.getInt( "test.property" ); |
| String text = registry.getString( "text.data" ); |
| boolean enabled = registry.getBoolean( "system.enabled", true ); |
| ----- |
| |
| The first parameter is always a key. The registry is hierachical, so in the key, a <<<.>>> (period) represents a |
| nested configuration, and can be traversed to any level. |
| |
| The second parameter specifies a default value. If it is not given, then <<<null>>> is returned for strings if the |
| key is not found in the registry, and an exception is thrown for integers and booleans under the same circumstances. |
| |
| ** Subsets and Sections |
| |
| There are two ways to work with a portion of the registry at a time: subsets and sections. |
| |
| Sections were encountered earlier - and while they return a subset it may span a number of different base prefixes, |
| depending on whether <<<config-at>>> was specified on the section or not. Even so, if it is a subset of the |
| hierachy, some elements of the hierachy at the same level might not be returned because they come from a different |
| section. |
| |
| On the other hand, subsets are reductions of the registry to keys descending from a given prefix. |
| |
| Once a subset (or section) is obtained, it behaves the same as the registry as a whole, however it will have fewer |
| values, and looking up values will not have the prefix as a part of the key. |
| |
| For example: |
| |
| ----- |
| String value = registry.getString( "org.codehaus.plexus.registry.value" ); |
| Registry subset = registry.getSubset( "org.codehaus.plexus.registry" ); |
| value = subset.getString( "value" ); // this will equal the earlier value retrieved |
| ----- |
| |
| ** Lists and Maps |
| |
| It is also possible to retrieve subsets of the registry as collections. |
| |
| * <<<getProperties(key)>>>: Maps and properties are straightforward - the subset is converted into key/value pairs |
| and returned as a map. |
| |
| * <<<getSubsetList(key)>>>: For lists of complex types that will still contain more than one key/value pair, |
| this method can be used to retrieve them as a list of subset registries. |
| |
| * <<<getList(key)>>>: For lists of simple types, this method can be used to get a list of value objects. |
| |
| ** Using Models |
| |
| To simplify the translation of configuration into reusable beans and to produce a self-documenting system, Modello |
| can be used to generate registry I/O classes. The appropriate goals in the plugin are <<<registry-reader>>> and |
| <<<registry-writer>>>. |
| |
| ** Saving Changes |
| |
| Saving changes to a registry is quite simple: |
| |
| ----- |
| registry.save(); |
| ----- |
| |
| Note that the registry must be a file-based section (saving the entire registry will not succeed). It will be saved |
| to the same location that it was loaded from. |
| |
| ** Adding Change Listeners |
| |
| ~~TODO |
| |