DEV Community: Manoj Sharma

The Engineering Guardrails We Need After AI Started Writing the Code

Manoj Sharma — Fri, 03 Apr 2026 18:34:52 +0000

Today, AI removes the typing cost. You ship faster, tests are green, code reviews pass. But it also removes the natural pauses where as an engineer you normally think through the hard parts — and this is where you should not be on autopilot:

retries
idempotency 👑
network timeouts
concurrency
rich suite of tests
observability

The result is: Reasoning Debt — and it keeps increasing.

The code works. But nobody can explain why it was written that way, and more importantly, nobody knows what it does when things go wrong.

Quietly similar to technical debt, but different:

Technical debt 👉 messy implementation
Reasoning debt 👉 unclear intent under failure

In production you need reasoning — and one day it breaks, and you find yourself in an endless debugging session with 2 or 3 more engineers trying to understand why you wrote what you wrote. This can silently kill your code reading and reasoning skills over time.

But we can set up a good set of engineering guardrails. And honestly, AI is getting more capable every day — we may see it handling these concerns by default in the near future. Until then, let's talk about a few things worth focusing.

Guardrail #1 — Fully Covered Tests Become Code Reasoning Documentation

AI can generate logic quickly, but intent is rarely obvious without tests. Consider this user eligibility logic:

public boolean eligible(User user) {
    return user.isActive()
        && user.getBalance() > 1000
        || user.isPremium();
}

Looks reasonable. But questions appear immediately:

Does isPremium() bypass the balance check entirely?
Does an inactive premium user get in?
Was operator precedence here intentional or accidental?

Without tests this becomes reasoning hell later. The fix isn't just adding parentheses — this is a business rule encoded as an expression, and the expression is ambiguous. Make sure you instruct AI to generate intent-covering tests, not just happy path ones.

Added tests turn this into a code manual:

@Test
@DisplayName("Premium users are eligible regardless of balance")
void premiumUserEligibleRegardlessOfBalance() {}

@Test
@DisplayName("Inactive users are never eligible, even if premium")
void inactiveUserNotEligible() {}

@Test
@DisplayName("Active non-premium users need sufficient balance")
void activeUserWithBalanceEligible() {}

Now the logic has to be unambiguous, because the tests force you to state every case explicitly. And when someone asks "what was this supposed to do?" — the tests answer that faster than any comment.

Guardrail #2 — AI Writes Happy Paths. Systems may fail Unexpectedly.

AI naturally writes linear success flows:

public void processOrder(String orderId) {
    payment.capture(orderId);
    inventory.reserve(orderId);
    shipping.create(orderId);
}

Completely correct... until retries happen. Higher environments sometimes introduce retries that catch you off guard — and if not handled, you may end up with significant drift that's not easy to rollback:

SQS retries
Kafka re-delivery
HTTP timeouts
Client retries after 502 or 409

Now imagine a failure mid-flow:

Attempt 1:
  payment.capture()   → SUCCESS ✅
  inventory.reserve() → SUCCESS ✅
  shipping.create()   → TIMEOUT ❌

Queue retries the message.

Attempt 2:
  payment.capture()   → CAPTURED AGAIN 💸
  inventory.reserve() → RESERVED AGAIN 📦
  shipping.create()   → SUCCESS ✅

Now you have:

double charge incidents
inventory drift
duplicate shipments
reconciliation nightmares

The missing idea is usually idempotency — not logic. You must protect the state, and this is something worth explicitly instructing AI to reason about. A simple attempt:

public void processOrder(String orderId) {
    if (orderStateRepository.isProcessed(orderId)) {
        log.info("Order {} already processed, skipping", orderId);
        return;
    }

    if (!payment.isAlreadyCaptured(orderId)) {
        payment.capture(orderId);
    }

    if (!inventory.isReserved(orderId)) {
        inventory.reserve(orderId);
    }

    if (!shipping.exists(orderId)) {
        shipping.create(orderId);
    }

    orderStateRepository.markProcessed(orderId);
}

Honestly, this is subjective — some engineers naturally think about it and instruct upfront, others don't. But it should always be on your brain map.

Guardrail #3 — Instruct AI to Test System Behaviour, Not Just Code Interaction

Without explicit instruction, AI tends to validate code interaction using mocks instead of actual system behaviour.

Problem 1 — Mocking Infrastructure Clients (e.g. OpenSearch)

@Test
void shouldIndexOrder() {
    OpenSearchClient client = mock(OpenSearchClient.class);
    SearchService service = new SearchService(client);

    service.index("order-123");

    verify(client).index(any());
}

Test proves: Client method was called.

Test does not prove:

index exists
mapping is correct
serialization works
AWS config works
search actually works

This is testing Java interactions, not search behaviour.

Problem 2 — Mocking DB Interaction (When You Have Liquibase)

class OrderRepositoryTest {

    @Mock
    OrderRepository repo;

    @Test
    void shouldSaveOrder() {
        repo.save(new Order("123"));
        assertTrue(repo.findById("123").isPresent());
    }
}

Looks fine. Hidden problems:

Liquibase never executed
schema never validated
constraints never validated
JSON columns may fail in production
migrations may fail at startup

Instruct AI to Write Real Integration Tests

Point AI toward Testcontainers — it knows about it, it just won't reach for it unless you ask:

@Testcontainers
@SpringBootTest
class OrderSystemIT {

    // spring.liquibase.change-log: classpath:db/changelog.xml
    @Container
    public static PostgreSQLContainer<?> postgres =
        new PostgreSQLContainer<>("postgres:15");

    @Container
    public static LocalStackContainer localstack =
        new LocalStackContainer(DockerImageName.parse("localstack/localstack"))
            .withEnv("SERVICES", "opensearch");

    @Autowired
    OrderService orderService;

    @Test
    void shouldCreateOrderAndSearch() {
        orderService.createOrder("order-123");

        List<Order> results = orderService.search("order-123");

        assertThat(results).hasSize(1);
    }
}

Now you're testing persist and search behaviour — not Java mocks.

Guardrail #4 — Instruct AI to Log With Context, Not Just Confirmation

AI generated logging looks completely reasonable on the surface:

public void processPayment(String orderId, BigDecimal amount) {
    log.info("Processing payment for order {}", orderId);
    Payment result = payment.process(orderId, amount);
    log.info("Payment processed for order {}", orderId);
}

When we Ship it to production, hit a failure, open our log aggregator. What we find:

Processing payment for order 123
Processing payment for order 234
Processing payment for order 345

No error. No context. No idea which order failed, what amount was involved, what the gateway returned, or whether a retry is safe.

Instruct AI to write structured logs with failure context from the start:

public void processPayment(String orderId, BigDecimal amount) {

    log.info("Payment processing started",
        kv("orderId", orderId),
        kv("amount", amount)
    );

    try {
        Payment result = payment.process(orderId, amount);

        log.info("Payment captured",
            kv("orderId", orderId),
            kv("transactionId", result.getTransactionId()),
            kv("duration", result.getDuration())
        );

    } catch (CustomException e) {
        log.error("Payment capture failed",
            kv("orderId", orderId),
            kv("errorCode", e.getErrorCode()),
            kv("retryable", e.isRetryable())
        );
        throw e;
    }
}

With structured logs, aggregator can answer "how many non-retryable payment failures in the last hour, by error code?".

Final Thoughts

None of these are new concepts. Idempotency, intent-driven tests, integration testing, structured observability — senior engineers have known these for years.
With AI, The speed is real. Just don't let it replace the thinking.
Write the guardrails into your prompts, your PR reviews, your definition of done. AI will follow — it just won't lead.

