Kees Jongenburger wrote: > I understand your problem. I don't think confiruation has to be stored in xml, there > shoud be a > java interface to add configuration.
Personally I think that XML is not a bad way to drive configuration. AFAIK, nowhere in MMBase this XML is used in memory then, it is always translated to some easier to use memory structure (usually a class with some members and maps). I think we may agree that configuration is always persistified on some way, and that on the most basic level you should be able to recover it as an InputStream. That's the only thing I would like to generalize for now. For the persistency locations I only implemented the two ways which are currently already used (namely as files (builder XML's, module XML's etc) , or as resources (DTD's Storage XML's etc).. Those two ways I want to unify and make then indistiguishable for the MMBase programmer. The MMBase user may choose then how she want to provide those (most of these) things. If we come up with a completely general way to deal with the configuration streams itself, that may be nice, but that is not where we are talking about right now. > While talking to michiel we "found out" that there are 2 types of configuration > stuff like > builders (for wich there is only 1 file). but there are also more files that needs > "merging" when > an other file is found. Yes, I feel strongly that there are actually two kinds of configurations, mergable and not-mergable (with some overlap, of course). E.g. the security.xml is definitely not-mergable, and fieldtypedefinitions.xml will be definitely mergable. But this too I think is more related to how you should handle the InputStream, then to how you should acquire them (to which my proposal is related in the first place). Of course, when dealing with non-mergeable resources, you could do several things when there are found more than one such resource, and this could principally be solved in the Resource-Loader itself. I did not do completely do that. If e.g. you have several jars with a security.xml (and no security.xml file), I suppose your in the hands of the JVM class-loader which will somehow decide which is the one which gets loaded. > on every startup and feed it to MMBase. I would like you to rephrase your -1 by > requireing that > is't possible to alter /add configuration on a runnig mmbase. (I hope we will be > able to store > such configuration in mmbase). As long as it are files, it will still work in excactly the same way as it did, meaning e.g. that you can use file-watcher and the like. When a resource is not a file, it gets trickier, and I have not ready-made sollution for that. But since it will have been loaded through our own classloader, I think it will be easy to implement some intervention. Michiel -- Michiel Meeuwissen mihxil' Mediacentrum 140 H'sum [] () +31 (0)35 6772979 nl_NL eo_XX en_US
