https://issues.apache.org/bugzilla/show_bug.cgi?id=47467
--- Comment #5 from Uwe Günther <u...@cscc.de> 2009-09-26 04:50:58 PDT ---
After some archaeological researches in older tomcat releases it came to
daylight the general URL support has been gone starting with Tomcat 5.5.0. In
this release o.a.c.Deployer has been removed from the Tomcat core. The Deployer
interface has been used inside the ManagerServlet to drive the deployments.
Deployer was a specialized Container into which web applications could be
deployed and undeployed. The whole Deployer interface could only used together
with java.net.URL. This was the main reason, why the enduser of the HTMLManager
application had to deal with URL like syntaxtes like "file://yourFileOrDir" or
"jar:file://yourWarFile.war!/"
Starting with Tomcat 5.5.0 o.a.c.Deployer interface got dropped from Tomcat and
the ManagerServlet got migrated to do the deployment with the JMX mBeanServer
from now on. If you look in the code starting from 5.5.0 the
ManagerServlet.deploy(.....) got worse and worse and less and less maintainable
because the migration hasn't done properly. For example:
* Javadoc hasn't been migrated
* URL support has been dropped (only a 'file:' prefix is supported from now
on which isn't really need but this is a different topic) which was a good
thing because the user from now on can use plain OS File paths like you would
expect from an enduser point of view from the very beginning.
* deployment of local war without context path has been dropped
* deployment of local dir without context path has been dropped
There should be short term and a long term solution.
Short term solution should be
1.) to apply the fix I already did for this bug mentioned in my comment
above,
2.) remove a the pseudo URLs like 'file:' we already have in the code and
provide the user a consistent interface for native file- and path-names. This
will effect the Ant DeployTask as well.
3.) The 'jar:file:' and 'file:' syntax needs to be removed/changed in the
related javadocs and howtos.
Long term solution would be to create a new bug to go over the whole manager
application and bring it back in to an consistant and maintainable state. I
will create that bug as soon this one went into svn.
--
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
