Tomcat Web Application Thing
Tomcat Web Application Thing deploys and operates one approved Java WAR at a named local URL. It is the delivery unit for a site-specific wizard, portal, operational handoff, or utility that must stay close to the Banalytics Agent and the infrastructure it serves.
Deploy an application for a real operating moment
Use one Web Application Thing when a browser workflow belongs to one local site and should have an explicit lifecycle beside its Agent. The application can be modest: a guided commissioning page, a status screen designed for one team, a small event-receiving service, or a diagnostic tool. What matters is that its owner can explain why it exists, who uses it, and what happens when it is unavailable.
The component deploys the application; it does not create a business process by itself. A custom WAR must define its user experience, authentication, data handling, and controlled use of any Agent integration.
Commissioning wizard
Guide an authorised technician through setup of a machine cell, pump room, monitoring point, or energy asset, with screens designed for that infrastructure object.
Local operational portal
Give a warehouse, factory area, branch, clinic, building, or field site an interface focused on the local Agent's selected status, evidence, and routine work.
Event handoff service
Receive selected real-time website or local-service events and deliver them to facilities, maintenance, security, reception, or customer service.
Agent interface service
Implement a focused REST, SOAP, or other service contract, then map authorised requests to selected Agent components. External systems receive a stable business interface rather than direct access to the Agent.
Distributed business site
Deploy one approved WAR to multiple branches or facilities while each instance is pointed at its own Agent and context path. The corporate system of record remains separate; the local application owns only its defined edge interaction.
Small-business workflow
A workshop, shop, office, farm, or service company can use a compact local page for immediate alerts, task acknowledgement, equipment handover, or an approved checklist.
Private and maker utility
A managed home or homelab can host a trusted local utility for diagnostics, device setup, or a focused status page while keeping it inside the local network.
One WAR, one managed context
On start, the Thing validates the selected WAR, calculates its SHA-256, expands it into a generated directory inside the selected Tomcat Integration Thing workspace, and deploys it at the configured context path. The source archive remains in its chosen location so a release process can replace it without Tomcat locking the file.
Each application has a separate Thing lifecycle, deployment state, health policy, variables, access-log view, and remote operations. A failed deployment affects that application rather than stopping the container or its other applications.
Release artifact
The selected WAR is a versioned deployable artifact. Its SHA-256 identifies the exact archive currently expanded.
Stable local URL
Use /portal, /commissioning, or another unique path. Use / only when the application owns the container root.
Managed recovery
An optional health endpoint verifies that the application responds after deploy and during normal operation.
Deploy a predictable site application
Start the container first
Select a running Tomcat Integration Thing with a deliberate bind address, connector, workspace, and transport-security policy.
Select the release WAR
Choose a readable local .war file with normal WEB-INF content. Keep the release source outside the Tomcat workspace.
Reserve a context path
Choose one stable path. Every path is unique within its container; a root context can be used by only one application.
Define a lightweight health endpoint
Use a fast endpoint such as /health that proves the application can answer without a costly report, an external dependency, or a browser session.
Plan update and rollback
Keep the previous approved WAR available. Replace a release atomically, then redeploy deliberately or enable SHA-256 detection where the deployment process is controlled.
Keep site settings and health explicit
Application variables let an operator supply site-specific values without creating a different WAR for every deployment. Each variable becomes a servlet context init-parameter, so the application reads it with ServletContext.getInitParameter(name). A secret variable should use a Secret Manager reference such as ${secret:alias}; the resolved value is not returned by the application-variable API.
Changing an application variable requires redeployment. Reload restarts the existing context but retains the parameter map created for its original deployment. Use Redeploy after changing variables or replacing the WAR.
0, it checks the WAR every 60 seconds without recurring HTTP health requests.Package for the runtime and treat the WAR as trusted code
The module runs Tomcat 9.0.120 with Servlet 4.0 and the javax.servlet namespace. Package application dependencies inside the WAR. Tomcat 10+ or jakarta.servlet-only applications are not compatible.
For an interface service, keep the public contract deliberately narrow: validate and authorise every request, map it only to the intended Agent operations, and return contract-level responses. Do not turn the WAR into a transparent proxy for the Agent or expose its internal API wholesale.
The Jasper runtime supports precompiled JSP pages, but the JSP compiler is intentionally not included. Precompile JSP/JSPX with JspC during the build, or provide the required compiler/runtime inside the WAR.
BoxEngine as a servlet-context attribute. It needs an owner, source review, release procedure, and appropriate browser security controls.Configuration parameters
| Parameter | Required | Description | Default |
|---|---|---|---|
Title | Yes | Display name for the deployed application. | Empty |
Tomcat container | Yes | Active Tomcat Integration Thing that hosts this application. | None |
WAR file | Yes | Selected local .war release archive. | None |
Context path | Yes | URL path for the application. It is normalised to start with /; use / for the root context. | Empty |
Health URL | Optional | Path relative to the context, for example /health. Leave empty when deployed-context state is sufficient. | Empty |
Health timeout | Conditional | Connection and read timeout; range 100-120000 ms. | 5000 ms |
Health check interval | Conditional | Recurring health-check interval; range 0-3600 sec. Zero only probes after deployment unless WAR change detection is enabled. | 0 sec |
Failures before restart | Conditional | Consecutive failed recurring checks before application error handling; range 1-100. | 3 |
Redeploy when WAR changes | Yes | Compares source and deployed SHA-256 values on the health schedule and redeploys when they differ. | Disabled |
Use the application panel for safe service work
Deployment status
Read lifecycle state, deployment state, context, URL, WAR hash, health, and last error.
Controlled changes
Reload when the existing deployment needs a restart. Redeploy to apply a new archive or changed application variables.
Request diagnostics
Read recent access-log entries for this context and run a health check directly from the application UI.
Lifecycle changes are published as TomcatWebApplicationDeploymentEvent with deployment state, context path, hosting container, WAR hash, and sanitised error text.