Description of problem:
When a parameter context is loaded, it creates a ConfigRegistry
instance to load the params from storage. The params are then copied
into the ParameterContext impl. While ParameterContext objects are by
convention singleton objects, there is no standard API for retrieving
the singleton instance. In addition, the AbstractConfig class from
which most parameter context impls inherit doesn't use a singleton
ConfigRegistry for loading the parameters from storage - it creates a
new instance each time. The upshot of this, is that there is no way to
retrieve all the singleton parameter context objects & their currently
loaded values.

Thus when writing the config registry browser (/ccm/ds/config/) I had
to instantiate a whole new set of ParameterCOntext objects and load
them fresh from the persistent storage. One of my reasons for writing
this new developer support entry was to be able to identity the in
memory config values the server is currently using, and thus highlight
any which are not consistent with the persistent storage. This will be
a very important piece of debugging functionality for the PS support
teams when rickshaw goes into production, because already we've been
encountering 'apparent' bugs which were in fact simple a case of
someone calling 'ccm set' but forgetting to re-start the app server.
When we move into multi-JVM deployment this will become even more
critical.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Call 'ccm set' on some parameter
2. Visit /ccm/ds/config/
3.
  
Actual results:
The new confijg value is displayed

Expected results:
The old old value is displayed, along with highlighting showing the
pending new vlaue.

Additional info: