Krishan Chawla

Playwright vs. Selenium — Trade-offs at Expert Depth

Thu, 02 Jul 2026 00:00:00 GMT

Introduction

"Playwright vs. Selenium" is usually framed as a popularity contest — newer, faster tool vs. the incumbent everyone already knows. That framing hides the actual decision, which is architectural: how each tool talks to the browser, what that buys you, and what it costs you in environments Selenium was never designed for and Playwright hasn't fully solved either.

This isn't a "just use Playwright" post. Both tools are still correct choices depending on what you're testing, what you already have in CI, and how much control you need over the browser layer.

At a glance, before the detail:

| Category | Playwright | Selenium | |---|---|---| | Protocol | CDP / WebDriver BiDi | W3C WebDriver | | Synchronization | Auto-waiting, built in | Explicit/implicit waits you manage | | Cross-browser | Chromium, Firefox, WebKit (bundled builds) | Virtually every real installed browser | | Mobile | Emulation only, no native apps | Real device/native coverage via Appium | | Parallelism | Native (workers, contexts, sharding) | Framework-dependent (Grid, TestNG, Docker) | | Network interception | Native (page.route()) | Requires CDP or a proxy like BrowserMob | | API testing | Built in (APIRequestContext) | Needs a separate client (REST Assured, etc.) | | Debugging artifacts | Trace, video, screenshots built in | Needs third-party tooling | | Ecosystem maturity | Growing fast | Extremely mature, 15+ years |

The rest of this post is why each row is the way it is, and where the table oversimplifies.

Architecture: the actual difference

Selenium — WebDriver, out-of-process

Selenium talks to the browser through the W3C WebDriver protocol: your test issues an HTTP request to a driver process (chromedriver, geckodriver, msedgedriver), which translates it into native browser automation calls.

Test code → WebDriver client → HTTP (JSON Wire / W3C) → Driver binary → Browser

Every action — click, type, navigate — is a network round trip through an external process. This is why Selenium is slower and why "flaky" has historically been associated with it: there's no shared execution context between your test and the browser, so Selenium has no native way to know when the DOM has actually settled after an action. That's what WebDriverWait and ExpectedConditions exist to paper over.

Playwright — CDP/BiDi, in-process control

Playwright talks to Chromium and WebKit browsers directly over the Chrome DevTools Protocol (and increasingly WebDriver BiDi for Firefox), using a persistent WebSocket connection from a Node/Python/Java/.NET process it manages itself — no separate driver binary to version-match.

Test code → Playwright driver process → WebSocket (CDP/BiDi) → Browser

Because Playwright owns the browser process lifecycle and has a live protocol connection, it can subscribe to actual browser events — network idle, DOM mutations, frame navigation — instead of polling. This is the real source of Playwright's "less flaky" reputation: auto-waiting is a byproduct of architecture, not a feature someone bolted on.

Auto-waiting vs. explicit waiting

This is the single biggest day-to-day productivity difference.

Selenium requires you to explicitly wait for actionability:

WebElement button = new WebDriverWait(driver, Duration.ofSeconds(10))
    .until(ExpectedConditions.elementToBeClickable(By.id("submit")));
button.click();

Skip this and you get intermittent ElementClickInterceptedException or StaleElementReferenceException — not because your test is wrong, but because Selenium clicked before the element was interactable (covered by an overlay, animating, or detached and re-rendered by a framework).

Playwright bakes actionability checks into every action — visible, stable (not animating), receives events (not obscured), enabled — before it acts:

await page.getByRole('button', { name: 'Submit' }).click();

If the element isn't actionable within the timeout, Playwright throws a specific error telling you which check failed, not a generic "element not found." That diagnostic quality alone cuts triage time significantly on a large suite.

Where this cuts the other way: auto-waiting can mask genuine race conditions in your app. A button that becomes clickable a beat before its handler is actually wired up will pass Playwright's actionability check and still fail intermittently — the failure just moves from "test infra" to "app timing bug," which is more honest but not free.

Locator strategy

Selenium's By locators (id, cssSelector, xpath) return a reference to whatever matched at that instant. If the DOM re-renders (React/Vue re-mount), that reference goes stale and you eat a StaleElementReferenceException on the next interaction.

Playwright's Locator is lazy — it re-resolves the query on every action, so it survives re-renders by design:

const row = page.getByRole('row', { name: 'jane@example.com' });
await row.getByRole('button', { name: 'Delete' }).click();

Playwright also pushes role/text-based locators (getByRole, getByLabel, getByTestId) as the default idiom, which happens to align with accessible markup — a genuine secondary benefit, not just API sugar.

Shadow DOM is the other place this matters in practice. Playwright pierces open shadow roots automatically — page.locator('my-component >> text=Save') just works. Selenium requires you to explicitly traverse into shadowRoot (and behavior varies by driver/browser version), which is a recurring source of custom helper methods in mature Selenium frameworks.

Network interception, mocking, and API testing

Selenium has no native network layer. Selenium 4 exposes some Chrome DevTools Protocol access, but intercepting and rewriting requests still typically means bolting on a proxy like BrowserMob, or dropping to raw CDP calls that aren't part of the stable WebDriver API. API testing is a separate concern entirely — you bring in REST Assured (Java), requests (Python), or similar, wired up alongside your UI framework rather than inside it.

