Ernst Bunders wrote: > Another option is to support different locations, but use only one at > any time. People that want to run mmbase from a war will have to deal > with the inconveneance. In the case of loading config files as resources > I would recommend a separate jarfile (ie mmbase-config.jar).
That would make code more complicated already, because I need to implement a jar-loader right away. I opted for suggesting a package only, and depending on normal class-loaders. Implementing loading configuration from jars directly can be useful too, for example you could have the same files in different jars, and still load them both (e.g. a 'fieldtypedefinition.xml' in several application-jars, which are then merged to 'the' fieldtypedefinitions' table inside mmbase core). I have not done this yet. Happily, because you are already complaining about things being too complicated... > I agree it is really confusing the way it is now. This dous not touch > your proposal, but should be addressed. If the configuration is in the > jar, it should be removed from the config dir. Perhaps leave a note > there to inform innocent users about the location change. Your problem is that the blob-dir setting is in the specific database-xml (which grantedly is perhaps a bit odly located). I think that wether you want blobs on dir is not specific to a certain database, and should not be configured in the specific database xml. I would suggest jdbc.xml. > > It depends on what you still see as configuration. E.g. a > > file like 'object.xml' I don't see as configuration, it is a > > resource, which is necessary for MMBase to run properly. You > > should not delete it, and probably should not change it either. > > But in your proposal It could be overwritten by placing a modified > version in a location with higher priority. Yes. I would not recommend that you do, though. > > > > > Anyhow, I feel that some configuration (like also the database > > 'configuration') is on the border of being configuration at > > all, and I'd like to be able to put them away in some jar. > > E.g. it would IMHO not be a strange idea to put an object.xml > > in mmbase.jar itself, to ensure that you cannot not have it. > > I have twoo situations allready where I have to overwrite the database > configuration inside the war (both related to blob storage ). Which > means I have configuration in three locations. This is no couse for > happyness to me. I totally agree It would be much nicer to have all > configuration in one place. That's completely what I suggest. In my proposal you could place your postgresql.xml in WEB-INF/config, though perhaps a default one will still be in mmbase.jar, making it possible to also run completely without it. But for me that's not configuration, it's a resource... Just like that you can run mmbase completely withouth caches.xml (just because every cache has default values for its settings). > > It would be nice to have a mechanism that ensures that you can write > configuration changes. But if too much complexity is the price (with > configuration all over the place and what to do if you want to upgrade > the site and so on) then how usefull will it be. I think it should allso > be a concern to keep mmbase simple. Not at all cost, but as a > consideration. I just want to give choice, and am worried about the packaging project which is, it seems, going to be mainly about writing configuration, so I would like to see it working, also in a case where e.g. the complete web-app is mounted read only. Did you look at resourceedit.jsp? Or the war I posted as an example? Michiel -- Michiel Meeuwissen mihxil' Mediacentrum 140 H'sum [] () +31 (0)35 6772979 nl_NL eo_XX en_US