Be a Responsible Code Reviewer

Manoj Sharma — Sat, 22 Nov 2025 05:49:28 +0000

When you work with different teams long enough, you start noticing something meaningful:
Good code reviews don’t just improve the code—they strengthen teams, culture, and the way we write applications. Think about it...

That's where we actually teach each other new tricks / ways, share our best practices, and make sure we're all building something awesome, maintainable and reliable.

Let’s take a clear look... what a helpful, responsible code review really looks like. I am going to dig into the everyday's habits we fall into — the good ones and the ones that slow us down — and let's figure out better ways to handle them.

Why Strong Engineering Teams 💪 Treat Code Reviews Seriously?

Code reviews aren’t only about catching typos. They protect the applications’s correctness, design, and future maintainers.

Let’s analyze few of the reasons...

1. Catching Hidden Logic or Edge-Case Bugs

Sometimes the code looks fine, until someone else reads it carefully.

public double withdraw(double balance, double amount) {
    return balance - amount; // Looks fine, but...
}

A reviewer notices:

Allows balance to go negative
No validation
Silent failures

A thoughtful improvement:

public double withdraw(double balance, double amount) {
    if (amount <= 0) throw new IllegalArgumentException("Invalid withdrawal amount");
    if (amount > balance) throw new IllegalStateException("Insufficient funds");
    return balance - amount;
}

So this one small review prevented a production nightmare 😰

2. Improving Design and Readability

Developers often optimize for “it just works”.
Reviewers can help guide towards "it works and it makes sense here, they help reshape it before it becomes a problem later."

orderService.processOrder(order);

But inside this method, total chaos! 🤯

public void processOrder(Order order) {
    // 200 lines of logic...
    // validation, transformations, ext calls...
    // Hard to read, hard to test, and even harder to change later.
}

even if it Works today, but becomes a headache for anyone reading it tomorrow.

A reviewer suggests breaking responsibilities:

validateOrder(order)
applyDiscount(order)
reserveStock(order)
notifyUser(order)

Reviews improve the design instincts — something no tool can automate.

3. Spotting Performance & Concurrency Pitfalls

Performance issues often hide in plain sight:

Map<String, User> map = new HashMap<>();
synchronized (map) {
    // heavy operations
}

Reviewer says:

You’re locking the entire map. That means only one thread can use it at a time.
Use a ConcurrentHashMap so multiple threads can work without blocking each other unnecessarily.

Small insight, big impact...but stay polite 🙌

How CI Helps Developers Trust Their Code?

Modern CI should take care of the repetitive checks, freeing reviewers to focus on real logic and blunders.

CI Handles What Humans Need not to

Basic static analysis
Null Pointers
High Logical Complexity
Code coverage
Security scans

If your CI is configured well, Reviewers need not to comment:

“Indentation wrong.”
“Rename this variable.”
“Remove unused imports.”

Most importantly it will take care of highlighting Vulnerabilities or Security concerns found in your latest changes.

Building a Learning Culture Through Code Reviews

A team that genuinely invests in code reviews gets better over time — because reviews are opportunity to learn new patterns, better designs, and even by reading other people's review comments educate everyone that this is how mistakes can be avoided... not just approvals to merge.

1. Tech Review Sessions With the Team

A simple habit strong engineering teams use:

Pick a PR that has some interesting design decisions
Walk everyone through what was done and why?
Talk about other possible approaches and their trade-offs
Note down anything useful for future work

This changes code review process from a private chat to something the whole team can learn from.

2. Knowledge Sharing Example

Suppose a developer introduces following piece of code

List<Order> orders = repo.findAll();
return orders.stream()
             .filter(o -> o.getStatus() == Status.COMPLETED)
             .sorted(Comparator.comparing(Order::getDate))
             .toList();

And reviewer suggests:

List<Order> orders = repo.findByStatusOrderByDateAsc(Status.COMPLETED);

Simple discussion here:

teaches why filtering and sorting at the source is more efficient
helps teammates recognize performance issues hidden in “harmless” code Reviews become mini lessons wrapped inside real code.

3. Language Modernization Through Reviews

Developer writes:

Optional<User> user = findUser(name);
if (user.isPresent()) {
    Address address = user.get().getAddress();
    if (address != null) {
        return address.getCity();
    }
}
return "anywhere";

Reviewer suggests:

return findUser(name)
        .map(User::getAddress)
        .map(Address::getCity)
        .orElse("anywhere");

No lecture — just a small improvement that exposes them to modern Java style.
This is how teams grow naturally.

How to Be a Responsible Code Reviewer ⭐️

Short, powerful, and practical.
No philosophy — just actionable mindset...

1. Understand The Context Before The Code

Read First:

PR description
Linked JIRA ticket
Commit message

You can’t review well unless you understand why the change exists.

2. Ask Questions, Don’t Command

Bad:

“Use Streams here.”

Good:

“Any reason Streams weren’t used here? they might simplify this block.”

Questions create collaboration; Commands create tension.

3. Praise Good Code When You See It

We often only comment when something is wrong.
But acknowledging good work helps morale and encourages a positive environment.

try (var client = new HttpClient()) {
    return client.fetch(url);
}

Good comment:

“Nice use of try-with-resources — clean and safe.”

4. When You Reject Something, Reject the Code — Not the Dev

synchronized (this) {
    timeConsumingOperation();
}

A harsh comment:

“This is bad, Why would anyone write this?”

Responsible reviewer:

“This might block more threads than needed. Can we lock only the shared part?”

5. Be Fast. Be Respectful. Be Honest.

Common anti-patterns:

Reviews slipping because of competing priorities.
Reviewer approves without reading.
Comments that are too short to be actionable (“Fix this”, “Why?”)

Responsible reviewer mindset:

Review within a reasonable timeframe.
Give actionable comments.
Being honest while staying respectful

6. Review the Scope — Not the Galaxy

If a PR is about “Add Get Users API”, don’t comment on unrelated parts like variable names in other unrelated methods.

Focus on: Functional correctness || Edge cases || Complexity
Don’t expand scope unless it’s truly necessary.

7. Don’t Just Point Out Problems — Propose Alternatives

A bad review makes the author feel stuck.
A good review helps them move forward faster.

public boolean isValid(Status status) {
    return status == Status.ACTIVE || status == Status.PENDING;
}

Reviewer:

“Hardcoded checks”

Responsible reviewer:

These rules will grow. Let the enum own its behavior instead of scattering logic.

public enum Status {
    ACTIVE(true),
    PENDING(true),
    SUSPENDED(false);

    private final boolean valid;
    Status(boolean valid) { this.valid = valid; }
    public boolean isValid() { return valid; }
}

One identifies the issue, The other one provides the solution as well...and allows dev to express their thoughts at the same time.

Wrapping up

That'it...
Repeating myself, Good code review process don’t just create better applications, They create better teams.
I’d love to hear from you people - What parts of the code review process frustrated you, and what changes made things better for you and your team? Share your thoughts 💭.

Virtual Threads - Comparative Analysis

Manoj Sharma — Sun, 09 Nov 2025 16:10:24 +0000

If you’ve worked with Java ☕️ long enough, you probably remember when thread management felt less like coding and more like careful resource budgeting.

We had to size our thread pools just "right", because
Too small -> and requests would just pile up, and waiting forever.
Too large -> and memory vanished quickly. as each thread reserved a big chunk for itself. Even worse, your CPU would spend all its time just switching between threads instead of doing actually work.

