Am 29.09.26 um 17:16 schrieb Christopher Schultz:
Amit,
On 9/25/26 1:08 PM, Amit Pande via users wrote:
If Tomcat could just host these applications separately, whoever
wanted to download/use, they could be free to do so.
The thought process is that some novice users want to be able to check
that their environment is working properly before doing anything else.
I'll have to say: I'm in favor of some way of removing the default apps
- maybe with a similar (but different) strategy as currently used for
the manager app: Manager is unusable until the system is configured with
credentials, so _something_ needs to be done to use it.
My suggestion is to continue to bundle the default apps, but in a
directory where they are not deployed by default - e.g. not in /webapps,
but in /sample-webapps - of course, without referencing this directory
anywhere. It'll be self-descriptive, allow copying them over to /webapps
to activate them if desired.
IMHO this should be including the manager app, although not updating it
in place might put some burden on existing deployments, so _this_ app
has some reason to stay in /webapps at least _for the current releases_.
For all others, there are almost no use cases to host ROOT or docs or
examples by default on any server where Tomcat is deployed.
This comes at a time when I have just discovered that ArchLinux updates
the complete package, installing all default webapps with an update
(unless explicitly instructed not to update the webapps directory -
which I've done _now_, after being bitten by this), thus overwriting
existing ROOT contexts. This demonstrates what can happen when
applications are bundled that are not really meant for widespread
hosting. I can't blame the ArchLinux maintainers for updating a full
package that they might not have intimate knowledge about, but imagine
I'd update my Apache httpd, only for my website to say "Hello World"
because the webserver's update came with an update to its default
content...
Not bundling default content in active form will support package
maintainers to do the right thing.
Of course, there's the point of updating potentially broken examples in
existing installations. From this point of view, even the examples app
might benefit from staying where it is in the current releases, but
lately when work on Tomcat 12 is started, this should be re-evaluated.
The ROOT app is the most notorious, with the biggest chance of being
custom on any Tomcat installation, and the good news is that it contains
no (breakable) code.
Not centrally updating at least the ROOT app seems to be a sensible,
no-risk operation even mid-stream though. But even if decided against:
Consider removing them all from /webapps starting with the next release
whenever work on it is being started.
Olaf
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