Playwright treats both as first-class:

// Mock a flaky third-party dependency (payment gateway, OTP provider) directly in the test
await page.route('**/api/payment/authorize', (route) =>
  route.fulfill({ status: 200, body: JSON.stringify({ status: 'approved' }) })
);

// Drive API calls in the same test, no separate HTTP client
const api = await request.newContext();
const response = await api.post('/api/orders', { data: { sku: 'ABC-123', qty: 1 } });
expect(response.status()).toBe(201);

That means you can seed state via API, then assert through the UI, in one test file with one runner — no context-switching between an HTTP client library and your browser automation stack. For flows gated behind a third-party dependency (payment, OTP, SSO), page.route() mocking is often the only practical way to test the failure paths deterministically.

Authentication state reuse

Logging in through the UI once per test is one of the biggest sources of wasted CI time in both tools, but Playwright makes the fix a one-liner. Authenticate once, persist the session, and reuse it across every test that doesn't specifically need to test login itself:

// global-setup.ts — runs once
const page = await browser.newPage();
await page.goto('/login');
await page.getByLabel('Email').fill('user@example.com');
await page.getByLabel('Password').fill('••••••••');
await page.getByRole('button', { name: 'Sign in' }).click();
await page.context().storageState({ path: 'auth.json' });

// playwright.config.ts
use: { storageState: 'auth.json' }

Every subsequent test starts already authenticated — no repeated login flow eating seconds per test across a suite that might run thousands of times a month. Selenium has no equivalent primitive; teams typically replicate this by injecting cookies or local storage manually after driver init, which works but isn't built in and isn't as robust across auth schemes (e.g. anything involving httpOnly or SameSite cookie nuances).

Parallelism and execution model

Selenium Grid (v4) distributes across nodes, but each session is a full browser instance with its own driver process — heavy to spin up, and coordination overhead (hub/router, session queuing) grows with grid size. It's proven at scale, but the ops burden is real: someone owns the Grid infrastructure.

Playwright ships parallelism as a first-class runner feature (playwright.config.ts workers), and browser contexts are cheap — isolated, cookie/storage-separated sessions within a single browser process launch. You get Selenium-Grid-like isolation without spinning up a new browser per test:

export default defineConfig({
  workers: process.env.CI ? 4 : undefined,
  fullyParallel: true,
});

For a suite of a few hundred E2E tests, Playwright's context-based parallelism is materially cheaper in CI compute than an equivalent Selenium Grid setup — fewer browser process cold-starts per test.

The same context model simplifies multi-tab and popup flows — OAuth redirects, "open in new tab" links, payment provider popups — which are a genuine pain point in Selenium:

// Selenium: manual window-handle juggling
const originalWindow = await driver.getWindowHandle();
const windows = await driver.getAllWindowHandles();
for (const handle of windows) {
  if (handle !== originalWindow) await driver.switchTo().window(handle);
}

// Playwright: the new page is just an object
const [popup] = await Promise.all([
  page.waitForEvent('popup'),
  page.getByRole('link', { name: 'Pay with PayPal' }).click(),
]);
await popup.getByLabel('Email').fill('user@example.com');

Cross-browser and real-device coverage

This is where Selenium still wins outright.

Selenium drives real installed browsers via vendor-maintained drivers — actual Chrome, actual Firefox, actual Safari, actual legacy Edge if you're unlucky enough to need it. It's the only realistic path to real mobile browser testing through Appium (which reuses the WebDriver protocol) or cloud grids like BrowserStack/Sauce Labs for genuine device/OS/browser matrices.
Playwright ships its own bundled builds of Chromium, Firefox, and WebKit. "WebKit" here is not Safari — it's a Playwright-patched WebKit build, which is a very good proxy for Safari behavior but has occasionally diverged from real Safari edge cases (especially around media APIs, permissions prompts, and some CSS rendering). If your product has a Safari-specific bug class (and most do, eventually), you cannot fully rule it out with Playwright's WebKit alone.
Playwright has no first-party mobile device automation — page.emulate gives you viewport/UA emulation of a desktop browser pretending to be mobile, not a real mobile browser engine.
Selenium is also the only option for legacy corporate environments still running Internet Explorer or older Edge builds via vendor drivers. Playwright never supported them and never will — it targets evergreen browsers only.

Verdict: if your test matrix must include "real Safari on real macOS" or "real Chrome on a real Android device," you still need Selenium/Appium or a cloud grid in the loop, full stop — Playwright is not a substitute there.

Debuggability

This isn't close. Playwright's tooling — Trace Viewer (full DOM snapshots, network, console, and a timeline scrubber per test run), the Inspector, --debug step mode, and codegen — gives you a post-mortem of a CI failure that looks like a time-travel debugger. Selenium has nothing built-in comparable; you're left instrumenting screenshots-on-failure and video capture yourself (or paying for a cloud grid that bolts this on).

npx playwright test --trace on
npx playwright show-trace trace.zip

For a team fighting flaky-test triage time, Trace Viewer alone can be the deciding factor, independent of everything else in this comparison.