And when I/O came into play — like, blocking on a database call or waiting for a network response — we either had to accept wasted threads or jump into async APIs, callbacks, and CompletableFuture chains.

We all made it work, of course. But it was a constant headache. We spent more time fighting with the concurrency model than we did building the actual feature.

Arrival of Virtual Threads 🚀

Virtual threads, became a stable feature in JDK 21.
They just quietly solved a problem we’d been carrying for years — how to make sequential blocking style code scale without rewriting everything.

Virtual Threads are not new thing anymore; But it’s still worth pausing to think about how they’ve changed the way we approach concurrency.

The goal is simple
Enable scalable concurrency without giving up the familiar, blocking programming model.

And the best part is?
They are still java.lang.Thread instances, but instead of being bound to OS threads, they are managed by the JVM.

How to Create?

Let’s see how virtual threads are created in Java, and how that differs from creating traditional platform threads

Platform Threads

// Platform thread
Thread t = new Thread(() -> {
    handleRequest();
});
t.start();

// Executor with fixed pool
ExecutorService pool = Executors.newFixedThreadPool(200);
pool.submit(() -> handleRequest());
pool.shutdown();

Virtual Threads (JDK 21+)

// Single virtual thread
Thread virtualThread = Thread.startVirtualThread(() -> {
    handleRequest();
});

// Executor that creates a virtual thread per task
try (ExecutorService virtualThreadExecutor = Executors.newVirtualThreadPerTaskExecutor()) {
    virtualThreadExecutor.submit(() -> handleRequest());
}

What’s Really Different Here?

→ Difference in Mechanics: Platform v/s Virtual

A Platform Thread in Java is a one-to-one wrapper around an operating system thread.
Each platform thread corresponds directly to an OS-managed thread, with scheduling, stack allocation, and blocking semantics handled by the operating system.

Because of that one-to-one relationship, creating large numbers of platform threads consumes significant native memory and kernel resources.

When a platform thread performs a blocking I/O call, the underlying OS thread thread sits idle until the operation completes. meaning that system-level thread cannot execute other tasks during that period. That’s why traditional applications rely on "right" fixed-size thread pools — to keep control over how many OS threads exist at once.

A Virtual Thread, changes only the implementation model — not the programming model.

A virtual thread is still an instance of java.lang.Thread, but instead of being tied to an OS thread, it is scheduled by the JVM and runs on top of a small, fixed set of carrier threads (which are regular platform threads).

When a virtual thread performs a blocking operation, the JVM parks that virtual thread and detaches it from its carrier, freeing the carrier to run another virtual thread.
When the blocking operation completes, the virtual thread is resumed — possibly on the same or a different carrier thread.
All of this happens transparently, without changing the semantics of the blocking APIs.

→ Scheduling Responsibility

The key distinction is who manages scheduling and blocking:

For platform threads, it’s the operating system scheduler.
For virtual threads, it’s the JVM runtime scheduler, implemented entirely in user space.

Because the JVM controls this scheduling, it can efficiently manage millions of virtual threads, each with a small memory footprint and negligible creation cost compared to platform threads.
This makes virtual threads ideal for I/O-bound, high-concurrency workloads — for example, servers handling thousands of simultaneous connections using blocking code.

→ Important Consideration

It’s really important to note that virtual threads don’t change CPU throughput.
For CPU-bound workloads, where tasks actively use the processor rather than waiting, performance remains limited by available CPU cores.
Virtual threads primarily optimize concurrency and scalability, not computation speed.
We will see this in example...

📈 Performance Comparison: Virtual vs Platform Threads

To get a practical sense of how these differences play out, let’s look at two simple benchmarks - one I/O-bound and one CPU-bound.

I/O-Bound

Testing how both models handle high concurrency with blocking operations.

public class VirtualVsPlatformIoBound {
    private static final int IO_TASKS = 10_000;
    private static final int IO_SLEEP_MS = 50;

    public long measureIO(String label, ExecutorService executor) throws Exception {
        long start = System.currentTimeMillis();
        for (int i = 0; i < IO_TASKS; i++) {
            executor.submit(this::remoteApiCall);
        }
        executor.shutdown();
        executor.awaitTermination(1, TimeUnit.MINUTES);
        long elapsed = System.currentTimeMillis() - start;
        System.out.printf("%s finished in %d ms\n", label, elapsed);
        return elapsed;
    }

