I didn't expect to trigger such an elaborate discussion ;-) > Personally, I still think that parsing the server.xml and the > context.xml or whatever config files the webserver is using is the > second best option.
There is another problem - how can you get path to tomcat root directory? It's not that obvious... I can easily obtain real absolute path to directory where application is deployed but it does not have to be within tomcat (context registered outside tomcat root). Also acquiring working directory from java system properties is not ok because it changes - for example when tomcat is launched from within Eclipse during development then java working dir is set to Eclipse home... > The best option imho would be simply configure it with an external > configuration file / system and don't spend too much time with magic > and trickery. The point is that we are preparing processing system with unknown (dynamically changing) amount of slave servers. What we were trying to achieve is: - ease of deployment on 20-100 machines. That's why setting different params in some config file for each server, packaging the WAR and sending it to the server would be pain in the ... ;-) It's also a reason for choosing tomcat-deployed web-apps as processing units - it's very easy to deploy on multiple machines... - possibility of coexistence of different versions of processing software on one machine. It's up to master application what servers are going to be used at particular processing - ability to easily access particular processing unit, see it's statistics and logs, alter it's configuration etc. That's why using web-applications with some administration tools was chosen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
