All Types of Client Extensions in Liferay 7.4

Introduction

Liferay Client Extensions provide a modern mechanism for extending Liferay DXP without deploying application code directly into the Liferay JVM. Traditionally, Liferay applications frequently relied on:

OSGi modules
MVC Portlets
Service Builder
REST Builder
JSP customizations
Traditional themes

These remain relevant for certain use cases, but they execute inside or are tightly associated with the Liferay runtime. Client Extensions provide a more loosely coupled architecture.

Client Extension ←→ Liferay APIs / Extension Points

Why Client Extensions?

Client Extensions can provide several architectural benefits:

Reduced coupling to Liferay internals
Easier upgrades
Independent technology choices
External microservice integration
Reusable configuration
Modern frontend integration
Better separation of concerns
Independent service scaling
Cloud-friendly deployment

The general principle is:

Extend Liferay̸ = Modify Liferay Core

The Four Major Classifications

Liferay Client Extensions are organized into four major classifications:

Frontend Client Extensions
Configuration Client Extensions
Microservice Client Extensions
Batch Client Extensions

Conceptually:

Diagram

               CLIENT EXTENSIONS
                     |
   +-------------------+-------------------+
   |                 |                |
   v                 v                v
Frontend          Configuration       Microservice
   |
   +---------------------------------------+
                                      |
                                      v
                                    Batch

Another useful way of thinking about them is:

Client Extensions = UI + Configuration + External Logic + Data

Classification Summary

Category	Primary Purpose	Typical Example
Frontend	Change presentation or embed frontend applications	CSS, JavaScript, ment, iFrame	Custom Ele-
Configuration	Deploy reusable Liferay configuration	OAuth configuration, instance settings
Microservice	Execute business logic outside Liferay	Object Action, Workflow Action	Notification,
Batch	Deploy/import structured data entities	Objects, workflows, configuration data

entities tion data

Part I

Frontend Client Extensions

Frontend Client Extensions provide frontend resources that affect Liferay’s presentation layer. They can be used to:

Add CSS
Add JavaScript
Modify theme styling
Change favicons
Embed remote applications
Register web components

Conceptually:

Frontend CX → Presentation Layer

Common frontend types include:

CSS
JavaScript
Theme CSS
Theme Favicon
Custom Element
iFrame

CSS Client Extension

A CSS Client Extension adds custom styling to Liferay pages. For example:

Code

body {
   font-family: Arial, sans-serif;
}

.custom-card {
   border-radius: 12px;
   padding: 20px;
}

Conceptually:

Existing Theme + CSS CX = Customized UI

Typical uses include:

Corporate branding
Typography
Buttons
Navigation styling
Layout enhancements
Component overrides

A conceptual YAML definition is:

YAML

my-custom-css:
   name: My Custom CSS
   type: globalCSS
   url: css/main.css

JavaScript Client Extension

A JavaScript Client Extension can inject custom JavaScript behavior. For example:

Code

console.log("Custom Liferay JavaScript loaded.");

Possible uses include:

Analytics integration
Event listeners
UI behavior
External JavaScript libraries
Custom tracking

Conceptually:

Liferay Page + JavaScript CX → Custom Browser Behavior

Theme CSS Client Extension

Theme CSS Client Extensions provide theme-level CSS resources. They can be used where a more substantial theme-style customization is needed without deploying a traditional Liferay theme. Conceptually:

Diagram

Liferay Theme
    |
    +--> Main CSS
    |
    +--> Clay CSS
    |
    +--> Theme CSS Client Extension

This can reduce the need to maintain a full traditional theme for certain styling requirements.

Theme Favicon Client Extension

A Theme Favicon Client Extension changes the favicon displayed by the browser. For example:

Code

company-logo.svg

becomes the site’s favicon. This is useful when branding multiple Liferay environments or sites.

Custom Element Client Extension

Custom Element Client Extensions are one of the most powerful frontend extension mechanisms. They allow externally developed web applications to be registered as widgets in Liferay. Technologies can include:

