hmm, that's how I thought it worked, the filename would only be used if
the "path" attribute was not present inside the XML file.
Filip
Yoav Shapira wrote:
Hi,
I know we've talked about this before and resolved Bugzilla items
related to this, but I'd like to be reminded, please. Why does the
following code exist as such?
In org.apache.catalina.startup.HostConfig
(http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/startup/HostConfig.java?view=annotate),
deployDescriptors method (line 527), the following code:
File contextXml = new File(configBase, files[i]);
if (files[i].toLowerCase().endsWith(".xml")) {
// Calculate the context path and make sure it is unique
String nameTmp = files[i].substring(0, files[i].length() - 4);
String contextPath = "/" + nameTmp.replace('#', '/');
if (nameTmp.equals("ROOT")) {
contextPath = "";
}
if (isServiced(contextPath))
continue;
...
This code results in the (correctly documented at
http://tomcat.apache.org/tomcat-5.5-doc/config/context.html, but
annoying) behavior that users deploying web applications from
conf/Catalina/localhost/appname.xml context files can't set a path for
their context. Instead, the path is taken right from the file name,
which is less flexible.
Why don't we use the path from the contextXml file and use it? The
isServiced check will remain unmodified, enforcing unique paths per
virtual Host. We can also keep / use the current path determination
code if the user doesn't specify a path explicitly.
Thanks,
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