    private void remoteApiCall() {
        try {
            Thread.sleep(IO_SLEEP_MS); // Simulated blocking I/O
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
}

// Test
class VirtualVsPlatformIoBoundTest {
    @Test
    void measureIO() throws Exception {
        var ioBound = new VirtualVsPlatformIoBound();
        System.out.println("==== I/O-Bound Workload ====");
        long ioPlatform = ioBound.measureIO("Platform Threads", Executors.newFixedThreadPool(200));
        long ioVirtual  = ioBound.measureIO("Virtual Threads", Executors.newVirtualThreadPerTaskExecutor());
        double speed = (double) ioPlatform / ioVirtual;
        System.out.printf("Speedup(I/O-bound): %.2fx\n", speed);
    }
}

I/O-Bound Result

==== I/O-Bound Workload ====
Platform Threads finished in 2689 ms
Virtual Threads finished in 126 ms
Speedup(I/O-bound): 21.34x

CPU-Bound

Testing performance when tasks are purely computational.

public class VirtualVsPlatformCpuBound {
    private static final int CPU_TASK_COUNT = 50_000;

    public long measureCPU(String label, ExecutorService executor) throws Exception {
        long start = System.currentTimeMillis();
        for (int i = 0; i < CPU_TASK_COUNT; i++) {
            executor.submit(this::cpuIntensiveTask);
        }
        executor.shutdown();
        executor.awaitTermination(1, TimeUnit.MINUTES);
        long elapsed = System.currentTimeMillis() - start;
        System.out.printf("%s finished in %d ms\n", label, elapsed);
        return elapsed;
    }

    // Burning CPU
    private long cpuIntensiveTask() {
        long sum = 0;
        for (int i = 0; i < 2_00_000; i++) {
            sum += (i * 37L) % 11;
        }
        return sum;
    }
}

// Test
class VirtualVsPlatformCpuBoundTest {
    @Test
    void measureCPU() throws Exception {
        var cpuBound = new VirtualVsPlatformCpuBound();
        System.out.println("==== CPU-Bound Workload ====");
        long cpuPlatform = cpuBound.measureCPU("Platform Threads", Executors.newFixedThreadPool(200));
        long cpuVirtual  = cpuBound.measureCPU("Virtual Threads", Executors.newVirtualThreadPerTaskExecutor());
        double speed = (double) cpuPlatform / cpuVirtual;
        System.out.printf("Speedup(CPU-bound): %.2fx\n", speed);
    }
}

CPU-Bound Result

==== CPU-Bound Workload ====
Platform Threads finished in 433 ms
Virtual Threads finished in 454 ms
Speedup(CPU-bound): 0.95x

💡 Yes, Results will vary depending on hardware and blocking time

Observations on Results 🔎

Virtual threads dramatically improve scalability in I/O-bound workloads by releasing carriers during blocking operations, enabling thousands of concurrent tasks with minimal overhead.
For CPU-bound tasks, both perform nearly the same; as I mentioned earlier as well — because computation still competes for physical cores, not thread count.
And Yes, I ran the test multiple times for getting the average/combined result.

🧭 Wrapping Up

Virtual threads don’t replace the fundamentals — they refine them.
In upcoming posts, I’ll dive into Structured Concurrency and other patterns that build on top of this model.

Spring Boot Actuators: Custom Endpoint

Manoj Sharma — Sat, 05 Aug 2023 09:55:56 +0000

In continuation to the blog series on Spring Actuators, In this post, Let's deep dive into more customization we can do with spring actuators.

No doubt, By default, Spring Actuator exposes a wider set of pre-defined endpoints that can be accessed to gather information about your application's health, metrics, configuration, and more. But there are scenarios where you might want to create custom Actuator endpoints to extend the monitoring and management capabilities of your application.

Here are some benefits and scenarios where custom endpoints can be useful:

Administrative Tasks: You can use custom endpoints to perform administrative tasks on your application. For example, triggering a specific maintenance routine, clearing cache, or reloading configurations can be exposed through custom endpoints.
Custom Health Checks: While Actuator provides a default health check endpoint, And in the last Post we deep dived into customizing your health endpoint. But your application might have specific health checks that are beyond the scope of the built-in checks. Custom health check endpoints allow you to implement and expose these checks.
Security and Access Control: By creating custom endpoints, you have fine-grained control over who can access specific monitoring and management information. This allows you to restrict access to sensitive endpoints, ensuring that only authorized users or systems can interact with them.
Third-party Integrations: If your application relies on external services or APIs, you can create custom endpoints to monitor the health and status of these integrations. This can be especially useful to quickly identify issues with external dependencies.
Complex Aggregations: The default Actuator endpoints provide basic metrics, but in some cases, you might need to perform complex aggregations and calculations to derive meaningful insights.

Building Custom Endpoint

Now, Let's try to build our own custom HTTP actuator endpoint.

@endpoint

@endpoint annotation is a core component of Spring Actuators. Once you annotate your class with @endpoint annotation and provide id field (mandatorily) as custom value, This class will now represent your custom endpoint.

@Component
@Endpoint(id="custom")
public class CustomActuatorEndpoint {
    ...
}

Do not forget to make your endpoint class spring-managed component by defining @Component annoation.

This will make following actuator endpoint available to be served: http://your-example-web-app:2121/actuator/custom. Not let's define Operations to add the definition for this custom endpoint.

Endpoint Operations

Spring Boot Actuator endpoints support mainly 3 basic operations to interact with custom endpoints. You can define methods and annotate them with these annotations.

@ReadOperation: @ReadOperation is used to handle HTTP GET requests. It is used to retrieve information from the Actuator endpoint. Typically, this operation is used to expose various metrics, health information, configurations, and other read-only data.
@WriteOperation: This operation type is used to handle HTTP POST requests to modify the state of the application or perform actions that have side effects.
@DeleteOperation: As it states, @DeleteOperation is used to handle HTTP DELETE requests to remove or delete resources from the application. It can be helpful when you want to provide an API for removing resources or performing specific cleanup tasks.

It is always recommended to secure your actuator endpoint with spring security while exposing sensitive information or performing write/delete operations that alters the state/config of your application.

It is quiet similar to defining an endpoint using Get/Post/Delete Mappings.

Example Custom Endpoint

Enough Theory 🤔, Let's write a custom actuator endpoint to manage your application release notes.

This is how your ReleaseNote data object looks like

public class ReleaseNote {
    private String version;
    private LocalDateTime date;
    private String changeLogData;
    // Constructors
    // Getters/Setters
}

Now, Let's write ReleaseNoteEndpoint class which uses ReleaseNotesDataRepository to manage persistence of your ReleaseNote object.

@Component
@Endpoint(id="releaseNotes")
public class ReleaseNotesEndpoint {

    @Autowired
    private ReleaseNotesDataRepository releaseNotesDataRepository;

    @ReadOperation
    public List<ReleaseNote> getReleaseNotes() {
        return releaseNotesDataRepository.getReleaseNoteList();
    }

    @WriteOperation
    public ReleaseNote addReleaseNote(String version, String changeLogData) {
        ReleaseNote releaseNote = new ReleaseNote(version, LocalDateTime.now(), changeLogData);
        return releaseNotesDataRepository.addReleaseNote(releaseNote);
    }

    @DeleteOperation
    public void deleteReleaseNote(@Selector String version) {
        releaseNotesDataRepository.deleteReleaseNote(version);
    }
}

Spring Actuator comes with @Selector annotation that is used as an argument of an @endpoint method to indicate the path parameter for your endpoint

Let's play with the new shiny actuator endpoint to manage release notes.

Add new Release Note

$ curl --location --request POST 'http://localhost:2121/actuator/releaseNotes' \
--header 'Content-Type: application/json' \
--data '{
    "version": "1.0",
    "changeLogData": "changeLog"
}' -i

# Response
HTTP/1.1 200 
...
{"version":"1.0","date":"2023-08-05T15:01:37.456528","changeLogData":"v1.0 changeLog"}

List all Release Notes

curl --location --request GET 'http://localhost:2121/actuator/releaseNotes' -i

# Response
HTTP/1.1 200 
...
[{"version":"1.0","date":"2023-08-05T15:01:37.456528","changeLogData":"v1.0 changeLog"}]

Delete Release Note

curl --location --request DELETE 'http://localhost:2121/actuator/releaseNotes/1.0' -i

# Response
HTTP/1.1 204

Final Words

Incorporating custom Actuator endpoints into your Spring Boot applications can be really helpful to fulfil your custom needs. These tailored endpoints empower your boot application to extract specific insights, enact administrative tasks, and dynamically adjust configurations. Would love to hear your experience and thoughts!

Spring Boot Actuators: Customise Health Endpoint

Manoj Sharma — Sat, 22 Jul 2023 11:38:30 +0000

In last post, I talked about configuring and leveraging spring boot actuators to configure your boot application to have production ready features.

In this Post, let's customise Health endpoint, which is one of the important actuator endpoint, It helps in:

Monitoring Application Health: The Health endpoint provides a simple and standardized way to monitor the health of your application. It allows you to quickly check whether your application is running correctly or encountering any issues. Monitoring the health status of your application helps you identify and respond to potential problems early, reducing downtime and ensuring a better user experience.
Proactive Issue Detection: By regularly polling the Health endpoint, monitoring tools and systems can proactively detect any degradation or failure in your application's health. This enables your operations team to take immediate action before issues escalate and impact users.
Integration with Orchestration Tools: In modern production environments, applications are often managed and orchestrated by tools like Kubernetes, Docker Swarm, or cloud platforms.
Operational Insights: The Health endpoint provides essential information about your application's internals. You can customize the endpoint to include details about database connections, external service status, resource availability, and more. These details are valuable for troubleshooting and gaining insights into your application's behavior during runtime.

Spring Actuators provide rich API support to customize health endpoint response.

Let's first enable health endpoint from the configurations and allow it to show details:

management.endpoints.web.exposure.include=health
management.endpoint.health.show-details=always

By default, it exposes ping status and disk details:

{
    "status": "UP",
    "components": {
        "diskSpace": {
            ...
            ...
            ...
        },
        "ping": {
            "status": "UP"
        }
    }
}

We can disable this default response by setting management.health.defaults.enabled property to false

Customising Health endpoint by implementing HealthIndicator

Implementing the HealthIndicator interface allows you to create custom health indicators to monitor specific aspects of your application.

The HealthIndicator (package: org.springframework.boot.actuate.health) interface is part of the Spring Boot Actuator module, and it provides a single method, health(), that returns a Health object representing the health status of your custom indicator. It provides several static methods to create instances of Health, as well as to add additional details and contextual information about the health check.

Here are some commonly used static methods of the Health class:

up(): Creates a Health instance with an UP status, indicating that the application is in a healthy state.

down(): Creates a Health instance with a DOWN status.

unknown(): Creates a Health instance with an UNKNOWN status.

status(Status status): Creates a Health instance with a custom status. The Status enum represents the health status, and it can be UP, DOWN, or UNKNOWN.

withDetail(String key, Object value): Adds additional details to the Health instance. These details provide more information about the health status and can be useful for troubleshooting and monitoring.

withDetails(Map details): Adds multiple details to the Health instance at once, using a Map of key-value pairs.

Let's now write an implementation of the HealthIndicator interface i.e. ExternalServiceHealthIndicator.class. It's a typical example, where I am returning a Health object based on HTTP statusCode received from external service call.

@Component
public class ExternalServiceHealthIndicator implements HealthIndicator {