Screenshots, video, and reporting

Playwright bundles page.screenshot() and locator.screenshot() with built-in masking and clipping, plus recordVideo on the browser context — no extra dependency. Getting the same artifacts out of Selenium means wiring up FFmpeg, a Grid video-recording sidecar, or a paid cloud grid that adds it for you.

Reporting follows the same pattern. Playwright's HTML reporter ships with traces, videos, and screenshots attached out of the box; you can still layer Allure on top if that's your org's standard. Selenium has no built-in report format — ExtentReports, Allure, and ReportPortal are the de facto standard, but they're all separate dependencies you own the versioning and configuration for. Neither gap is fatal, but it's real setup and maintenance surface Playwright starts you without.

Language and ecosystem maturity

Selenium: bindings in Java, Python, C#, Ruby, JavaScript, Kotlin — genuinely first-class in each, backed by 15+ years of Stack Overflow answers, Page Object frameworks (Serenity, Selenide), and enterprise QA tooling that assumes WebDriver underneath (most commercial test-management and visual-regression tools integrate with Selenium by default).
Playwright: first-class in TypeScript/JavaScript, Python, .NET, and Java — but the JS/TS experience is where the tool is designed and battle-tested first; other bindings sometimes lag on API parity for newly released features. If your org is Java-first with a large existing Selenium/TestNG investment, migrating fully is a bigger lift than the marketing suggests.

When to actually choose which

Choose Playwright when:

You're starting a new E2E suite and the target is modern web apps (React/Vue/Angular) in Chromium/Firefox/WebKit-class browsers
CI cost and flakiness triage time are real pain points
Your team is JS/TS-native or Python-native
You want network interception/mocking and API testing as native features (page.route(), APIRequestContext), not a Selenium-plus-BrowserMob-plus-REST-Assured bolt-on
Login flows dominate your suite's runtime and storageState reuse would meaningfully cut CI time

Choose Selenium when:

You need real Safari, real mobile browsers, or a specific legacy browser (including IE/old Edge) in the matrix
You already have a mature Selenium Grid + Page Object investment and the migration cost outweighs the flakiness savings
Your org's commercial test-management/visual-testing tooling is WebDriver-native
You're testing through Appium for native + hybrid mobile apps, where WebDriver is the shared protocol

Conclusion

The honest framing: Playwright's architecture eliminates an entire category of flakiness that Selenium engineers have spent a decade building workarounds for, and its debugging tooling is a genuine step change. But Selenium's WebDriver protocol is still the only standard that gets you real cross-browser and real-device coverage, and that's not a gap Playwright's bundled-browser model closes. Pick based on what's actually in your browser matrix, not which tool has the better changelog.

Key Takeaways

Selenium drives real browsers out-of-process via WebDriver; Playwright drives its own bundled browser builds in-process via CDP/BiDi — this single difference explains almost every other trade-off
Playwright's auto-waiting is an architectural byproduct, not a convenience feature, and materially reduces flaky-test triage time
Selenium remains the only realistic choice for real Safari and real mobile-device coverage; Playwright's WebKit is a very good but imperfect Safari proxy
Playwright's Trace Viewer has no real Selenium equivalent and is often the deciding factor on its own
Native API testing (APIRequestContext) and storageState auth reuse let Playwright seed state and skip repeated logins without a separate HTTP client — a real CI-time win at scale
Don't migrate a mature Selenium Grid investment to Playwright purely for speed — check your browser/device matrix requirements first

K6 Performance Testing for APIs – Quick Start Guide

Tue, 16 Dec 2025 00:00:00 GMT

Introduction

Performance testing is no longer optional for modern APIs. Even a perfectly functional API can fail under load if performance is not validated early.

K6 is a modern, open-source performance testing tool designed for developers, QA engineers, and DevOps teams. It allows you to write readable performance tests using JavaScript and run them locally or in CI/CD pipelines.

What is K6 and When Should You Use It

K6 is best suited for:

REST and GraphQL API performance testing
Load testing microservices
Stress and spike testing
CI/CD performance gates
Pre-production validation

Core Performance Testing Concepts

| Term | Meaning | |-----|--------| | Virtual User (VU) | Simulated user executing your test | | Iteration | One full execution of the test function | | Load Test | Expected production traffic | | Stress Test | Gradually increasing load to find limits | | Spike Test | Sudden traffic increase | | Threshold | SLA or pass/fail condition |

Step 1: Install k6

macOS

brew install k6

Windows

choco install k6

Linux (Debian / Ubuntu)

sudo apt update
sudo apt install k6

Docker (CI/CD Friendly)

docker pull grafana/k6

Verify installation:

k6 version

Step 3: Your First K6 API Test

Create api-test.js:

import http from 'k6/http'
import { check, sleep } from 'k6'

export const options = {
  vus: 10,
  duration: '30s',
}

export default function () {
  const response = http.get('https://jsonplaceholder.typicode.com/posts')

  check(response, {
    'status is 200': (r) => r.status === 200,
    'response time < 500ms': (r) => r.timings.duration < 500,
  })

  sleep(1)
}

What this test does

