Rob van Maris wrote: > Only a few people reacting is probably due to the bloated discussion > that followed your initial posting. You just can't expect everyone to > read though the whole discussion just to find out exactly what you're > proposing, especially if the proposal keeps changing. Your latest > posting suffers from the same problem, since it refers to the former > discussion.
I can hardly change it. It's no use posting code without some clarifications. I don't expect everybody to read it, but if you are interested, it is at least readable. It also helps forming my own thoughts of course. It's quite a lot of work implementing (and testing this), so I prefer to request for comments in an early stage, to avoid this work, if people don't want it anyway. I'm glad you reacted. > 1 - We need a unified method for reading configurations. This enables us > to implement it in a way that works for both expanded webapps and > webapps running from a (not expanded) WAR-file. I agree. Indeed, that is excactly the point. The whole thing is basicly about this. > 2 - You propose that configuration files may be stored in several > places. These are searched successively in a predefined order. I don't > agree. Allowing the same configuration files in several places, one > location taking precedence above the other, is unnecessary and > confusing. Instead I think all the configuration files should go in one > place, precisely as is the case with like WEB-INF/config now. This is > easiy, convenient and straightforward for everyone, novice and expert > alike. Of course, the 'search path' should be as short as possible and WEB-INF/config is certainly the preferred location. I do see some merits in a several locations though. It seems e.g. useful to remain supporting the ancient 'mmbase_config' option. This allows supporting for placing all mmbase configuration outside the web-root. But because it is a fall-back mechanisme you can also use it to place only one or two files outside the web-root. E.g. I imagine that it could be conventient to place only jdbc.xml and log4j.xml outside your war, and the rest still in it. Those files are often for other people (the ones installing the site..). You'll have this option, though of course, it would not be the setup of e.g. the distro. > At present it's already confusing that the database configuration files > (mysql.xml, postgres.xml, etc.) are in the classpath instead of in the > config directory. I don't know why it was put there. As far as I'm > concerned it's an ill-advised move, it should be undone, and we should > not proceed in this direction. > 3 - You propose the classpath as a location for configuration files. A > bad idea in my opinion. It's not appropriate, and not in line with > common practise in J2EE. With the exception of the occasional > propertyfile off course, but these are usually used for configuration of > the runtime. A dedicated config directory outside the classpath is more > appropriate for application configuration like most MMBase configuration > files. 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. 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. Another example are those database XML's. I'm not interested in those. I simply want to place mmbase-hsql.jar (or mmbase.jar :-) and then I should be able to use HSQL. hsql.xml I consider a part of the hsql layer implementation, and the fact that it is XML rather then java-code I consider an implementation detail. Of course, it can be convenient if I can override this XML to tune the hsql-configuration, but I hope I will never have to! So, I would envision a clean mmbase-installation with an WEB-INF/config containing only configuration file which really do need your attention. WEB-INF/config/databases is a bit obfuscating because to configure my database I must look into WEB-INF/config/modules/jdbc.xml. > 4 - You propose a unified method for writing configurations. This may be > a good idea, but needs more elaboration. What is the purpose? Where are > the configurations stored? Are we talking about writing the current > configuration or ad-hoc creation of configurations to be stored? The purpose is to be able to write web-based configuration tools. The configuration is principally stored on the same spot was were it was read from. So, if caches.xml was read from WEB-INF/config it will also be stored there. But e.g. if your set-up does not allow for that (e.g. WEB-INF is mounted read-only, or the war is packed), you could set things up that it saves differently. E.g. by defining a mmbase_config directory pointing to a writable place, or by installing the 'resources' builder. If you haven't done so, you'd probably end up with an exception, which probably is what you want, but at least you'd have the option not to. You could of course also create new configuration resources, but when you do that, you (or your code) should of course know what you are (it is) doing, because obviously a new XML is pointless if there is no code to read it. > Like I mentioned before, it will be of great help for a proper > discussion to separate out the different issues and treat them > successively in the proper order. Actually I can present the thing quite simply: - I want to add ResourceLoader.java (plus some associated classes) to mmbase core which then should be used to load (and save) configuration files. Then, I will probably get questions about implementation details, and impact, so I tried to ellaborate on that. If one is not interested in those, and trust that I have solved that decently, the issue is simple. In the actual HACK I will probably present it this simply, and refer to the code, apidoc, example, and this discussion for those who need more detail to come to an opinion. greetings, Michiel -- Michiel Meeuwissen mihxil' Mediacentrum 140 H'sum [] () +31 (0)35 6772979 nl_NL eo_XX en_US
