First pass design: There are exactly two registries defined. If we need more later we will refactor.

The core "in-memory" Registry is basically defined by a hashtable. If something is not found there then Synapse automatically looks up the key in the other registry. The other registry is defined by an interface and you can configure the provider using the following XML syntax:

<syn:registry provider="o.a.s.r.HTTPRegistry">
  <property name="prop-for-HTTPRegistry" value="...">

At the moment the properties in our config

<property name="" value=""/>


  1. only strings
  2. only loaded from this XML (i.e. not pulling in an external resource)

This proposes changing this. Instead of having each mediator pull XML config or metadata in its own way, we can extend the properties to support XML, and then have the mediators grab the XML from the "in-memory" registry.

mediator <== property <== (value | inline | src | lookup)

So here is the enhanced property xml:

 <property name="foo" [value="string"] [src="url to XML"] [key="string-key"]>

Note that the particular approach of <property name="" key=""/> is really just an aliasing mechanism.

If you specify a key then it will lookup the entry *whenever* you use it. Of course we will optimize cache etc this.

The core in-memory registry is actually the SynapseEnvironment properties model. The other registry is just a mapping from keys (strings) to XML fragments (OMNode).

SynapseEnvironment {
   Object getProperty(String name);
   XMLRegistry getXMLRegistry();

public interface XMLRegistry {
  OMNode lookup (String key);
  OMNode lookupIfModified (String key, long since);
  void insert (key, OMNode);