Runs 10 virtual users
Executes for 30 seconds
Sends HTTP GET requests
Validates response status and performance

Step 4: Running the Test

k6 run tests/api-test.js

K6 will immediately start printing live metrics to the terminal.

Step 5: Understanding K6 Output

Key Metrics to Watch

| Metric | What It Tells You | |------|------------------| | http_req_duration | End-to-end request latency | | http_req_failed | Percentage of failed requests | | vus | Number of active virtual users | | iterations | Total test executions | | checks | Assertion success rate |

Focus First On

Load Testing Example

export const options = {
  vus: 50,
  duration: '2m',
}

Use this to simulate normal expected traffic.

Stress Testing Example

export const options = {
  stages: [
    { duration: '1m', target: 20 },
    { duration: '1m', target: 50 },
    { duration: '1m', target: 100 },
    { duration: '1m', target: 0 },
  ],
}

Use this to identify:

Performance degradation
Breaking points
Resource bottlenecks

API Testing with Headers and Auth

const params = {
  headers: {
    Authorization: 'Bearer YOUR_TOKEN',
    'Content-Type': 'application/json',
  },
}

http.get('https://api.example.com/users', params)

Step 6: Adding Thresholds (SLAs)

Thresholds fail the test when SLAs are violated.

export const options = {
  thresholds: {
    http_req_duration: ['p(95)<500'],
    http_req_failed: ['rate<0.01'],
  },
}

Perfect for CI/CD pipelines.

CI/CD Usage (Quick Example)

k6 run tests/api-test.js --summary-export=summary.json

Pipeline can fail if thresholds are breached.

Best Practices

Start small, scale gradually
Keep tests deterministic
Version control test scripts
Avoid testing from unstable networks
Always define thresholds

When NOT to Use K6

UI/browser testing
Visual performance testing
End-to-end user journey validation

Conclusion

K6 enables teams to shift performance testing left and catch issues early.
With minimal setup and readable scripts, it becomes a powerful part of your DevTools ecosystem.

Key Takeaways

K6 is lightweight and developer-friendly
Ideal for API and microservice testing
Easy CI/CD integration
Clear metrics and strong automation support

How to Install and Configure NGINX Server on CentOS

Tue, 09 Dec 2025 00:00:00 GMT

🚀 How to Install and Configure NGINX on CentOS

NGINX is one of the most popular web servers in the world. It's fast, lightweight, and easy to configure — perfect for hosting websites, APIs, or static content.

In this guide, you’ll learn how to install NGINX on CentOS, start the service, configure a basic website, and verify the installation.

Step 1: Update Your System

sudo yum update -y

Step 2: Install NGINX

sudo yum install nginx -y
sudo systemctl start nginx
sudo systemctl enable nginx
sudo systemctl status nginx

Step 3: Allow NGINX in the Firewall

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

Step 4: Verify NGINX is Running

Visit:

http://<your-server-ip>

You should see the NGINX welcome page.

Step 5: Hosting Your First Web Page

Default NGINX web root:

/usr/share/nginx/html

Edit:

sudo nano /usr/share/nginx/html/index.html

Example:

<h1>Hello from NGINX on CentOS!</h1>

Step 6: Basic Custom NGINX Configuration

Create:

sudo nano /etc/nginx/conf.d/mywebsite.conf

Add:

