WAR deployment fails when jar: URL is passed to "war=" or "config=" argument of /manager/deploy service. It seems code supporting jar: URL is currently gone from ManagerServlet.java (it was there with Tomcat 4), so I added support for it once again. In addition to jar: URL, this patch adds support for any URL, so you can deploy remote WAR file located on FTP or HTTP server (or anything java.net.URL supports).
Created attachment 13564 [details] Patch to regain support for various URL formats for "war=" or "config=" parameter of /manager/deploy service
Thanks for the patch, but this has very little use. As a result, I'm -0 for adding complexity to support this. Please consider using uploading your war to the server, which does the same but is far simpler.
*** Bug 32505 has been marked as a duplicate of this bug. ***
I understand the concern on complexity, so I won't push this patch to be included. However, code might be _simpler_ if URL-style string get handled by URL class instead of doing internal String cut-and-pasting as it is now (mine was bit complex as it tried to handle extraction of jar: URL). Allowing generic use of URL instead of just local file is powerful concept (meaning more flexible deployment style, giving more power to users), and should be included if complexity concern is resolved... # For example, you can do JNLP-like one-click webapp deployment # if generic URL is supported. Though its value on serverside is # arguable.
I don't understand how this is different from using the deploy task, and telling it to upload your war (since it does the same: the webapp is transferred to the server = no benefit). The only difference is that it was pulled (so you need a server of some sort) rather than pushed (the Ant task does the pushing for you). If the WAR is local to the server, then the deploy form you're using allows to not transfer the webapp, which has a benefit (and is why I left it; otherwise, it would be gone too).
(In reply to comment #5) > I don't understand how this is different from using the deploy task, and telling > it to upload your war (since it does the same: the webapp is transferred to the > server = no benefit). The only difference is that it was pulled (so you need a > server of some sort) rather than pushed (the Ant task does the pushing for you). > > If the WAR is local to the server, then the deploy form you're using allows to > not transfer the webapp, which has a benefit (and is why I left it; otherwise, > it would be gone too). The big difference is that the WAR file is already there. While you are uploading the WAR file, the application must not be there (undeployed) and this is very significant in time-critical applications. We currently are building a "updater" web application, that receives (via uploading) the building blocks of a webapp, then builds the WAR, finally sends the WAR file path to the caller that, after that, calls /deploy using this path. This way, the time that the webapp is down is limited to the operation of unpacking the war and the "real" deployment, thus eliminating the time needed for upload. Another thing. If you don't want to add complexity to implement this feature, why you still report in the documentation? Best regards Antonio Petrelli
Feel free to implement any custom scenarios that are needed for your production needs. That is the whole point of OSS. However, please do not reopen this report.
First of all sorry for reopening, will never do it again :-P . Anyway, you did not address the problem. If there are docs about the feature, that feature should exist, don't you agree? We are not allowed to distribute "our" version of Tomcat, they are running some other application and we cannot mix app "our" version with the "official" one. You asked what are the differences between uploading and deploying directly on the server and I showed it. Still a question: why Tomcat 4.1.31 implements this feature smoothly? (In reply to comment #7) > Feel free to implement any custom scenarios that are needed for your production > needs. That is the whole point of OSS. However, please do not reopen this report.
(In reply to comment #8) > We are not allowed to distribute "our" version of Tomcat, they are running some > other application and we cannot mix app "our" version with the "official" one. > You asked what are the differences between uploading and deploying directly on > the server and I showed it. If you are using Tomcat as you would of a closed source commercial offering, then you are limited to what you could do with a commercial offering (aka, if you want a particular feature, you're in trouble if it's not available). It's your decision, so you have to live with the consequences. I don't see what's bad with tweaking something like the manager servlet.
(In reply to comment #9) > > If you are using Tomcat as you would of a closed source commercial offering, > then you are limited to what you could do with a commercial offering (aka, if > you want a particular feature, you're in trouble if it's not available). It's > your decision, so you have to live with the consequences. I don't see what's bad > with tweaking something like the manager servlet. Errr... yes it's nothing bad but I felt confused when I saw this bug, whoops missing feature, after reading the documentation. At least for coherence remove the docs! Anyway, I modified my code with different calls for Tomcat 4.1 and 5.5. It seems that calling /deploy passing the complete path in the "war" parameter, that file is deployed, though this feature is undocumented. Maybe it's the documentation that needs a fix ;-)