Bug 117467 - There is no API to get the in memory config values & /ccm/ds/config/ doesn't show in memory config values
There is no API to get the in memory config values & /ccm/ds/config/ doesn't ...
Status: CLOSED WONTFIX
Product: Red Hat Web Application Framework
Classification: Retired
Component: other (Show other bugs)
nightly
All Linux
medium Severity high
: ---
: ---
Assigned To: ccm-bugs-list
Jon Orris
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-03-04 06:50 EST by Daniel Berrange
Modified: 2007-04-18 13:03 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-02 13:36:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Daniel Berrange 2004-03-04 06:50:08 EST
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:
Comment 1 Daniel Berrange 2006-09-02 13:36:00 EDT
Closing old tickets

Note You need to log in before you can comment on or make changes to this bug.