Daniel Ockeloen wrote: > 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.
I think that is just what I did, I did look into the more general problem. At least for the reading part of the problem. I haven't concerned myself about writing them yet, but why would that not be more then putting them in a readable spot? > 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). That is not true; in my proposal you can still write in the config dir, because the proposed ClassLoader will look there, and even will prefer it above all other locations. If running as a war, of course you would probably not succeed writing new files there, because WEB-INF is not directory, so you cannot create a file there, but that won't be the case in any case. I suppose that your current implementation would not allow for working in a war, but you loose nothing: simply don't do that then, you couldn't do it before my hack, you will not be able to do it after it.... But, I can imagine that it is solvable then. Perhaps I stressed to much that my proposal involves wars. It hardly does. It only involves the possibility to put any resource on a spot loadable from inside a war too, so also the builder and module XML's which were the greatest barrier for this to be possible until now. > 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 method for obtaining a certain configuration file, I provided. Setting, no, not yet. A general way for that seems a bit trickier, because in some cases it is probably not possible. > 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. I considered overriding also 'findResources' of my class-loader, which can then e.g. give back all 'magazines.xml'. The problem remains how to decide which and what should be prefered over which or what. It would be outside the scope of my hack-proposal. Storing resources in the database would be a possible improvement on this, which I did not implement nor as yet propose. > 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. Even obtaining _all_ XML configuration files can be done, I think, by ResourceLoader#getSubResources(XML_Pattern, true /*recursive*/). Michiel -- Michiel Meeuwissen mihxil' Mediacentrum 140 H'sum [] () +31 (0)35 6772979 nl_NL eo_XX en_US
