TAFC to TAFJ

TAFJ Deployment Explained — WAR Files, Cache, and Verification

A successful deployment log proves only one stage. Verify the artefact, activation, runtime instance, cache path, and changed behaviour before declaring the release complete.

By T24Guru Editorial·
MigrationProduction support

Browse more Migration articles →

The deployment lifecycle

  1. Source change: routine, version, enquiry, Java, JavaScript, CSS, or configuration changes.
  2. Build: compile or generate the required artefacts using the approved pipeline. Review JBC versus Design Studio and the TAFJ compilation pipeline.
  3. Package: assemble the expected JAR, EAR, WAR, or related deployable content.
  4. Deploy: transfer and register the package with the intended application-server instance.
  5. Activate: load the new classes, resources, context, and configuration.
  6. Serve: pass the response through application, proxy, and browser cache layers.
  7. Verify: prove the new version and expected behaviour independently.

Why a green deployment log is not enough

A deploy command can succeed while the wrong artefact, wrong server, old application context, or stale cache remains user-visible. The release check must therefore extend beyond file transfer and application registration.

  • Confirm the package checksum or version identifier matches the approved build.
  • Confirm the target host, server group, profile, port, and application context.
  • Check activation timestamps and the first startup error after deployment.
  • Test the changed behaviour through the same route users follow.

Cache layers that can preserve old behaviour

Browser cache

Static resources can remain cached according to response headers. Compare resource URLs, response headers, content hashes, and computed output rather than relying only on an incognito window or repeated refreshes.

Reverse proxy or web tier

A proxy, load balancer, web server, or CDN may serve cached content or route the request to another application instance. Identify the responding node and verify cache policy.

Application-server and TAFJ runtime cache

Classes, generated components, metadata, routines, and application contexts may require a documented reload, redeploy, or restart. Use the local deployment procedure; do not clear runtime state indiscriminately.

A verification-first sequence

  1. Record the expected commit, build number, package name, size, and checksum.
  2. Verify the package on the target host before deployment.
  3. Capture deployment and activation timestamps plus the first relevant log events.
  4. Confirm which application instance answered the verification request.
  5. Check the deployed class or static-resource version directly where supported.
  6. Run a narrow functional smoke test of the changed behaviour.
  7. Compare the result from a direct application route and the normal user route when possible.
  8. Record rollback criteria and business sign-off.

For log evidence, see TAFJ log file locations. For database-side deployment tooling, see TAFJ DBTools.

Common stale-version causes

  • The package was built from the wrong branch or an older compiled artefact.
  • The package was copied to a different instance from the one serving traffic.
  • The deployment registered but the application context failed during activation.
  • A load balancer continued routing to an unchanged node.
  • A static-resource URL did not change and remained cached.
  • A routine or generated component was not compiled or integrated into the package.
  • Environment-specific configuration replaced or masked the intended change.

Rollback preparation

Preserve the previous deployable artefact, configuration, checksum, and activation procedure. Confirm database compatibility, session impact, cache handling, and whether rollback itself requires a service interruption. A rollback is complete only when the previous version is active and its expected behaviour has been verified.

Internal-link check

The supporting routes used by this guide are canonical article routes: JBC vs Design Studio, TAFJ compilation, TAFJ log locations, and TAFJ DBTools.

Related reading

TAFC to TAFJ

TAFJ Compilation: Why Your Changes Aren't Doing Anything

In TAFJ, editing source code changes nothing until you compile, package, and deploy. The full pipeline: tCompile, tIntegrate, tComponentSplitter, tMerge — and what each one does.

TAFC to TAFJ

TAFJ DBTools: The SELECT Replacement Nobody Tells You About

In TAFC you ran a SELECT in the command line. In TAFJ that is gone. The replacement is DBTools — a separate console with its own users, its own modes, and a 200-row default limit nobody mentions.

TAFJ operations

TAFJ Log Files: Where to Look When Something Goes Wrong

TAFJ distributes its logs across six different locations maintained by different parts of the stack. Where each one lives, what it covers, and the order to check them in — before an incident makes the question urgent.