On Sep 18, 2004, at 12:08 AM, Michiel Meeuwissen wrote:
Hello,
I got sick and tired of mmbase not wanting to run as a war, and clumsy loading of configuration
files.
So I decided to do something about it, and I think I nearly succeeded. I am going to offer it as a hack on CVS
HEAD, but first, I'd like to start a bit of discussion on the subject, to avoid harvesting unnecessary
-1's because of implementation details.
Actually, the problem is not very big, because most configuration files are handled by one base
class (org.mmbase.util.xml.DocumentReader), and the idea was that if that class could be a bit
smarter lots of the issues would be solved.
Of course there would remain some problems, because on a few other spots in the MMBase code explicit
file handling is done. Most noticebly when loading the modules and builders because that depends on
File#listFiles.
Some other configuration implementations like those of logging and security also proved to depend
explicitely on Files but those can relatively easily be changed.
Sorry ill -1 or veto it if we at this time don't look at this in as a more general problem. I would love to see a way
we can run mmbase as a war but if we change the way we read/write config files lets tackle the whole problem or
alteast have a idea of how to solve this. This for example kills the whole package manager since i can't write to the
config dir anymore (since there is no way i can ask mmbase for a allowed place to write the files).
I would like to see a simple ConfigManager that has the task of keeping track of all the config files for MMbase. the Interface
should provide methods for obtaining for obtaining the xml file, setting the xml file, methods for optional controller classes (for the files
we have editors for).
The main gain is that we can make the Manager responsible for finding a allowed/prefered place on a local disk to write the files or for
the people who have been asking this for ages (not me) even store them in a database. This also allows us to think of dynamic config problems
like optional settings for a magazine in your mmbase instead of all magazines in your cloud without adding extra fields all the time.
The second gain is that for the first time you can atleast list/view/all the config files in some type of editor for administrators. When the core becomes
smaller and smaller and we get more applications the number of config files will go up and if we don't have a way of keeping track of
them we are asking for trouble.
Greetings,
Daniel.