    private final Random randomizer = new Random();
    private final List<Integer> statusCodes = List.of(200, 204, 401, 404, 503);

    @Override
    public Health health() {
        int randomStatusCode = statusCodes.get(randomizer.nextInt(statusCodes.size()));
        Health.Builder healthBuilder = new Health.Builder();
        return (switch(randomStatusCode) {
            case 200, 204 -> healthBuilder.up()
                    .withDetail("External_Service", "Service is Up and Running ✅")
                    .withDetail("url", "https://example.com");
            case 503 -> healthBuilder.down()
                    .withDetail("External_Service", "Service is Down 🔻")
                    .withDetail("alternative_url", "https://alt-example.com");
            default -> healthBuilder.unknown().withException(new RuntimeException("Received status: " + randomStatusCode));
        }).build();
    }
}

@ConditionalOnEnabledHealthIndicator annotation

@ConditionalOnEnabledHealthIndicator is a meta-annotation in org.springframework.boot.actuate.autoconfigure.health package to conditionally enable or disable the health check provided by that specific indicator and requires indicatorName as a mandatory String argument which can be enabled with the externalised application configuration. Let's see an example in action.

@Component
@ConditionalOnEnabledHealthIndicator("external_service_health")
public class ExternalServiceHealthIndicator implements HealthIndicator {

