Sakai should have more flexibilty in reading properties files.
Description
Environment
Test Plan
is related to
relates to
Activity
Ray Davis July 24, 2009 at 8:53 AM
In the "Services and Framework" section of http://confluence.sakaiproject.org/display/DOC/Release+Notes+%282.6%29 , follow the link from "Support for more flexible configuration of components".
Jean-François Lévêque July 24, 2009 at 7:40 AM
Ray, I can't see anything about it in the2.6.0 release notes. Which other documentation were you refering to?
Ray Davis January 3, 2008 at 2:00 PM
Merged branch into trunk at revision: 39741.
I'll leave this assigned to me since 2.6.0 release notes and other documentation will need to be dealt with.
Ray Davis December 20, 2007 at 12:36 PM
Put on hold pending further discussion.
Ray Davis December 18, 2007 at 1:50 PMEdited
Good points and good ideas, Jason. Before Antranig started work on his auto-proxying branch and we started talking about OSGi, I thought of experimenting with a central component configurer object something along the lines you describe. Getting this branch's externalized configuration support in place would help with such experimentation: for example, we could easily use internally-maintained configuration file(s) to define a translation map from old-style implementation-bean override properties to new-style configuration object properties. Again, though, that would be its own, more ambitious, JIRA task, building on but separate from this one.
Sakai currently reads a fixed list of property files. It should read a variable number of properties files that can be organized as most efficient for the implementor. The fixed list of files is fine for simple installations, but when multiple instances of Sakai need to be maintained and some properties need to vary by instance and some need to stay the same it become unwieldly to try to keep monolithic files up to date. It would be better to be able so separate out the things that remain the same from values that vary by instance.
Sakai should read in all properties files in the sakai.home directory (sorting by file name to ensure they are read in a consistent order) and then read in the files that it currently reads in. Since values in files read later take precedence this allows folks to add new files organized to the current set of properties files and not have the values in sakai.properties mysteriously overridden. Properties can be migrated from sakai.properties gradually and they only need to be migrated at the conveinence of the implementor.