> > 1) is there a real reason one can not manage with the axis2.xml inside > > reository? campare the complexity to the code now and before ..I would > > say YAGNI > > It can be in the repo if you want .. but the repo is now spsed to be a > URL; so it can be used to boot up a server in a cluster by pointing to a > repo on another machine for example. (Deepal's in the middle of the URL > support.) +1 agreed it is a reasonable use case
> > 2) The system properties are BAD ..same reason the static parameters are > > BAD. > > It has possible secuirty threats and source for bugs. I know Axis did > > it .. which I belive is a mistake > > 3) The parameters should be in client API no body will notice system > > properties. Check axis archives how meny people did know about Axis > > has a system property for configuration file. I think it is not even > > 1% of all users.. there are tons of mails asking how to make client > > config acrive? > > It is a client API thing .. system property is just the way for the > shell scripts etc. to get it into the system. You can always create your > own config (see AxisConfigurator) and get the config info from > anywhere .. the system property and file system configurator etc. are > all conveniences. Basically the *entire* system can be fluffed up from a > database if you want or from memory or from a Web site or whatever. > > I don't agree that's YAGNI because the cluster scenario is a good simple > usecase. right now client API (Service Client) do not have a way to set it, but that is easy thing to fix. if system property is there there is a certain security risk involved, e.g. 1) If I have a servlet that load before Axis2 servlet (some cases putting a aa war will do the trick) 2) and all servlets run on a j2ee container that share some of class loaders .. usually JRE class loaders are shared (I knows Jboss 3.x did it, may be others do) I can make axis2 installation to load a security module with a backdoor for me by setting a system property. I know this is far fetched scenario, but as we are going to actively use security, may be it is good idea to worry about this kind of things. I would say we should stick to .. no static things (no static variables, no system properties ......) Thanks Srinath