    @Override
    public Health health() {
        ...
    }
}

The Custom indicator can be enabled/disabled by setting management.health.<custom-indicator>.enabled property true/false in the application's configuration. If the property is not present or set to false, the indicator will not be enabled.

management.health.external_service_health.enabled: true

Final Words

Health Endpoint is a really useful endpoint to Monitor your Application health, get Operational insights, health check your deployments. Please share your thoughts/opinions in the comments.

Spring Boot Actuators: Expose Operational Info

Manoj Sharma — Sun, 10 Jul 2022 12:08:38 +0000

Spring boot has gained a lot of popularity with time, because of its provided features. and now this framework offers solutions for a wide range of enterprise problems and patterns and fits best into every need, It is bundled with a large number of auto configurable libraries/modules to reduce the boiler plate and allow you to focus on your business logic.

Spring boot Actuator is one of the popular feature of Spring Boot for creating production ready applications. Actuator exposes set of endpoints to monitor your application health, view metrics, secure them with spring security and many other features that are necessary for you to declare your application production ready.

Features of Spring Boot Actuator

Spring Boot Actuator module allows you to monitor your applications in 2 ways; either by leveraging HTTP endpoints or JMX (Java Management Extension). Most of the applications leverage HTTP endpoints.
Endpoints: Actuator module is bundled with a rich set of HTTP endpoints to monitor and interact with the application. You can even create custom endpoints to fulfil your needs, and also leverage spring-security to secure actuator endpoints. Few examples are
- info
- health
- metrics
- beans
- caches
- loggers
- mappings
Metrics: Spring Boot Actuator provides support for a instrumentation library, called Micrometer, which is a vendor neutral application metrics facade that captures and exposes application metrics to different monitoring solutions such as Prometheus, Dynatrace, New Relic, DataDog and many more... It provides interfaces for timers, gauges, counters, distribution summaries, and long task timers with a dimensional data model.
Actuator module is highly (yet simply) configurable and you can utilise your application.[properties|yaml] file to meet most of your customised needs.

Let's build a spring boot application and witness the magic of spring-boot-actuator in action...

Pre-Requisites:

Java installed on your system (JDK 17 recommended), Try SDKMAN to manage your JDK versions.
Spring project with starter-web dependency.

$ curl -G https://start.spring.io/starter.zip \
    -d type=gradle-project \
    -d language=java \
    -d packaging=jar \
    -d javaVersion=17 \
    -d dependencies=web \
    -d name=spring-boot-actuator-example \
    -d baseDir=spring-boot-actuator-example \
    -o starter.zip
$ # You can specify more options using -d option; like groupId, artifactId, packageName
$ unzip starter.zip
$ # Open project in your preferred IDE

Adding Spring Boot Actuator to your application

Add 'spring-boot-starter-actuator' dependency in your build configuration file.
For maven users:

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

For gradle users:

implementation 'org.springframework.boot:spring-boot-starter-actuator'

As soon as you add starter-actuator dependency in your classpath and restart the application (after rebuilding), you can see actuator endpoints are enabled by spring boot. By default, '/actuator' is a base-path for your all actuator endpoints.

INFO 9143 --- [           main] i.c.s.SpringbootActuatorsApplication     : No active profile set, falling back to 1 default profile: "default"
INFO 9143 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat initialized with port(s): 8080 (http)
INFO 9143 --- [           main] o.apache.catalina.core.StandardService   : Starting service [Tomcat]
INFO 9143 --- [           main] org.apache.catalina.core.StandardEngine  : Starting Servlet engine: [Apache Tomcat/9.0.64]
INFO 9143 --- [           main] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring embedded WebApplicationContext
INFO 9143 --- [           main] w.s.c.ServletWebServerApplicationContext : Root WebApplicationContext: initialization completed in 648 ms
INFO 9143 --- [           main] o.s.b.a.e.web.EndpointLinksResolver      : Exposing 1 endpoint(s) beneath base path '/actuator'
INFO 9143 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port(s): 8080 (http) with context path ''
INFO 9143 --- [           main] i.c.s.SpringbootActuatorsApplication     : Started SpringbootActuatorsApplication in 1.271 seconds (JVM running for 1.818)
INFO 9143 --- [on(1)-127.0.0.1] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring DispatcherServlet 'dispatcherServlet'
INFO 9143 --- [on(1)-127.0.0.1] o.s.web.servlet.DispatcherServlet        : Initializing Servlet 'dispatcherServlet'
INFO 9143 --- [on(1)-127.0.0.1] o.s.web.servlet.DispatcherServlet        : Completed initialization in 1 ms

The application is started on port 8080, Let's hit '/actuator' endpoint to see all the available actuator endpoints...

As you can observe there is only '/actuator/health' endpoint is exposed, By default all the other endpoints are disabled, because of security reasons, Since some of the actuator endpoints can expose sensitive data, So be careful...

Let's enable all the endpoints...Update your 'application.properties' file by setting 'management.endpoints.web.exposure.include' property

management.endpoints.web.exposure.include=*

'*' pattern will enable all the endpoints exposed by actuator module. But it is recommended to expose a specific set of endpoints (comma separated list) which is necessary for your operational requirement to avoid any security issues.
NOTE: 'shutdown' endpoint will still be disabled since it is highly critical for your application. It is used to gracefully shutdown your application.
Let's try by hitting 'http://localhost:8080/actuator'

{
   "_links" : {
      "beans" : {
         "href" : "http://localhost:8080/actuator/beans",
         "templated" : false
      },
      "caches" : {
         "href" : "http://localhost:8080/actuator/caches",
         "templated" : false
      },
      "caches-cache" : {
         "href" : "http://localhost:8080/actuator/caches/{cache}",
         "templated" : true
      },
      "conditions" : {
         "href" : "http://localhost:8080/actuator/conditions",
         "templated" : false
      },
      "configprops" : {
         "href" : "http://localhost:8080/actuator/configprops",
         "templated" : false
      },
      "configprops-prefix" : {
         "href" : "http://localhost:8080/actuator/configprops/{prefix}",
         "templated" : true
      },
      "env" : {
         "href" : "http://localhost:8080/actuator/env",
         "templated" : false
      },
      "env-toMatch" : {
         "href" : "http://localhost:8080/actuator/env/{toMatch}",
         "templated" : true
      },
      "health" : {
         "href" : "http://localhost:8080/actuator/health",
         "templated" : false
      },
      "health-path" : {
         "href" : "http://localhost:8080/actuator/health/{*path}",
         "templated" : true
      },
      "heapdump" : {
         "href" : "http://localhost:8080/actuator/heapdump",
         "templated" : false
      },
      "info" : {
         "href" : "http://localhost:8080/actuator/info",
         "templated" : false
      },
      "loggers" : {
         "href" : "http://localhost:8080/actuator/loggers",
         "templated" : false
      },
      "loggers-name" : {
         "href" : "http://localhost:8080/actuator/loggers/{name}",
         "templated" : true
      },
      "mappings" : {
         "href" : "http://localhost:8080/actuator/mappings",
         "templated" : false
      },
      "metrics" : {
         "href" : "http://localhost:8080/actuator/metrics",
         "templated" : false
      },
      "metrics-requiredMetricName" : {
         "href" : "http://localhost:8080/actuator/metrics/{requiredMetricName}",
         "templated" : true
      },
      "scheduledtasks" : {
         "href" : "http://localhost:8080/actuator/scheduledtasks",
         "templated" : false
      },
      "self" : {
         "href" : "http://localhost:8080/actuator",
         "templated" : false
      },
      "threaddump" : {
         "href" : "http://localhost:8080/actuator/threaddump",
         "templated" : false
      }
   }
}

Take a look on this spring documentation for detailed explanation of each endpoint.

*Some more configuration in your application.properties file:

#1. Update default port for actuator endpoints
management.server.port=2121

#2. Update base-path to use **'/manage'** instead of **'/actuator'**
management.endpoints.web.base-path=/manage

#3. Following will ensure include all actuator endpoints except 'mappings' and 'heapdump'
management.endpoints.web.exposure.include=*
management.endpoints.web.exposure.exclude=mappings,heapdump

Health Endpoint

Health endpoint exposes your application's health to outside world (with useful data), This endpoint becomes more important in distributed systems, where liveness of your one service is dependent on another service like databases, queues or other applications.
Now, Let's try '/actuator/health' endpoint, and see the response

Right now the only information being returned by health endpoint is whether the application is up or not, by default health endpoint does not show all of the details. This can be enabled (or securely enabled) by setting value of health.show-details attribute.

management.endpoint.health.show-details=always
# Possible values for health.show-details can be one of the following
# never|always|when_authorized
# by default it is set to 'never', 
# 'always' will display all the details,
# 'when_autorized' will display details when requesting user is authorized.

Output (health endpoint with status and diskspace):

Please note Spring Boot Actuator module support configuration update for each endpoint individually by using following pattern.

# Pattern: management.endpoint.{endpoint-name}.{property}=value
# property attribute can vary according to endpoint

management.endpoint.configprops.enabled=true
management.endpoint.info.enabled=false

management.endpoint.beans.cache.time-to-live=10s

management.endpoint.logfile.external-file=~/app.log

Info Endpoint

Let's try '/actuator/info' endpoint now, and see what it returns.

So, by default info endpoint does not return any useful information, You can customise the response of info endpoint by updating build configurations, Let's walk through how you can configure the info endpoint in build.gradle file.
Maven users can also follow this official spring doc

For gradle users, let's first update the build.gradle file, Add buildInfo task, and update version value.

description = 'Spring Boot Actuator Configuration App'
version = '2.0.0'

springBoot {
    buildInfo() {
        properties {
            additional = [
                    'lastRelease': '1.0.0',
                    'description': rootProject.description
            ]
        }
    }
}

Apart from build info, You can also set additional information in application.properties file:

management.info.env.enabled=true

app.cusomInfo=This is Custom Info
info.app.cusomInfo=${app.cusomInfo}
info.app.java-version=${java.version}
info.app.java-vendor=${java.vendor}
info.app.excluded-actuator-enpoints=${management.endpoints.web.exposure.exclude}

Let's now see output of '/actuator/info' endpoint:

You can observe all the configured information in response. The info endpoint can be extended further to expose git related info (like commit id, branch).

Final Words:

As we can observe just by leveraging the application.[properties|yaml] file, we can fully customise and configure our actuator endpoints to expose useful information. In subsequent posts we will see how we can create custom endpoints, and connect to different monitoring tools using micrometer.

Source Code: manojshr/springboot-actuators

Please share your thoughts in the comments!

Ansible for Managing Configurations...

Manoj Sharma — Fri, 18 Mar 2022 15:27:02 +0000

So, What is Ansible?

Ansible is simply an Automation Tool, which handles automation of your IT infrastructure, like:

Few reasons that make Ansible my first choice:

Ansible is a Push-based configuration management tool that makes it more powerful and different from other configuration management tools. It requires to setup a control node only, and you are good to push your configurations or deployments to any (or self) node configured in your inventory. sounds cleaner way to set up a node :)
It is open source and free to use.
CentOS and Ubuntu Linux is one of the choices for application deployments, and by default, Ansible is packaged to support a number of modules that are commonly used for managing the virtual machines.
Ansible is backed by a strong developer community, so no need to worry if you are stuck, you will get help easily.
Ansible offers a very high and seamless integration with leading cloud providers (AWS, Azure, GCP), different automation tools (like StackStorm), and various 3rd Party services.
It is highly customizable based on your workflow requirements, with the ability to easily create new modules/sub-modules and plugins.

How to Setup?

Ansible is an agentless automation tool that you install on a control node. From the control node, Ansible manages machines and other devices remotely (by default, over the SSH protocol).

Ansible is supported on the majority of general-purpose Operating systems. A few of them are Linux (RHEL, CentOS, Fedora, Ubuntu, Debian, Arch), macOS, Windows...

There are several ways to install Ansible on your control node. If your OS supports a rich package manager that comes with Ansible binaries, go for it. If not, Ansible and its required binaries can be easily installed using python's widely used package management tool, pip.