React
Angular
Vue
Vanilla JavaScript
Web Components

Architecture:

Diagram

+-------------------------+
| Liferay Page            |
|                      |
| +---------------------+ |
| | Custom Element      | |
| |                  | |
| | React / Angular /   | |
| | Vue / JavaScript    | |
| +---------------------+ |
+-------------------------+

The application remains decoupled from Liferay’s Java runtime. A conceptual custom element may be:

XML / HTML

class QuantumDashboard extends HTMLElement {

   connectedCallback() {

      this.innerHTML =
         "<h2>Quantum Dashboard</h2>";
   }
}

customElements.define(
   "quantum-dashboard",
   QuantumDashboard
);

Liferay can then expose the custom element as a page widget.

iFrame Client Extension

An iFrame Client Extension embeds an externally hosted web application into a Liferay page. Architecture:

Diagram

+----------------------------------+
| Liferay Page                     |
|                              |
| +------------------------------+ |
| | iframe                       | |
| |                          | |
| | https://app.example.com      | |
| |                          | |
| +------------------------------+ |
+----------------------------------+

This is useful when:

An application already exists externally
Tight frontend integration is unnecessary
Strong UI isolation is useful
Migration speed is important

Custom Element vs iFrame

	Custom Element	iFrame
Integration	Closer	More isolated
UI experience	More native	Embedded
CSS interaction	Possible	Isolated
Existing app reuse	Moderate	Very easy
Complexity	Higher	Lower

Part II

Configuration Client Extensions

Configuration Client Extensions allow Liferay configuration to be managed and deployed as code. Conceptually:

Configuration → Version Control → Deployment

Instead of manually repeating configuration across:

Code

Development
Testing
UAT
Production

configuration can be packaged and deployed consistently.

Why Configuration as Code?

Suppose an OAuth application must be configured manually in four environments. Manual configuration can lead to:

Human error
Environment drift
Missing settings
Inconsistent permissions

Configuration Client Extensions provide:

Repeatability + Versioning + Automation

OAuth Configuration Client Extensions

OAuth-related Client Extensions can support authentication and authorization requirements for other extensions. For example:

Diagram

Custom Element
     |
     v
OAuth User Agent
     |
     v
Liferay API

or:

Diagram

Microservice
     |
     v
OAuth Headless Server
     |
     v
Liferay API

OAuth configuration therefore often works together with frontend or microservice Client Extensions.

OAuth User Agent

An OAuth User Agent Client Extension is useful for browser/user oriented authorization scenarios. Conceptually:

User → Frontend CX → OAuth → Liferay API

The authorization context is related to user-triggered activity.

OAuth Headless Server

For service-to-service communication, a headless server OAuth configuration can provide machineoriented access. Conceptually:

External Service → OAuth Token → Liferay Headless API

This is particularly useful for:

FastAPI services
Spring Boot services
Node.js services
Integration middleware
AI/ML backends

Instance Settings Client Extension

Instance Settings Client Extensions can deploy Liferay instance configuration. Conceptually:

Configuration PID + Configuration Values → Liferay Instance

This makes configuration repeatable across environments.

Language Client Extension

In supported newer Liferay releases, Language Client Extensions can add or override language keys. Conceptually:

Properties

welcome.message=Welcome to our portal

could have translations such as:

Diagram

English -> Welcome
French  -> Bienvenue
Hindi   -> Swagat

This can provide language customization without modifying Liferay language bundles directly.

Part III

Microservice Client Extensions

Microservice Client Extensions integrate external backend logic with Liferay.

The external application runs outside the Liferay JVM.

Liferay ←→ External Microservice

The microservice can use technologies such as:

Java / Spring Boot
Python / FastAPI
Node.js
Go
.NET

Microservice Architecture

Diagram

+------------------------+
| Liferay DXP            |
|                     |
| Objects                |
| Workflow               |
| Notifications          |
| Headless APIs          |
+-----------+------------+
           |
           | HTTPS / OAuth 2
           |
           v
