[Deploying Sakai] [Building Sakai] What do you think about Config Viewer?

Matthew Jones jonespm at umich.edu
Thu Jan 7 18:35:52 PST 2010


Thanks for all the +1's.

When I was starting to modify config editor to persist settings we locally
discussed this. It's not going to write or modify files so thats off the
table. The options as you mentioned are:

On a system restart:
1) The properties that are in the database set by the editor override the
properties in the flat files. (Database authority) This made the most sense
to me

2) You have to go into the editor admin UI after the system is restarted and
click something like "Apply database settings"

The desired operation of this behavior could be also controlled through a
property. ;)
config.editor.authority=database/files

In either case, when the system started up, log messags would be printed
saying something like:

*DB Authority:*
WARNING: Property defined in local file(s) as <something> overriden to
<something else>
*
File Authority:*
INFO: Property defined in local file(s) as <something> NOT overriden to
<something else>, must be done manually

(Note we opted 'at the time' not to continue the work to modify config
editor for use in the project we were working on, instead using a simpler
config perister. But the ideas were still relevant and I still remember most
of what was necessary and the meetings we had about it)

 -Matthew


On Thu, Jan 7, 2010 at 8:59 PM, Jon Gorrono <jpgorrono at ucdavis.edu> wrote:

> We also recognized but avoided the sticky questions as to where the
> authoritative setting comes from: static prop file? if changed live,
> and live changes are authoritative, then does the tool then rewrite
> the prop file for the next time sakai is bounced? If not, then do the
> db settings then become the authoritative values for boot time?
>
> writing props files can get ugly too with sakai, local, secure,
> instance? prop files differently named and divided into possibly
> arbitrary categories
>
> So with that idea aside, then dynamically changed values would *not*
> be authoritative and static prop files, the authority. In that case,
> IMO there ought to be a way to make it very easy for admins to find
> those changed values so that they can be optionally persisted. This
> could include writing of files to be compared against static ones....
>
> jp
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/production/attachments/20100107/40c933cc/attachment.html 


More information about the production mailing list