Install pip on your control node (https://pip.pypa.io/en/stable/installation/)
Install Ansible using pip

$ python -m pip install --user ansible

How Ansible Works?

Ansible works by connecting your control node to managed nodes and pushing out small programs, called "Ansible Modules" to them. Ansible then executes these modules (over SSH by default) and removes them when finished. The configuration of all the managed nodes can be done in the inventory file. Ansible even supports Jinja2 templating to enable dynamic expressions and access to variables and facts.

So How do we tell Ansible to execute these modules?

Executing an ad-hoc command
Write the flow of your configurations in an Ansible playbook. Ansible Playbook is a YAML file, in which you write ordered instructions for pushing your configurations; these instructions are nothing but writing the modules, which will be executed on the remote hosts.

Let's see an example in action:

Presumably, you have already installed Ansible on your control node, we will go through the process of running the Ansible playbooks step by step.

Verify Ansible setup on Control Node
Create the Managed node and configure the SSH keys
Setup the standard Ansible directory on control Node
Write a playbook
Running your playbook

1. Verify Ansible setup on Control Node

The Ansible 'ping' module is a simple but useful tool for testing connectivity with a remote host. The module will attempt to connect to the remote, validate a usable 'python', and return 'pong' if successful.

~ ➜ ansible localhost -m ping
localhost | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

2. Create a managed node and set up the SSH keys

We will bootstrap a minimal Ubuntu virtual machine, where we will setup the configurations using ansible. Additionally, we will setup the SSH keys to allow access to the managed node from your control node.

2.A Install multipass

Multipass is a lightweight VM manager, and we can launch Ubuntu instances using the multipass cli.
Installation Instructions: https://multipass.run

2.B Launching Multipass instance

~ ➜ #List available multipass instances
~ ➜ multipass find
Image                       Aliases           Version          Description
18.04                       bionic            20220310         Ubuntu 18.04 LTS
20.04                       focal,lts         20220308         Ubuntu 20.04 LTS
21.10                       impish            20220309         Ubuntu 21.10

~ ➜ #Launch bionic instance with default configurations
~ ➜ multipass launch --name ubuntu-bionic bionic
Launched: ubuntu-bionic

2.C Copy SSH keys to ubuntu VM

~ ➜ #Generating SSH key pair
~ ➜ ssh-keygen -t rsa -N '' -f /tmp/ansiblekey <<< y
Generating public/private rsa key pair.
Your identification has been saved in /tmp/ansiblekey
Your public key has been saved in /tmp/ansiblekey.pub
The key fingerprint is:
SHA256: <random-chars> manojsh@192.168.54.24

~ ➜ #Copying public key to multipass instance
~ ➜ cat /tmp/ansiblekey.pub | multipass exec ubuntu-bionic -- tee -a .ssh/authorized_keys

2.D Verify SSH to multipass instance

~ ➜ #List Multipass instances
➜  Installs multipass ls
Name                    State             IPv4             Image
ubuntu-bionic           Running           192.168.215.15    Ubuntu 18.04 LTS

~ ➜ #SSH into multipass instance
➜  ssh -i /tmp/ansiblekey ubuntu@192.168.215.15
The authenticity of host '192.168.215.15 (192.168.215.15)' can not be established.
ED25519 key fingerprint is <random-chars>.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes

To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

ubuntu@ubuntu-bionic:~$

3. Setup the standard Ansible directory on control Node

3.A Create an `AnsibleWorkspace` directory

~ ➜ #Create a directory where you can keep your playbooks, inventory and other required files.
~ ➜ mkdir AnsibleWorkspace
~ ➜ cd AnsibleWorkspace
AnsibleWorkspace ➜ ls -a
.  ..
AnsibleWorkspace ➜

3.B Create `ansible.cfg` file

'ansible.cfg' is a main configuration file that governs the behavior of all interactions performed by the control node.

~ ➜ #Generating default ansible config file with all properties disabled
AnsibleWorkspace ➜ ansible-config init --disabled > ansible.cfg

3.B Create inventory file

Ansible works against managed hosts that are configured in your inventory file as a list or group of lists. The default location for inventory is /etc/ansible/hosts, but we can override this by updating path value of inventory field in ansible.cfg file. Let's first create an inventory file for our multipass ubuntu instance.

AnsibleWorkspace ➜ cat > ./inventory << EOL
[webservers]
nginxserver ansible_host=192.168.215.15 ansible_user=ubuntu
EOL

ansible_host and ansible_user values are nothing but the IPAddress and username of your configured multipass instance; using this info ansible will connect to the multipass instance via SSH.

Please read this official link to learn more about inventory file creation.

3.C Update inventory and ssh-key file path in 'ansible.cfg' file

Open the ansible.cfg file and set the following values under defaults section

[defaults]
inventory=./inventory
private_key_file=/tmp/ansiblekey

3.D Verify the Ansible Configuration

Since we have already configured inventory and private key path, we are good to verify connectivity with our multipass instance 'nginxserver'.

➜  AnsibleWorkspace ansible nginxserver -m ping                                            
nginxserver | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}

4. Write a playbook

Playbooks are the language by which Ansible orchestrates, configures, administers, or deploys systems.
Let's write a playbook to setup an Nginx server.
Create nginx-setup.yml file in your AnsibleWorkspace directory with tasks to install and start an Nginx server.

---
- hosts: nginxserver
  become: yes
  tasks:
    - name: Install nginx latest version on host
      apt: 
        name: nginx 
        state: latest

    - name: Start nginx service
      service:
          name: nginx
          state: started

Let's take a look at each and every part of your playbook file:

hosts: The name of the node or node-group configured in your inventory.
become: The become flag instructs ansible to connect as a root user.
tasks: tasks is a list of modules that we wish to run on the managed node in a specific order. Every task will include a 'name' field as well as a'module' with configurable arguments.
apt The apt module will install the newest version of Nginx using the standard Ubuntu apt package manager.
service service module controls services on managed node.

5. Running your playbook

Ansible is packaged with a set of binaries, We can run an ansible playbook using the ansible-playbook command.

AnsibleWorkspace ➜ ansible-playbook nginx-setup.yaml                                                        

PLAY [nginxserver] **************************************************************

TASK [Gathering Facts] **************************************************************
ok: [nginxserver]

TASK [Install nginx latest version on host] **************************************************************
changed: [nginxserver]

TASK [Start nginx service] **************************************************************
changed: [nginxserver]

PLAY RECAP **************************************************************
nginxserver                : ok=2    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Playbook executed without any error, and we can see it has installed and started nginx service. Now, let's verify the output, go to http://192.168.215.15 (multipass instance ip, default port 80) in your browser.

Final Words

Ansible is a straightforward yet powerful automation solution for automating your IT infrastructure. It can manage modest to large-scale systems. We can use ad-hoc commands to meet simple demands or construct complicated playbooks to set up a multi-node orchestration.
Resources to learn more about ansible:

JDK 18: Simple Web Server

Manoj Sharma — Sat, 22 Jan 2022 10:00:01 +0000

JDK 18 version is all set to release in March 2022 and will be coming with 9 new features (with some enhancement features from the previous versions).

400: UTF-8 by Default
408: Simple Web Server
413: Code Snippets in Java API Documentation
416: Reimplement Core Reflection with Method Handles
417: Vector API (Third Incubator)
418: Internet-Address Resolution SPI
419: Foreign Function & Memory API (Second Incubator)
420: Pattern Matching for switch (Second Preview)
421: Deprecate Finalization for Removal

JDK 18 will be packaged with a NEW command line (i.e. jwebserver) tool to start a minimal web server that serves static files only. As of now (even no confirmations about future plans), there is No CGI or servlet-like functionality available with jwebserver. This tool will be useful for prototyping, ad-hoc coding, and testing purposes, particularly in educational contexts.

The Simple Web Server is a minimal HTTP server for serving a single directory hierarchy and can be used via the dedicated command-line tool jwebserver or programmatically via its API.

Installation of JDK 18 EA builds (as of now only EA builds are available):

One can download the JDK 18 Early-Access Builds from jdk.java.net