+------------------------+
| External Microservice  |
|                     |
| FastAPI / Spring Boot  |
| Node.js / Go / .NET    |
+-----------+------------+
           |
           v
+------------------------+
| DB / AI / External API |
+------------------------+

Object Action Client Extension

An Object Action Client Extension allows an external service to execute business logic in response to a Liferay Object event/action. For example:

Diagram

Order Object Created
       |
       v
Object Action
       |
       v

Diagram

External Microservice
       |
       v
Fraud Check

Another example:

Patient Record → Object Action → AI Diagnostic Service

Possible use cases include:

Validation
External synchronization
AI processing
Payment processing
Notifications
ERP integration

Workflow Action Client Extension

A Workflow Action Client Extension can connect workflow execution to external logic. For example:

Diagram

Workflow
   |
   v
Manager Approval
   |
   v
External Compliance Service
   |
   v
Continue Workflow

This is useful when workflow processing requires functionality that should not run inside Liferay.

Workflow Condition Client Extension

A workflow condition can use external logic to determine the workflow path. For example:

Risk Score < 50 ⇒ Normal Approval

while:

Risk Score ≥ 50 ⇒ Enhanced Review

The risk score itself could be calculated by an external microservice.

Notification Client Extension

A notification-oriented extension can integrate Liferay with an external notification service. Conceptually:

Diagram

Liferay Event
    |
    v
Notification CX
    |
    v
External Notification Service
    |
    +--> Email
    +--> SMS
    +--> Push
    +--> Enterprise Messaging

Custom Microservice

A microservice can also implement specialized business logic. Examples:

AI inference
Quantum simulation
Document processing
Payment processing
ERP integration
CRM integration
Data transformation

For example:

Diagram

Liferay Portal
     |
     v
FastAPI Service
     |
     v
Qiskit / Qulacs
     |
     v
Quantum Result
     |
     v
Liferay

Part IV

Batch Client Extensions

Batch Client Extensions provide data entities to a Liferay instance. Instead of manually creating resources in every environment:

Export → Package → Deploy → Import

can be used. Typical entities can include:

Object definitions
Workflow definitions
Application data
Supported configuration/data entities

Batch Architecture

Diagram

Development Environment
       |
       | Export
       v
Batch Data
       |
       v
Batch Client Extension
       |
       | Deploy
       v
Target Liferay
       |
       v
Imported Entities

Batch Engine Data

A built Batch Client Extension can contain files with names such as:

Code

*.batch-engine-data.json

These are packaged under a batch directory. Conceptually:

Diagram

batch/
|
+-- object-definitions.batch-engine-data.json
|
+-- workflows.batch-engine-data.json

This makes data/configuration transport part of the deployment lifecycle.

When to Use Batch Client Extensions

Batch Client Extensions are useful when:

The same Object definitions are needed across environments
Workflow definitions must be deployed repeatedly
Initial application data must be provisioned
Configuration should be version controlled
Manual environment setup should be minimized

client-extension.yaml

Client Extension projects commonly use:

Code

client-extension.yaml

as their primary source configuration. A single project can conceptually contain multiple extensions:

YAML

company-css:
   name: Company CSS
   type: globalCSS

company-widget:
   name: Company Widget
   type: customElement

company-service:
   name: Company Service
   type: microservice

The actual supported type names and properties depend on the Liferay release.

Liferay Workspace Structure

Client Extension projects normally reside under:

Diagram

liferay-workspace/
|
+-- client-extensions/
|   |
|   +-- company-css/
|   |
|   +-- customer-widget/
|   |
|   +-- payment-service/
|   |
|   +-- application-data/
|
+-- modules/
|
+-- themes/
|
+-- gradle/

This provides a clear separation between traditional modules and modern Client Extensions.

Packaging

Client Extension projects are packaged into deployable archives. A conceptual packaged structure is:

Diagram

client-extension.zip
|
+-- *.client-extension-config.json
|
+-- static/
|
+-- batch/
|
+-- Dockerfile
|
+-- LCP.json
|
+-- microservice resources

