Bug 32418

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 ;-)