> > >The final idea floating around is that of multiple configurations. I am >thinking that there are many deploy directories in the MainDeployer now (it >is capable of scanning many directories not just the /deploy one) and we >should take advantage of this. Maybe we could have >/conf/default/<bare>-service.xml >/conf/medium/<more>-service.xml >/conf/nineyards/<everything>-service.xml >
What is the point of providing multipule configurations? What are the expected usage of them? Do we expect users to use one of the provided configurations with out changing them? I mean, are we trying to provide a set of configurations which will be useable with no configuration in the users enviornment? I would hope not. We are talking about the configuration structure which is generated by the build system for use in development, testing and for release. The development role is way to complex to provide configurations for each use, so lets forget that one. For testing, we want to provide a config (or configs) which will cover all aspects of the system... which is a fat task and should be done externally by the JBoss/Testsuite module. That leaves us to the configuration structure for a release. What do we expect users todo with a release distribution? Do we expect them to use those configs asis in a production environment? I would hope not. We want to provide new users who are not famillar with JBoss or app servers with a painless way to get positive results that the 10 megs they just downloaded and uncompressed wasn't a waste of there time. We want a user to get the server started with a single command and no configuration and have that user go to the admin console and have their first look at a functional JBoss server. Ok, so that takes care of a large percentage of users... and we probably want to limit what does into this config. Next there are the more technical guys (and gals) which want to play around with the more advanced features of the server. We can expect that they will have the depth to read some docs first and perform some optional configuration. Then we are back in the same boat as above, a one command, jboss starts and they have positive feed back that it works. Lastly, you have the folks that want to play with the misc fluffy goodness which needs some serious code written and application specific hook up. We want to provide them with some example files and some simple howto docs on making those more complicated or configuration intensive components work. So, from my perspectifve, the configs which ship are purly educational. I would expect anyone who is going to be serving up a serious production application to tune the configuration as needed. Could be the default config that is tuned, could be the advanced, or could be hand rolled. I think we are kidding ourselves if we expect anything more. Which brings me back to the above more than one deploy directory, which is now quite easily added by adding another DeploymentScanner, or simply by adding another directory (soon to be url) list in the default one. What would that buy us? Given the different usage which I expect, I don't see that it buys anything... in fact it just complicates the default confgurations. It also means that if a user wants to change the config they have to edit a file, instead of usign the --config parameter on the command line. The above scheme looks more tailord to reducing file duplication, which I admit is something to keep in mind when working with a production setup with lots of server nodes... but that isn't what these configs are for. We should only be providing configs for the three types of users with a release... but make sure that the servers configuration systems will not keep it from functioning in a more diverse environment. Now, it could be that I just don't understand the full details of multipule deploy dirs... wouldn't be the first time I didn't understand something you were talking about =P --jason PS. One of my first pains with JBoss (~2.0) was trying to get it to run in the environment which fit my operational needs. This turned out to be no easy task, since the system was so tied to its release structure to run. I eventually gave up trying to force JBoss into my layout and wrote some ant magic to take my requirements and then generate a JBoss environment... which is rather backwards when you think about it. _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