The exact contents depend on the Client Extension classification. For example:

Frontend extensions use static resources
Batch extensions contain batch data
Microservice extensions can contain service resources
Configuration extensions primarily provide configuration

LUFFA

Liferay refers to the deployable Client Extension archive as a Liferay Universal File Format Archive, or LUFFA. Conceptually:

Client Extension Source → Build → LUFFA (.zip)

The Liferay Workspace tooling normally handles the packaging process.

Build and Deployment

A typical build command is:

Shell

./gradlew build

On Windows:

Shell

gradlew.bat build

For a specific Client Extension:

Shell

gradlew.bat :client-extensions:my-extension:build

The deployment process varies according to environment and extension type. Conceptually:

Diagram

Source
  |
  v
client-extension.yaml
  |
  v
Gradle Build
  |
  v
LUFFA / ZIP
  |
  v
Liferay Environment

Frontend Packaging

Frontend Client Extensions generally contain static resources. For example:

Diagram

static/
|
+-- css/
|   +-- main.css
|
+-- js/
|   +-- main.js
|
+-- images/
    +-- logo.svg

A frontend container can serve these resources externally to Liferay.

Microservice Packaging

A Microservice Client Extension can require its own Dockerfile because the runtime depends on the selected technology. For example:

Code

FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .

RUN pip install -r requirements.txt

COPY . .

CMD [
   "uvicorn",
   "app.main:app",

Code

   "--host",
   "0.0.0.0",
   "--port",
   "8080"
]

This is fundamentally different from a frontend static-resource container.

OAuth 2 and Client Extensions

Client Extensions frequently need authenticated access to Liferay. The general pattern is:

Client Extension → OAuth 2 → Liferay API

For frontend/user-oriented scenarios:

Diagram

User
 |
 v
Frontend CX
 |
 v
OAuth User Agent
 |
 v
Liferay API

For service-to-service scenarios:

Diagram

Microservice
 |
 v
OAuth Headless Server
 |
 v
Liferay Headless API

Client Extensions vs OSGi Modules

Characteristic	Client Extension	OSGi Module
Runtime	Generally outside core Liferay runtime	Inside Liferay JVM
Coupling	Loose	Potentially tighter
Languages	Technology dependent / flexible	Primarily Java
Communication	APIs and extension points	Java/OSGi APIs
Scaling	Can be independent	Usually tied to Liferay
Upgrade impact	Generally lower	Can require API adaptation
Internal Liferay APIs	Limited	Available depending on API
Cloud suitability	Strong	Depends on deployment model

When Should OSGi Still Be Used?

Client Extensions do not eliminate OSGi. An OSGi module may still be appropriate when the requirement needs:

Deep portal internals
Liferay service overrides
Internal extension points
Java service components
Low-level platform integration
Functionality unavailable through Client Extension APIs

Therefore:

Use Client Extensions when possible

but:

Use OSGi when deep platform integration is required

How to Choose the Right Type

A simple decision model is:

Diagram

What do you need to extend?
       |
       +--> UI / Styling?
       |      |
       |       +--> Frontend CX
       |
       +--> Liferay Configuration?
       |      |
       |       +--> Configuration CX
       |
       +--> External Business Logic?
       |      |
       |       +--> Microservice CX
       |
       +--> Deploy Data / Definitions?
              |
              +--> Batch CX

Or mathematically:


 F  

Frontend, x = presentation

  F  
  F   
 F  C 
  C 
 Configuration,  x = configuration

CX(x) =

M  
  Microservice, x = external logic 
  M  
  M   
 M  B 
  B 

Batch, x = data provisioning

Example Composite Application

A real application may use all four categories simultaneously. Consider an AI Assessment Portal.

Diagram

              LIFERAY DXP
                  |
    +---------------+---------------+
    |             |             |
    v             v             v
Frontend CX     Configuration CX   Batch CX
    |             |             |
    |             |             |
React UI          OAuth Config    Objects/
                               Workflow
    |
    v
Microservice CX
    |
    v
