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.
What I have been missing all along is a clear statements of basic principles, like what are the problems you are trying to solve. The way things are now, you're proposing too many different things at once, certainly too many for a vote. I think it helps to distinguish several issues. 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. 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. 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. 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? 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. Rob van Maris Technical Consultant Quantiq xmedia & communication solutions Koninginneweg 11-13 1217 KP Hilversum T +31 (0)356257211 M +31 (0)651444006 E [EMAIL PROTECTED] W http://www.quantiq.com
