Find the Best Cosmetic Hospitals

Explore trusted cosmetic hospitals and make a confident choice for your transformation.

“Invest in yourself — your confidence is always worth it.”

Explore Cosmetic Hospitals

Start your journey today — compare options in one place.

Embedded Jetty for Mission-Critical Production: Deployment Model, Trade-offs, and Operations

Embedding Jetty means shipping your Java application and its web container together as a single runnable unit. For DevOps teams operating critical services, this model can reduce environment drift, simplify rollback, and keep test and production behavior closer together.

This guide explains the production pattern described in the original post, where it helps most, and what you must explicitly design for monitoring, security, load balancing, and operational consistency.

Originally published on 2010-03-09; fully revised and updated.

How to use Jetty in production

What embedded Jetty changes in production

In a traditional Java setup, multiple applications are deployed into a shared application server. In an embedded model, each application carries its own server runtime (Jetty libraries) and starts from its own main method. Practically, this shifts control from platform-level deployment to application-level deployment.

The original seminar example used this model to avoid server-level dependency constraints and to make deployment as simple as replacing one JAR with another.

Deployment model: one artifact, minimal host prerequisites

The original post demonstrates packaging and shipping a standalone artifact (example project: embedded-container sample application) and requiring only a JVM on the target host.

mvn clean install
scp server/target/app-1.0.onejar.jar appuser@appserver:/home/appuser/test-env1/
ssh appuser@appserver "cd /home/appuser/test-env1/ && java -jar app-1.0.onejar.jar &"Code language: JavaScript (javascript)

This enables straightforward rollback (replace artifact with a previous one) and easy horizontal scaling (run multiple instances with separate ports and process supervision).

Why teams adopt this pattern

  • Runtime independence: each service can evolve JVM and library choices without coordinating every change across a shared server platform.
  • Dependency control: application dependencies are bundled and versioned with the service, reducing classpath surprises from server-provided libraries.
  • Simpler release mechanics: deployment and rollback are artifact operations rather than app-server console operations.
  • CI/CD friendliness: immutable artifacts map cleanly to pull- or push-based deployment workflows.
  • Test and production parity: you can start Jetty inside tests (example from the original post: JUnit-based Jetty startup), reducing server-behavior differences between environments.
  • Operational clarity: operations teams can work with standard process controls (start, stop, status, logs) per service.

Operational capabilities you must explicitly own

When you stop relying on a full external app server, you gain control but also inherit explicit responsibilities.

Monitoring and health checks

At minimum, write logs to a known location and expose a health endpoint that checks application-critical dependencies (database, downstream services, file shares, queues).

curl -fsS http://127.0.0.1:8080/healthCode language: JavaScript (javascript)

Load balancing and session behavior

Embedded Jetty does not automatically provide cluster routing behavior. Handle load balancing at reverse proxy, ingress, or network tiers, and decide whether you need sticky sessions. The original post points to Jetty-related proxy/session guidance here: Configuring mod_proxy.

Security boundaries

The source notes JAAS support and SSO patterns where identity is forwarded via HTTP headers. In production, this only works safely when those headers are injected by a trusted upstream component and spoofed headers are stripped at the edge.

Consistency across services

Standardize service layout and operations: startup commands, log paths, config conventions, health URLs, and runbooks. This keeps multi-service operations manageable even when each app owns its runtime.

Deployment and runtime workflow

flowchart TD
    A[Build with Maven] --> B[Create runnable artifact]
    B --> C[Publish artifact]
    C --> D[Copy or pull to target host]
    D --> E[Start java jar process]
    E --> F[Serve traffic behind proxy]
    E --> G[Expose health endpoint]
    G --> H[Monitoring checks]
    E --> I[Write logs]
    I --> J[Central log collection]
    H --> K{Healthy}
    K -- no --> L[Restart or rollback]
    K -- yes --> M[Continue serving]

Minimal embedded Jetty bootstrap example

A small bootstrap class illustrates the model: the application constructs and starts Jetty directly.

public class App {
    public static void main(String[] args) throws Exception {
        int port = Integer.parseInt(System.getProperty("server.port", "8080"));

        Server server = new Server(port);
        ServletContextHandler context = new ServletContextHandler(ServletContextHandler.SESSIONS);
        context.setContextPath("/");
        context.addServlet(HealthServlet.class, "/health");
        context.addServlet(AppServlet.class, "/*");

        server.setHandler(context);
        server.start();
        server.join();
    }
}Code language: JavaScript (javascript)

Externalize runtime settings rather than hardcoding them:

server.port=8080
app.environment=production
log.dir=/var/log/myapp
health.check.dependencies=trueCode language: JavaScript (javascript)

Embedded Jetty vs shared application server

OptionStrengthsTrade-offsBest for
Embedded Jetty per applicationStrong app isolation, consistent packaging, easy rollback, simpler per-service CI/CDYou must implement operational standards yourself (health, supervision, conventions)Service-oriented teams that want independent release velocity
Shared external application serverCentralized platform controls and shared operational modelCross-app dependency coupling, slower coordinated upgrades, potential classpath conflictsEnvironments with strict centralized middleware governance

Best practices for mission-critical use

  • Treat the deployable artifact as immutable and versioned.
  • Use process supervision (systemd, container orchestrator, or equivalent) rather than ad-hoc background processes.
  • Make health checks dependency-aware, not just process-aware.
  • Keep config external and environment-specific.
  • Define a standard service contract: ports, logs, metrics, startup, shutdown, and alerting behavior.
  • Validate authentication header trust boundaries at the reverse proxy layer.

Historical reference from the original post: http://www.javaworld.com/community/?q=node/4133

Find Trusted Cardiac Hospitals

Compare heart hospitals by city and services — all in one place.

Explore Hospitals
I'm Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms. I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.

Related Posts

Team Foundation Server 2015 Installation Guide (SQL Express + Update 3)

Install Team Foundation Server 2015 using the original Microsoft download paths, with clear guidance for online, offline, and ISO-based setup. This revised guide also includes an installation workflow, command example, and practical pitfalls to avoid.

Read More

How to Access a Running Docker Container Shell: docker exec vs docker attach

Need a shell inside a running container that is already in detached mode? This updated guide shows the correct workflow, compares docker exec and docker attach, and explains when SSH does and does not make sense.

Read More

Host Your Own NuGet Feed: Local Source vs NuGet.Server vs NuGetGallery

Learn how to host a private NuGet feed using three practical approaches: a local folder source, NuGet.Server, and NuGetGallery. This revised guide includes setup steps, command examples, and a workflow diagram to help you choose the right model.

Read More

Publish NuGet Packages to NuGet.org: CLI Steps, Workflow, and CI Example

Learn how to publish a NuGet package to NuGet.org using either nuget.exe or the dotnet CLI. This revised guide includes a workflow diagram, command comparison, and a CI-friendly example.

Read More

How to Create NuGet Packages with nuget.exe (Assembly, .nuspec, and .csproj Methods)

Learn three practical ways to build NuGet packages using nuget.exe: from an existing assembly, from a convention-based folder layout, or directly from a Visual Studio project. This guide includes commands, folder conventions, token behavior, and common pitfalls.

Read More

Virtualization in DevOps: Using Vagrant, Docker, and Cloud Platforms Together

This guide explains how VM-based workflows, containers, and cloud platforms complement each other in DevOps. It includes a practical workflow, trade-off table, and command examples for day-to-day use.

Read More
Subscribe
Notify of
guest
0 Comments
Newest
Oldest Most Voted
0
Would love your thoughts, please comment.x
()
x