Or Another way to manage the JDK versions would be using SDKMAN. Take a look at the usage page to setup desired java version.

$ curl -s "https://get.sdkman.io" | bash
$ sdk install java 18.ea.31-open

A. Using jwebserver Command Line:

After installing JDK 18 we are set to use jwebserver command line utility.
By default, the server runs in the foreground and binds to the loopback address and port 8000. Also, if the directory (-d option) is not specified, files are served from the current directory.

$ jwebserver --help
Usage: jwebserver [-b bind address] [-p port] [-d directory]
                  [-o none|info|verbose] [-h to show options]
                  [-version to show version information]
Options:
-b, --bind-address    - Address to bind to. Default: 127.0.0.1 (loopback).
                        For all interfaces use "-b 0.0.0.0" or "-b ::".
-d, --directory       - Directory to serve. Default: current directory.
-o, --output          - Output format. none|info|verbose. Default: info.
-p, --port            - Port to listen on. Default: 8000.
-h, -?, --help        - Prints this help message and exits.
-version, --version   - Prints version information and exits.
To stop the server, press Ctrl + C.

Let’s serve a directory containing HTML content using jwebserver, and see how this utility made it easier.

1) Create a directory and add an index.html file in the directory with some html content.

$ mkdir jdk18-webserver
$ cd jdk18-webserver
$ echo "<h1>Hello World from JWebServer</h1>" > index.html

2) Run the jwebserver

$ jwebserver -p 8080 -d /Users/home/jdk18-webserver

Binding to loopback by default. For all interfaces use "-b 0.0.0.0" or "-b ::".
Serving /Users/home/jdk18-jwebserver and subdirectories on 127.0.0.1 port 8080
URL http://127.0.0.1:8080/

B. Using APIs:

While the command-line tool is useful, what if one wants to use the components of the Simple Web Server (i.e. server, handler, and filter) with existing code, or further customize the behavior of the handler?

This Simple Webserver API is based on the web server implementation in the com.sun.net.httpserver package that has been included in the JDK since 2006. The package is officially supported and extended with APIs to simplify server creation and enhance request handling.

The SimpleFileServer class supports the creation of a file server, a file-server handler, and an output filter:

package com.sun.net.httpserver;

public final class SimpleFileServer {
    public static HttpServer createFileServer(InetSocketAddress addr,
                                              Path rootDirectory,
                                              OutputLevel outputLevel) {...}
    public static HttpHandler createFileHandler(Path rootDirectory) {...}
    public static Filter createOutputFilter(OutputStream out,
                                            OutputLevel outputLevel) {...}
    ...
}

Let's create a server instance using jshell.
1) Define the server configurations.

jshell> import com.sun.net.httpserver.SimpleFileServer;
jshell> var dir = "/Users/home/jdk18-webserver";
jshell> var PORT = 8080;
jshell> var server = SimpleFileServer.createFileServer(new InetSocketAddress(PORT),
            Path.of(dir), SimpleFileServer.OutputLevel.VERBOSE);

2) Starting the web server: static method SimpleFileServer.createFileServer() returns the instance of com.sun.net.httpserver.HttpServer which can be used to start or stop the server.

jshell> server.start()

Logs generated on hitting the URL (http://127.0.0.1:8080) -

jshell> 127.0.0.1 - - "GET / HTTP/1.1" 200 -
Resource requested: /Users/home/jdk18-jwebserver
> Accept-encoding: gzip, deflate, br
> Accept: text/html,application/...
> Sec-fetch-dest: document
> Sec-fetch-user: ?1
> Connection: keep-alive
> Sec-fetch-site: none
> Host: 127.0.0.1:8080
> Accept-language: en-GB,en;q=0.9,en-US;q=0.8
...
...
...
< Content-type: text/html
< Content-length: 36

3) Stopping the server: The HttpServer instance has stop method which accepts delay in seconds as Integer argument. The method will then block until all current exchange handlers have completed or else when approximately delay seconds have elapsed (whichever happens sooner).

// server.stop(delay: Integer)
jshell> server.stop(0)

Thoughts

As Intended, The Simple Web Server is not so feature-rich, but it is an appropriate tool to get your static contents served without handling the hassles of writing a huge chunk of code for such a small work to be done. To learn more about jwebserver, check out the official JEP 408 document...

Please share your thoughts in the comments!

DEV Community: Manoj Sharma

The Engineering Guardrails We Need After AI Started Writing the Code

Guardrail #1 — Fully Covered Tests Become Code Reasoning Documentation

Guardrail #2 — AI Writes Happy Paths. Systems may fail Unexpectedly.

Guardrail #3 — Instruct AI to Test System Behaviour, Not Just Code Interaction

Problem 1 — Mocking Infrastructure Clients (e.g. OpenSearch)

Problem 2 — Mocking DB Interaction (When You Have Liquibase)

Instruct AI to Write Real Integration Tests

Guardrail #4 — Instruct AI to Log With Context, Not Just Confirmation

Instruct AI to write structured logs with failure context from the start:

Final Thoughts

Be a Responsible Code Reviewer

Why Strong Engineering Teams 💪 Treat Code Reviews Seriously?

1. Catching Hidden Logic or Edge-Case Bugs

2. Improving Design and Readability

3. Spotting Performance & Concurrency Pitfalls

How CI Helps Developers Trust Their Code?

CI Handles What Humans Need not to

Building a Learning Culture Through Code Reviews

1. Tech Review Sessions With the Team

2. Knowledge Sharing Example

3. Language Modernization Through Reviews

How to Be a Responsible Code Reviewer ⭐️

1. Understand The Context Before The Code

2. Ask Questions, Don’t Command

3. Praise Good Code When You See It

4. When You Reject Something, Reject the Code — Not the Dev

5. Be Fast. Be Respectful. Be Honest.

6. Review the Scope — Not the Galaxy

7. Don’t Just Point Out Problems — Propose Alternatives

Wrapping up

Virtual Threads - Comparative Analysis

Arrival of Virtual Threads 🚀

How to Create?

Platform Threads

Virtual Threads (JDK 21+)

What’s Really Different Here?

→ Difference in Mechanics: Platform v/s Virtual

→ Scheduling Responsibility

→ Important Consideration

📈 Performance Comparison: Virtual vs Platform Threads

I/O-Bound

I/O-Bound Result

CPU-Bound

CPU-Bound Result

Observations on Results 🔎

🧭 Wrapping Up

Spring Boot Actuators: Custom Endpoint

Building Custom Endpoint

@endpoint

Endpoint Operations

Example Custom Endpoint

Add new Release Note

List all Release Notes

Delete Release Note

Final Words

Spring Boot Actuators: Customise Health Endpoint

Customising Health endpoint by implementing HealthIndicator

@ConditionalOnEnabledHealthIndicator annotation

Final Words

Spring Boot Actuators: Expose Operational Info

Features of Spring Boot Actuator

Pre-Requisites:

Adding Spring Boot Actuator to your application

Health Endpoint

Info Endpoint

Final Words:

Ansible for Managing Configurations...

So, What is Ansible?

How to Setup?

How Ansible Works?

Let's see an example in action:

1. Verify Ansible setup on Control Node

2. Create a managed node and set up the SSH keys

2.A Install multipass

2.B Launching Multipass instance

2.C Copy SSH keys to ubuntu VM

2.D Verify SSH to multipass instance

3. Setup the standard Ansible directory on control Node

3.A Create an AnsibleWorkspace directory

3.A Create an `AnsibleWorkspace` directory

3.B Create `ansible.cfg` file