apache-tomcat-9

Overview

Apache Tomcat is a servlet container and web application server for Jakarta-based Java web applications. The upstream project describes Tomcat 9 as an implementation of the Servlet 4.0 and JavaServer Pages 2.3 specifications, with additional functionality used to develop and deploy web applications and web services. (github.com)

In a Linux distribution, this package exists to provide a maintained, packaged Tomcat 9 runtime that can be installed, updated, configured, and integrated through the distribution's packaging workflow instead of being managed only as a manual upstream installation. That role is typical for administrators and CI/CD maintainers who need a repeatable server-side Java web platform, and for developers who need a local or shared servlet container for application deployment and testing. The exact deployment model used by a given site should be verified by the NiceOS maintainer. (github.com)

Purpose and typical use cases

Typical uses of Tomcat 9 include:

• hosting Java web applications that target the Servlet and JSP APIs;
• running application deployments in development, staging, or production environments;
• providing a servlet container for integration tests or build pipelines;
• serving as the managed runtime for web applications that are packaged for Tomcat rather than for a full application server.

Tomcat documentation is written for administrators and web developers, which matches the usual audience for this package. Security engineers and platform owners may also review the package when they need to align configuration, upgrade planning, or hardening work with the upstream documentation. (tomcat.apache.org)

Upstream project

The upstream project is Apache Tomcat, hosted by the Apache Software Foundation. Its public repository and documentation describe the project, its build layout, installation notes, and version-specific manuals. The main upstream repository also contains the project README, BUILDING.txt, RUNNING.txt, and versioned documentation bundles. (github.com)

Maintainers should verify any Tomcat 9-specific packaging assumptions against the upstream Tomcat 9 documentation rather than against documentation for other major Tomcat lines. (tomcat.apache.org)

Dist-git repository contents

This dist-git repository normally contains only the packaging sources needed to build the RPM in NiceOS:

• SPECS/ for the RPM spec file and related packaging logic;
• SOURCES/ for source metadata and manifest files used to track upstream inputs;
• METADATA/ for repository metadata used by the packaging workflow;
• SBOM/ for software bill of materials data, when maintained for this package.

The repository does not store the large upstream source archives themselves. Those files are intentionally kept out of Git, and source integrity is tracked through the manifest files in SOURCES/. Maintainers should treat those manifests as the place to verify what upstream source material the package expects, while keeping in mind that the actual archive contents are fetched or staged through the normal packaging process. The exact manifest format and regeneration steps should be verified in the repository layout used by NiceOS. (github.com)

Source storage and integrity policy

NiceOS uses manifest-based source tracking in SOURCES/ instead of committing large upstream archives to Git. This keeps the repository small and makes it easier to review packaging changes without mixing them with bulky binary source payloads.

Before updating the package, maintainers should check:

• that the upstream source set still matches the packaging intent recorded in SOURCES/;
• whether any manifest files need regeneration after changing the upstream source reference;
• whether the spec file needs a refresh for patches, file lists, scriptlets, service units, documentation paths, or install-time paths;
• whether SBOM data, if present, should be regenerated to match the new source set;
• whether any downstream configuration or systemd integration assumptions still hold after the upstream update.

If any of those points are unclear, NiceOS maintainers should verify them before relying on the package update. (github.com)

NiceOS maintenance notes

When preparing an update, check the following:

• review upstream release notes and documentation changes that may affect packaging or runtime behavior;
• verify whether the Tomcat packaging still matches the intended JDK, directory layout, startup method, and default configuration approach used in NiceOS;
• confirm whether any local patches can be dropped, rebased, or need adjustment;
• check whether bundled docs, examples, or auxiliary files changed and whether the spec file should install, exclude, or relocate them;
• inspect config file handling so that local edits are preserved as intended across upgrades;
• review permission, ownership, and service management changes if the package ships systemd units or scripts;
• consider whether upgrade-path risks exist for deployed applications, especially if configuration defaults, directory names, or supported deployment assumptions changed upstream.

Tomcat's own documentation includes setup, configuration, security, and architecture material that is useful for this review. The precise packaging details still need to be validated in the spec file and repository metadata. (tomcat.apache.org)

Build and verification checklist

For RPM maintainers, a practical check list is:

• confirm that the source manifest in SOURCES/ matches the intended upstream inputs;
• build the SRPM and RPMs from the current spec file;
• review the build log for missing files, unexpected path changes, or failed filters;
• verify that installed files land in the expected directories and that no unintentional payload was added;
• check that configuration files are handled as config files where appropriate;
• verify that services, scripts, or wrapper tools still start and stop correctly if they are shipped by the package;
• run any package tests that exist in the repository or in the upstream source tree;
• compare installed documentation and example files against packaging policy;
• regenerate SBOM or other metadata if the package workflow requires it;
• test a representative upgrade path if the package carries stateful configuration or service data.

If a build or verification step depends on local packaging conventions, the NiceOS maintainer should confirm those conventions in the distribution packaging guidelines. (tomcat.apache.org)

References

• Apache Tomcat repository
• Apache Tomcat 9 documentation index
• Apache Tomcat 9 introduction
• Apache Tomcat 9 setup
• Apache Tomcat 9 security considerations
• Apache Tomcat 9 architecture

Russian documentation

See README_RU.md for the Russian version of this documentation.

Dist-git repository notes

• Package repository: rpms/apache-tomcat-9
• NiceOS branch: niceos-5.2
• This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.