Hi, For what it's worth, I was under the same impression as Rohit - that administrators would edit components.xml to fit their deployment.
See for example this snippet from "Extending CloudStack Networking" [1]: > "Generally, it is expected that the cloud administrator will configure components.xml to avoid this clash." I can see advantages to keeping this behvaior, but I may be missing part of the picture. Thanks, Dave. [1] https://cwiki.apache.org/CLOUDSTACK/extending-cloudstack-networking.html On Tue, Feb 26, 2013 at 6:25 PM, Hugo Trippaers < htrippa...@schubergphilis.com> wrote: > Heya Rohit, > > Why would a sysadmin need to change this? They should be considered part > of the source code, any configuration should be done via the config in the > database or with the *.properties files. > > Cheers, > > Hugo > > > -----Original Message----- > > From: rohityada...@gmail.com [mailto:rohityada...@gmail.com] On Behalf > > Of Rohit Yadav > > Sent: Tuesday, February 26, 2013 10:22 AM > > To: cloudstack-dev@incubator.apache.org > > Cc: Hugo Trippaers; w...@widodh.nl > > Subject: Help with packaging and doc for sysadmins > > > > Hi Hugo and Wido, > > > > Earlier we used to have components.xml from where a sysadmin could > > enable/disable components for ex. a plugin. > > Now we've applicationContext and other *Context xml files, but I see them > > copied to WEB-INF/classes: > > cloud-client-ui-4.2.0-SNAPSHOT/WEB-INF/classes/applicationContext.xml > > > > How will a sysadmin change them, will they be copied to > > /etc/cloudstack/* path or sysadmin would need to edit them wherever the > > exploded war is installed? > > > > Regards. >
