Hello Some comment > -----Oorspronkelijk bericht----- > Van: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Namens Michiel Meeuwissen > Verzonden: dinsdag 19 oktober 2004 18:32 > Aan: [EMAIL PROTECTED] > Onderwerp: Re: Request for Discussion: mmbase.war and ResourceLoader. > > > 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.
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). > > > 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. 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. > > > 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. But in your proposal It could be overwritten by placing a modified version in a location with higher priority. > > 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. > > 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. 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. > > > 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 > > > > >
