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