server {
    listen 80;
    server_name example.com;
    root /var/www/mywebsite;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Reload:

sudo nginx -t
sudo systemctl reload nginx

🎉 Done!

You've successfully installed and configured NGINX on CentOS.

MySQL Master-Slave Replication for Data Redundancy

Sat, 22 Mar 2025 00:00:00 GMT

Introduction

In production environments, data redundancy and high availability are critical requirements. MySQL master-slave replication is a proven solution that ensures your data is safely replicated across multiple servers.

This guide will walk you through setting up MySQL master-slave replication step by step.

What is MySQL Replication?

MySQL replication enables data from one MySQL database server (the master) to be copied to one or more MySQL database servers (the slaves). Replication is asynchronous by default; slaves do not need to be connected permanently to receive updates from the master.

Benefits of Replication

Data Redundancy: Keep multiple copies of your data
Load Distribution: Distribute read queries across multiple slaves
Backup Solution: Use slaves for backups without locking the master
Disaster Recovery: Quick failover to slave in case of master failure

Prerequisites

Before we begin, make sure you have:

MySQL 8.0 or higher installed on both servers
Root access to both servers
Network connectivity between servers
Basic understanding of MySQL

Step 1: Configure Master Server

First, edit the MySQL configuration file on the master server:

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

Add the following lines:

[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_do_db = production_db

Important Configuration Parameters:

server-id: Unique identifier for the server (must be unique across all servers)
log_bin: Enable binary logging
binlog_do_db: Specify which database to replicate

Restart MySQL after making changes:

sudo systemctl restart mysql

Step 2: Create Replication User

On the master server, create a dedicated replication user:

CREATE USER 'replica'@'%' IDENTIFIED BY 'strong_password_here';
GRANT REPLICATION SLAVE ON *.* TO 'replica'@'%';
FLUSH PRIVILEGES;

Step 3: Get Master Status

Lock the database and note the master status:

FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

You'll see output like:

+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 | 154      | production_db|                  |
+------------------+----------+--------------+------------------+

Important: Note the File and Position values - you'll need them for slave configuration.

Step 4: Export Data from Master

If you have existing data, export it:

mysqldump -u root -p --databases production_db > master_backup.sql

After the export completes, unlock the tables:

UNLOCK TABLES;

Step 5: Configure Slave Server

Edit the MySQL configuration on the slave server:

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

Add these lines:

[mysqld]
server-id = 2
relay-log = /var/log/mysql/mysql-relay-bin.log
log_bin = /var/log/mysql/mysql-bin.log
binlog_do_db = production_db

Restart MySQL:

sudo systemctl restart mysql

Step 6: Import Data to Slave

If you exported data from master:

mysql -u root -p < master_backup.sql

Step 7: Start Replication

On the slave server, configure the master connection:

CHANGE MASTER TO
  MASTER_HOST='master_ip_address',
  MASTER_USER='replica',
  MASTER_PASSWORD='strong_password_here',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=154;

Start the slave:

START SLAVE;

Step 8: Verify Replication

Check the slave status:

SHOW SLAVE STATUS\G

Look for these indicators of successful replication:

Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0 (or a small number)

Testing Replication

Create a test table on the master:

USE production_db;
CREATE TABLE test_replication (
    id INT PRIMARY KEY,
    message VARCHAR(100)
);

INSERT INTO test_replication VALUES (1, 'Replication is working!');

Check the slave:

USE production_db;
SELECT * FROM test_replication;

If you see the data, congratulations! Replication is working.

Monitoring and Maintenance

Key Metrics to Monitor

Replication Lag: Seconds_Behind_Master
Slave Status: Both IO and SQL threads should be running
Binary Log Size: Monitor disk space usage
Connection Status: Ensure slave can reach master

Common Issues and Solutions

Issue: Slave_IO_Running: No

Check network connectivity
Verify replication user credentials
Check firewall rules

Issue: Replication Lag

Check slave server resources (CPU, memory, disk I/O)
Consider using semi-synchronous replication
Review long-running queries

Best Practices

Use Dedicated Replication User: Don't use root for replication
Monitor Regularly: Set up alerts for replication issues
Test Failover: Regularly test your failover procedures
Secure Connections: Use SSL for replication traffic
Backup Binary Logs: Keep backups of binary logs
Document Configuration: Maintain documentation of your setup

Conclusion

You now have a working MySQL master-slave replication setup! This configuration provides data redundancy and can help with read load distribution.

Next Steps

Set up monitoring using tools like MySQL Workbench or Prometheus
Implement automatic failover with MySQL Router or ProxySQL
Consider setting up semi-synchronous replication for better durability
Explore multi-source replication for complex scenarios

Additional Resources

Happy replicating! 🚀

Java Spring Boot Docker Deployment with Oracle Made Simple

Wed, 19 Mar 2025 00:00:00 GMT

Introduction

In today’s DevOps-driven world, containerization has become a crucial aspect of deploying applications efficiently. Docker enables developers to package applications along with their dependencies, ensuring seamless deployment across different environments.

In this blog, we will walk through the step-by-step process of deploying a Java Spring Boot application on Docker with Oracle Database, including how to tackle the challenge of downloading the OJDBC driver, which is not available through Maven.

Why Use Docker for Java Spring Boot Applications?

Consistency: Ensures the application runs the same way across different environments.
Scalability: Containers can be easily scaled using tools like Kubernetes.
Isolation: Each application runs in an isolated environment, avoiding dependency conflicts.
Efficiency: Docker containers are lightweight and resource-efficient compared to VMs.

Prerequisites:

Before getting started, ensure you have the following installed:

Java JDK 17+
Spring Boot Application (Maven/Gradle)
Docker (Installed and running)
Oracle Database (Running in Docker or accessible remotely)
OJDBC Jar (Manually downloaded from Oracle website)
Basic knowledge of Docker and Spring Boot

Step 1: Create a Simple Spring Boot Application

If you already have a Spring Boot project, skip this step. Otherwise, create a new one using Spring Initializr:

curl https://start.spring.io/starter.zip -d dependencies=web -o demo.zip
unzip demo.zip -d demo
cd demo

Ensure your pom.xml has the following dependencies:

<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-strarter-web<artifactId>
</dependency>

Create a simple REST controller in /src/main/java/com/example/demo/HelloController.java

@RestController
@RequestMapping(“/api”)
Public class HelloController {

	@GetMapping(“helloWorld”)
	public String sayHello() {
		return “”Hello, Dockerized Spring Boot Application!”;
	}

}

Now, build the application:

mvn clean package -DskipTests

Step 2: Download and Add the Oracle JDBC Driver

Since Oracle’s JDBC driver is not available in public Maven repositories, you must download it manually from Oracle JDBC Downloads page.

Once downloaded, add it to your local Maven repository:

mvn install:install \
	-Dfile=ojdbc8.jar \
	-DgroupId=com.oracle \
	-DartifactId=ojdbc8 \
	-Dversion=21.9.0.0 \
	-Dpackaging=jar

Then, include the dependency in your pom.xml:

<dependency>
	<groupId>com.oracle</groupId>
	<artifactId>ojdbc8</artifactId>
	<version>21.9.0.0</version>
</dependency>

Step 3: Create a Dockerfile

A Dockerfile defines the environment needed to run your application. Create a Dockerfile in the project root:

# Use an official OpenJDK runtime as base image
FROM openjdk:17-jdk-slim

# Set working directory in container
WORKDIR /app

# Copy JAR file into the container
COPY target/demo-0.0.1-SNAPSHOT.jar app.jar 

# Expose the port the app runs on
EXPOSE 8080

# Run the application
CMD [“java”, “”-jar, “app.jar”]

Step 4: Build and Run the Docker Container

Now, build your Docker image:

Docker build -t my-spring-app .

Run the container:

Docker run -d -p 8080:8080 —name spring-app my-spring-app

Verify that the application is running by opening your browser and visiting:

http://localhost:8080/api/hello

Step 5: Run Oracle Database in a Docker Container

To run an Oracle Database instance in Docker, use:

Docker run -d —name oracle-test \
	-p 1521:1521 \
	-e ORACLE_SID=ORCL \
	-e ORACLE_PBD=ORCLPDB1 \
	-e ORACLE_PWD=admin123 \
	container-registry.oracle.com/database/enterprise:latest

Update your application.properties file:

spring.datasource.url=jdbc:oracle:thin:@//oracle-db:1521/ORCLPDB1
spring.datasource.username=system
spring.datasource.password=admin123
spring.datasource.driver-class-name=oracle.jdbc.OracleDriver

Ensure both services are running on the same Docker network:

docker network create mynetwork
docker network connect mynetwork spring-app
docker network connect mynetwork oracle-db

Conclusion

By following this guide, you have successfully Dockerized a Java Spring Boot application, connected it to an Oracle database using Docker, and resolved the OJDBC download challenge.

Key Takeaways

Docker ensures portability and scalability for Java applications.
Using Docker Compose simplifies multi-container deployment.
Overcoming OJDBC driver challenges is possible with manual integration.

Oracle XE In Docker On Windows: An Ultimate Guide

Wed, 25 Dec 2024 00:00:00 GMT

Setting up Oracle XE in your local development environment can significantly speed up application development by giving you a powerful relational database to work with. This guide provides a straightforward approach to setting up Oracle XE using Docker on a Windows system, followed by creating a schema to start your development journey.

Why Use Oracle XE with Docker for Local Development?

Oracle XE is a lightweight, free version of Oracle Database that caters to the needs of developers and small-scale applications. Running it in Docker adds the benefit of containerization, allowing:

Easy setup and cleanup.
Isolation from your host environment.
Seamless portability across systems.

Prerequisites

Before we dive into the setup, ensure you have the following installed on your Windows machine:

Docker Desktop: Download and install Docker.
Windows Subsystem for Linux (WSL): Enable WSL if not already configured.

Containerize An Oracle Database

Step 1: Pull the Oracle XE Docker Image

The first step is to pull the Oracle XE Docker image from Oracle’s repository or Docker Hub. Open a terminal and run:

docker pull container-registry.oracle.com/database/express:21.3.0-xe

This command downloads the Oracle XE 21c image to your local system.

Step 2: Run the Oracle XE Container

Create and run a Docker container using the image you just pulled. Execute the following command:

docker container create `
   -it ` # Run the container in interactive mode
   --name [container-name] `  # Name of the container
   -p [host-port]:1521 `  # Map the port from host to container for DB
   -e ORACLE_PWD=[custom-pass] `  # Password for default user
   container-registry.oracle.com/database/express:[version]  # Image

Explanation:

--name oracle-xe-container: Names your container for easier reference.
-p 1521:1521: Maps the database’s port to your local machine.
-e ORACLE_PWD=your_password_here: Sets the password for the default SYS and SYSTEM users.

After running the command, Oracle XE will initialize inside the container. It may take a few minutes to start up.

Step 3: Verify the Container is Running

To ensure the Oracle XE container is up and running, execute:

docker ps

Look for a container named oracle-xe-container in the list. If it’s not running, check the logs for any issues:

docker logs oracle-xe-container

Step 4: Connect to the Oracle XE Database

You can connect to Oracle XE using any database client, such as SQL*Plus or Oracle SQL Developer. Use the following connection details:

Host: localhost
Port: 1521
Service Name: XEPDB1
Username: SYS
Password: The password you set with ORACLE_PWD
Role: SYSDBA

Oracle XE database container should be up and running now. Once the database is accessible, we need to create schema.

Create an Oracle XE Schema

Step 1: Access the Oracle Database Container

First, connect to the running container:

docker exec -it <container_name_or_id> bash

Step 2: Log in to SQL*Plus

Inside the container, use the sqlplus utility to log in as the default database user (e.g., SYS or SYSTEM):

sqlplus SYS/<password>@localhost/XEPDB1 as sysdba

Replace <password> with the SYS password you provided when running the container. XEPDB1 is the default pluggable database name for Oracle XE.

Step 3: Create a New User (Schema)

A schema in Oracle is effectively a user. To create one:

CREATE USER your_schema_name IDENTIFIED BY your_password;

Step 4: Grant Privileges to the User

To allow the user to connect to the database and create objects:

GRANT CONNECT, RESOURCE TO your_schema_name;

Optionally, you can grant additional privileges as needed, such as:

GRANT DBA TO your_schema_name;

Step 5: Connect to the New Schema

Exit SQL*Plus by typing exit, and log back in as the new user:

sqlplus your_schema_name/your_password@localhost/XEPDB1

Step 6: Test the Schema

You can now create tables and other objects in the new schema:

CREATE TABLE Test (
    id NUMBER PRIMARY KEY,
    name VARCHAR2(100)
);

Instrument JaCoCo Code Coverage agent with WebLogic

Sat, 18 May 2024 00:00:00 GMT

JaCoCo is an open-source library created by the EclEmma team for measuring and reporting code coverage in an application. It is quite popular among the variety of code coverage libraries for Java out there. If you wish to setup JaCoCo with Maven, you can go through my previous blog which provides a detailed Guide to setup JacoCo Code Coverage Tool with Maven.

In this blog, we will be talking about how to set up a JaCoCo agent on the WebLogic server. To get started, we have a sample License Eligibility Checker application.

Sample Application

For demonstration, we are going to use a simple License Eligibility Checker application consisting of a UI that prints if the user is eligible for a license or not based on the provided age.

Integrating Jacoco Agent with WebLogic Server

JaCoCo uses class file instrumentation to record the coverage data against the test execution. Class files are instrumented on the fly using a so-called Java agent. When a Java agent is attached to the JVM, the agent can see when the class file is called and what lines are executed.

Download the latest JaCoCo distribution from JaCoCo’s official website

https://www.eclemma.org/jacoco/index.html

Extract the JaCoCo Distribution file

Once downloaded, extract the downloaded JaCoCo distribution zip file. You will be able to see multiple JAR’s in the lib folder inside the extracted distribution, which we will be needing in further steps.

Move the JaCoCo distribution under WebLogic

Create a new directory inside <WEBLOGIC_HOME>/user_projects/domains/<DOMAIN_DIRECTORY>/ named jacoco. Copy the jacocoagent.jar, jacocoant.jar, and jacococli.jar inside the newly-created directory.

Please Note - Creating the jacoco directory inside the above provided path is not mandatory. You can create the directory anywhere according to your convivence. I generally prefer the above path for better maintenance.

Attach JaCoCo Agent to JVM

We now need to attach the JaCoCo agent with WebLogic JVM. To attach the JaCoCo agent, add the below argument to setDomainEnv.sh (For Linux) / setDomainEnv.cmd (For Windows) file available inside <WEBLOGIC_HOME>/user_projects/domains/<DOMAIN_DIRECTORY>/bin/ directory.

set JAVA_OPTIONS=-javaagent:PATH_TO_JACOCO_AGENT_JAR/jacocoagent.jar=destfile=PATH_TO_GENERATE_JACOCO_EXEC_FILE/jacoco.exec,output=file,append=false

JaCoCo agent is successfully attached to JVM now. When we start the WebLogic server, there should be a jacoco.exec file generated at the provided destination file path.

Please Note – The size of jacoco.exec file is zero initially. On successful WebLogic server shutdown, the Jacoco agent appends the coverage data to an already created binary file.

Convert JaCoCo Binary to HTML report

The Java agent generates a Binary file that is not human readable. The file cannot be singlehandedly interpreted. In order to convert the generated binary file (jacoco.exec) we will utilize jacococli.jar. In order to generate the HTML report, perform the following steps:

Step 1 – Create a new directory inside the jacoco directory which we previously created with name ‘reports’. We will utilize this folder to generate the HTML report.

Step 2 – Execute the following jacococli.jar with parameters:

java -jar PATH_TO_JACOCO_DIRECTORY/jacococli.jar report jacoco.exec --classfiles PATH_TO_APPLICATION_CLASS_FILES --html PATH_TO_HTML_REPORT_DIRECTORY

JaCoCo Code Coverage Setup with Maven

Sat, 11 May 2024 00:00:00 GMT

In this blog, we will be talking about how to set up JaCoCo with Maven Project. To understand JaCoCo’s code coverage capabilities, we need to have a code sample.

Sample Maven Project

Here, we are going to use a simple class named ‘LicensingService’ consisting of a simple Java Function that prints if the user is eligible for a license or not based on the provided age and ‘LicensingServiceTest’ consisting of Unit Tests.

public class LicensingService {

    public void eligibilityChecker(int age) {
         System.out.println("User Provided Age: " + age);
         if (age >= 18) {
              System.out.println("You are eligible to apply for license");     
         } else {
              System.out.println("Sorry, you are not eligible to apply for license");     
        }
    }

}

Now, we need to add JUnit Tests against which the coverage will be generated.

public class LicensingServiceTest {

     @Test
     public void licenseEligibilityChecker() {
          LicensingService licensingService = new LicensingService();
          licensingService.eligibilityChecker(18);
     }

}

Configuring Jacoco Maven Plugin

Now to configure Jacoco with the project, we need to declare this maven plugin in our pom.xml file:

<build>
    <plugins>
        <plugin>
            <groupId>org.jacoco</groupId>
            <artifactId>jacoco-maven-plugin</artifactId>
            <executions>
                <execution>
                    <goals>
                        <goal>prepare-agent</goal>
                    </goals>
                </execution>
                <execution>
                    <id>report</id>
                    <phase>prepare-package</phase>
                    <goals>
                        <goal>report</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

The JaCoCo Java agent will collect coverage information when maven-surefire-plugin runs the tests. It will write it to target/jacoco.exec by default. Read more.

Executing the Tests and Creating the Coverage Reports

Execute the Tests using mvn clean test

On execution of tests, Jacoco agent will automatically instrument to the code, thus, it will create a coverage report in binary format in the target directory – target/jacoco.exec.

The generated report can further be interpreted through two different ways.

Display Interactive Report in IntelliJ
Interpret Binary Report to HTML format

1. Display Interactive Report in IntelliJ

IntelliJ provides an interactive coverage interface that can be utilized to analyze line-by-line coverage of complete code. The jacoco.exec binary file generated after the execution of tests can simply be accessed in the IntelliJ Coverage window using the below steps.

Step 1 – Click on Run -> Show Coverage Data. [Shortcut : Ctrl + Alt + F6]

A new Coverage Suite Dialog box will appear.

Step 2 – Click on (+) add button in the Coverage Suite Dialog box. Select the jacoco.exec binary file and click Show Selected.

You will now be able to view the line-by-line coverage.

2. Interpret Binary Report to HTML format

The generated jacoco.exec can be interpreted to the HTML, CSV, XML Report format which is human readable. To achieve this, we can simply run the below maven command.

bash mvn jacoco:report

Please Note: This step can be completely avoided by adding the above goal during the test execution itself.

Example: mvn clean test jacoco:report

We can now take a look at the target/site/jacoco/index.html page to see what the generated report looks like.

Automate MySQL Database Backups on Linux

Tue, 30 Apr 2024 00:00:00 GMT

Ensuring the safety and security of your MySQL databases is crucial for any business. Regular MySQL database backups are a key component of a solid data protection strategy. In this blog, I’ll show you how to automate MySQL database backups on Linux using a simple shell script.

STEP 1: Create a Backup Shell Script

First, create a new shell script named mysql_backup_script.sh and add the following content:

#!/bin/bash

# MySQL database credentials
DB_USER="<DB_USER>"
DB_PASS="<DB_PASSWORD>"
DB_NAME="<DB_NAME>"

# Backup directory
BACKUP_DIR="<path/to/backup/directory>"

# Backup file name
BACKUP_FILE="$BACKUP_DIR/$DB_NAME-$(date +%Y%m%d%H%M%S).sql"

# Dump the MySQL database
mysqldump --user=$DB_USER --password=$DB_PASS $DB_NAME > $BACKUP_FILE

# Optional: Compress the backup file
# gzip $BACKUP_FILE

Replace <DB_USER>, <DB_PASSWORD>, <DB_NAME>, and <path/to/backup/directory> with your actual MySQL credentials, database name, and backup directory path.

Step 2: Configure executable permissions for the script

Add the executable permissions to the script file by running:

chmod +x mysql_backup.sh

Step 3: Schedule the MySQL database Backups

Schedule the backup script to run automatically on a specified time using cron. Open your crontab file by running:

crontab -e

Add the following line to schedule the backup to run daily at midnight:

0 0 * * * /path/to/mysql_backup_script.sh

Replace /path/to/mysql_backup_script.sh with the actual path to your backup script.

You can utilize the following reference, if you wish to configure different schedule for your backup.

How to download maven dependencies behind organization proxy

Wed, 10 Apr 2024 00:00:00 GMT

Introduction

Whether you’re a Software Developer or an Automation Engineer, Maven is a widely used build tool today. One common challenge in some environments is the inability to download Maven dependencies due to organizational proxies. In this article, I’ll share a quick guide on how to download Maven dependencies behind your organization’s proxy.

Proxy Configuration

Let’s understand how to setup proxy configuration. This configuration can be done in settings.xml file.

Open your settings.xml file located in <user_home>/.m2 directory. If the file does not exist, you can create it.
Add the following <proxies> configuration inside the <settings> element, replacing proxy.example.com and 8080 with your server’s hostname and port:

<proxies>
    <proxy>
        <id>example-proxy</id>
        <active>true</active>
        <protocol>http</protocol>
        <host>proxy.example.com</host>
        <port>8080</port>
        <!-- Optional: Proxy username and password -->
        <!--<username>proxy-username</username>-->
        <!--<password>proxy-password</password>-->
        <!--<nonProxyHosts>localhost|127.0.0.1</nonProxyHosts>-->
    </proxy>
</proxies>

If your organization requires authentication, uncomment the <username> and <password> tags and provide your credentials. Additionally, you can specify hosts that should bypass the proxy in the <nonProxyHosts> tag.

Test the Configuration:

To test the proxy configuration, run a Maven command such as mvn clean install for a Maven project. Maven should now be able to download dependencies through the proxy.