> > >What is on deploy/ should really only be used for development and adding >dynamically say a datasource. > >PERIOD. >
Deploy is also being used to deploy user services, support services and such... >Putting all the deployment in there and removing the service.xml from conf >is a bad idea. >Do you hear me... a *bad* idea. > >The service.xml from conf is the STATIC configuration, and it should REALLY >BE THE WAY WE SHIP OUR STUFF. > I don't belive that anyone is sugessting this... I certainly was not. >In clear you develop your solutions with the sar trick, you deploy new stuff >eventually but when it comes down to locking your servers for production or >shipping a product with JBoss YOU PUT OUT A SERVICE.XML IN THE CONFIGURATION >DIRECTORY and the files in lib/ext. > And how does this XML file get processed? By placing it in the deploy directory right? >because we can then change the configuration in one file. I don't buy the >"I remove a file and I removed the stuff", because I can just as well remove >the xml entry and I removed the service and since the SAR makes the xml >unreachable its a pain. End of case. > The concept here, which is becoming clearer to me over time is that we would rather have users leave the core jboss-service.xml alone and provide a specific user-service.xml which has all of there config isolated. This makes is nice and clean when upgrading to a new JBoss, simply extract, copy custom user-service.xml (and whatever others) as well as support .ear/.jar/.sars and thats it! No need to diff the old and new files for changes... >You are turning what is a trick in development (hotcycling your services) >and what is a nice way to extend services in your servers with datasources >and new services, into a silly standard. Bottom line you can't work on the >XML, there are 24 configuration files (one per service) and the whole thing >is silly. > We have to split up the config into smaller files currently to allow seperate modules to execute/update config files with out having to do any messy cross module config file maintenece. It is just a mess to maintain it the other way around. Now that we have mbean depends, then isolating the different services into seperate config files allows users to easily remove parts of there config with out having to understand too much. Most of these files do not need any configuration. Some do, and as I mentioned before I think we should setup an example config (or something) which users will have to configure to use first. --jason _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