FastAPI
    |
    v
AI Model

The responsibilities are:

Extension	Responsibility
Frontend	React/JavaScript interface
Configuration	OAuth and Liferay configuration
Microservice	AI/business processing
Batch	Objects/workflows/application data

This demonstrates why Client Extensions should be considered an ecosystem rather than isolated features.

Example Quantum Application

For a quantum assessment platform:

Diagram

+-----------------------------------+
| Liferay DXP                       |
|                               |
| User Management                   |
| Objects                           |
| Workflow                          |
| Pages                             |
+----------------+------------------+
               |
       +--------+--------+
       |               |
       v               v

Diagram

Frontend CX        Configuration CX
React UI            OAuth
       |
       v
Microservice CX
       |
       v
FastAPI
       |
   +----+----+
   |       |
   v       v
Qiskit     Qulacs
       |
       v
Quantum Result
       |
       v
Liferay Object

A Batch Client Extension could additionally deploy:

Assessment Object definitions
Question structures
Workflow definitions
Initial configuration data

Security Considerations

Client Extensions should follow standard security practices. Important considerations include:

HTTPS/TLS
OAuth 2
Least privilege
Secure secret storage
Input validation
CORS configuration
Content Security Policy
API authorization
Token expiration
Audit logging

Never place secrets directly in:

Browser JavaScript
Public repositories
CSS
Public configuration

Advantages

The Client Extension model provides several advantages.

Loose Coupling

Extension̸ ⊂ Liferay Core

Technology Freedom

External components can use technologies appropriate to the task.

Independent Scaling

Scale(Liferay)̸ = Scale(Microservice)

Upgrade Resilience

API-oriented integration can reduce dependencies on Liferay implementation details.

Cloud Readiness

Externalized applications and configuration-as-code patterns align well with modern cloud architectures.

Limitations

Client Extensions are not automatically the best solution for every requirement. Potential considerations include:

Network latency
API limitations
Authentication complexity
Distributed debugging
External service availability
Version-dependent capabilities
CORS/security configuration

A deeply internal portal customization may still require OSGi.

Troubleshooting

Client Extension Does Not Appear

Check:

YAML syntax
Extension type
Build output
Deployment logs
Liferay version compatibility

Frontend Resource Not Loaded

Check:

Resource URL
Browser console
Network tab
MIME type
CORS
Content Security Policy

401 Unauthorized

Check:

OAuth client configuration
Access token
Token expiration
Client ID
Client secret

403 Forbidden

Authentication may have succeeded but the identity does not have the required authorization.

Microservice Not Reachable

Check:

Service URL
DNS
Firewall
Container
Port
TLS certificate

Interview Questions and Answers

Multiple Choice Questions

Question 1

How many major Client Extension classifications does Liferay define?

A. Two

B. Three

C. Four

D. Seven

Answer: C

Question 2

Which category is primarily responsible for presentation?

A. Batch

B. Frontend

C. Microservice

D. Configuration

Answer: B

Question 3

Which Client Extension is suitable for a React application rendered as a Liferay widget?

A. Batch

B. Custom Element

C. Object Action

D. Instance Settings

Answer: B

Question 4

Which Client Extension is most suitable for embedding an existing external website?

A. iFrame

B. Batch

C. Theme Favicon

D. OAuth

Answer: A

Question 5

Which category executes specialized business logic externally?

A. Frontend

B. Microservice

C. Batch

D. Theme

Answer: B

Question 6

Which category is useful for deploying Object definitions and workflow definitions?

A. Batch

B. CSS

C. iFrame

D. JavaScript

Answer: A

Question 7

Which file commonly defines a Client Extension project?

A. service.xml

B. portlet.xml

C. client-extension.yaml

D. web.xml

Answer: C

Question 8

Which category can deploy OAuth configuration?

A. Configuration

B. Batch only

C. CSS

D. Theme

Answer: A

Question 9

Where does an external Microservice Client Extension execute?

A. Inside the Liferay JVM

B. Outside the Liferay JVM

