https://issues.apache.org/bugzilla/show_bug.cgi?id=47467
--- Comment #7 from Uwe Günther <u...@cscc.de> 2009-09-27 03:44:40 PDT --- Thanks for your input but this leads me to some further questions to discuss :-) The 'path' parameter describes the context path of the web application. By providing a 'path' and a 'war' parameter you can tell the ManagerServlet for example ?path=/myWebapp&war=C:\\myWar.war. This adds the value to not having a hard wired relationship between the context name (aka '&path=/myWebapp') and the deployment source (webapp as *.war file or as an webapp conform directory structure aka '&war=C:\\myWar.war' or '&war=C:\\myDir') Further more there is the case where you can provide a context.xml as config, but you have to know to which webapp this config belongs to. A case would be ?path=/myWebapp&config=C:\\context.xml In this case the context.xml would be end up in ${catalina.base}/conf/[Engine]/[Host]/myWebapp.xml Basically you can say the '&path=' is used to get the Context (aka webapp) from the mBeanServer. If the '&path=' gets dropped you would need it inside the deploy(.....) method anyway but with the limitation the '&path=' would be always hardwired to the name of the '&war=' value (war or dir name) or the '&config=' value (config name Ok this derivation of the '&path=' from '&war=' is done at the moment anyway if no '&path=' is provided, but you still have the possibility to override that, say you want to deploy the same war as 5 different webapps for testing purposes for example. It works like this at the moment in the patch: if (!hasPath && !hasConfig && hasWar) { //war this.war = new War(war); this.path = this.war.getPath(); this.config = null; } else if (!hasPath && hasConfig && hasWar) { //war, config this.war = new War(war); this.path = this.war.getPath(); this.config = new Config(config); } else if (hasPath && !hasConfig && hasWar) { //war, path this.war = new War(war); this.path = new Path(path); this.config = null; } else if (hasPath && hasConfig && !hasWar) { //config, path this.war = null; this.path = new Path(path); this.config = new Config(config); } else if (hasPath && hasConfig && hasWar) { //war, config, path this.war = new War(war); this.path = new Path(path); this.config = new Config(config); } else { //!hasPath && !hasConfig && !hasWar //!hasPath && hasConfig && !hasWar // hasPath && !hasConfig && !hasWar throw new IllegalArgumentException( "Need one of the following combinations" + ": war " + "| war, path " + "| war, config " + "| war, config, path " + "| config, path"); } We could think about to derive the '&path=' (aka webapp context) from the '&config=' (config name) for the following case: //!hasPath && hasConfig && !hasWar for example: ?config=C:\myWebapp.xml would be end up in: ${catalina.base}/conf/[Engine]/[Host]/myWebapp.xml Thats what you suggested as well in comment #6 case 2. BTW: In the pre JMX version of ManagerServlet (all pre Tomcat 5.5.0 versions) we had o.a.c.Deployer to encapsulate all the deployment related tasks. Starting with Tomcat 5.5.0 all these tasks got moved as 'JMX Agent Level like' access methods into the Manager Servlet which is a bit ugly from an OO point of view. Instead of that solution we should think about having a 'JMX Agent Level like' Deployer object in the 'manager' webapp to provide encapsulated services for the tasks to perform an deploy, undeploy, ... from within the ManagerServlet. But thats possibly beautifying and should go with an different Bug. -- Kind Regards Uwe Günther -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org