C. Inside Elasticsearch

D. Inside the browser only

Answer: B

Question 10

Which technology can be used for an external microservice?

A. FastAPI

B. Spring Boot

C. Node.js

D. All of the above

Answer: D

Question 11

What is a major advantage of Client Extensions?

A. Stronger dependency on Liferay internals

B. Loose coupling

C. All code must be Java

D. They require portal source modification

Answer: B

Question 12

Which extension can be used to add page-level CSS?

A. CSS Client Extension

B. Batch Extension

C. Workflow Extension

D. OAuth Extension

Answer: A

Question 13

What does LUFFA represent?

A. A Liferay database

B. A packaged Client Extension archive

C. A Java servlet

D. A workflow task

Answer: B

Question 14

Which model is suitable for service-to-service Liferay integration?

A. Microservice + OAuth

B. CSS only

C. Theme Favicon

D. JSP only

Answer: A

Question 15

Client Extensions generally communicate with Liferay through:

A. Supported APIs and extension points

B. Direct database modification

C. JVM memory

D. JSP compilation

Answer: A

Quick Revision Table

Client Extension	Primary Purpose
CSS	Add custom CSS styling
JavaScript	Add browser-side JavaScript behavior
Theme CSS	Provide/override theme styling resources
Theme Favicon	Replace site/theme favicon
Custom Element	Embed modern frontend application as a widget
iFrame	Embed externally hosted application
OAuth User Agent	Support user-oriented OAuth authorization
OAuth Headless Server	Support machine/service-oriented API access
Instance Settings	Deploy Liferay instance configuration
Language	Add/override language keys in supported releases
Object Action	Invoke external logic for Object actions
Workflow Action	Invoke external logic from workflow processing
Workflow Condition	Use external logic for workflow routing
Notification	Connect notification processing to external services
Batch	Deploy/import supported data entities

The Big Picture

A modern Liferay application can combine all four categories:

Diagram

                  LIFERAY DXP
                      |
       +----------------+----------------+
       |              |              |
       v              v              v
    FRONTEND        CONFIGURATION       BATCH
       |              |              |
  React / CSS          OAuth          Objects /
  Custom Element     Settings         Workflow
       |
       v
   MICROSERVICE
       |
       v
FastAPI / Spring
       |
       v
  Business Logic

The responsibilities can therefore be separated as:

	Frontend CX = Presentation
Configuration CX = Platform Configuration
Microservice CX = External Business Logic
Batch CX = Data / Definition Provisioning

Together:

Modern Liferay Application = F + C + M + B

where:

F = Frontend

C = Configuration

M = Microservice

B = Batch

Key Takeaway

The easiest way to remember Liferay Client Extensions is:

Need	Choose	Think
Change UI	Frontend	Presentation
Configure Liferay	Configuration	Configuration as Code
Execute external logic	Microservice	Business Logic
Deploy data/definitions	Batch	Provisioning

Therefore:

UI → Frontend CX

Settings → Configuration CX

External Logic → Microservice CX

Data → Batch CX

The important architectural shift is from:

Customization = Code Inside Liferay

toward:

Customization = Loosely Coupled Extensions + Stable APIs

This reduces unnecessary coupling and makes it possible to combine Liferay’s portal, Objects, workflow, identity, permissions, and Headless APIs with modern frontend frameworks and independently deployed backend services.

Version Considerations

Liferay 7.4 has evolved significantly across GA and quarterly releases. Therefore, “Liferay 7.4” should not be treated as a single fixed feature set. Some Client Extension types and capabilities were introduced or enhanced in later 7.4 updates. Before implementing a particular extension, verify:

Exact Liferay DXP quarterly release or Portal GA
Client Extension type availability
Supported YAML properties
OAuth capabilities
Deployment environment
Feature flags where applicable

Official Reference

The official Liferay Client Extensions documentation is available at:

Code

https://learn.liferay.com/w/dxp/development/client-extensions

For exact extension type names and supported properties, also consult the Client Extension Reference corresponding to the target Liferay release.