Liferay 7.4 Client Extensions: Reference Notes

A Client Extension is a mechanism for extending or integrating with Liferay while keeping much of the custom implementation outside the traditional Liferay OSGi runtime. Instead of modifying Liferay internals or deploying all customization logic as OSGi bundles, Client Extensions allow developers to connect external applications, frontend resources, services, OAuth clients, and other capabilities to Liferay through supported extension points. Conceptually:

This makes Client Extensions attractive for:

• External microservices
• React applications
• JavaScript/CSS customization
• Remote applications
• OAuth integrations
• External notification systems
• Custom element applications
• Headless architectures

Traditional Liferay customization frequently relies on OSGi modules deployed directly into the Liferay runtime. This provides significant power but also creates tighter coupling:

The main architectural goals include:

• Better separation of concerns
• Easier platform upgrades
• Reduced dependence on Liferay internals
• Cloud-friendly deployment
• Independent development lifecycles
• Independent technology stacks

An OSGi module executes inside the Liferay application runtime. A Client Extension generally integrates through supported external extension mechanisms rather than embedding all application logic inside that runtime.

Liferay 7.4 supports several Client Extension categories, depending on the product update and deployment environment. Important categories include:

• Custom Element
• Global CSS
• Global JavaScript
• OAuth 2 Application
• Object Action
• Object Validation
• Notification Type
• Theme CSS
• Theme Favicon
• Theme JavaScript
• Theme Spritemap

Some Client Extension types are especially relevant to Liferay’s cloud and SaaS-oriented architecture.

A Client Extension project commonly contains configuration describing the extension together with the resources or source code required by that extension. A simplified structure might look like:

client-extensions/
|
+-- employee-dashboard/
   |
   +-- client-extension.yaml
   +-- package.json
   +-- src/
   |   +-- index.js
   |
   +-- assets/

The most important configuration file is typically:

client-extension.yaml

It describes how Liferay should recognize and configure the extension.

The client-extension.yaml file is the primary descriptor used to define Client Extensions. A simplified conceptual example is:

employee-dashboard:
   type: customElement
   name: Employee Dashboard
   htmlElementName: employee-dashboard
   urls:
      - index.js

The exact supported properties depend on the Client Extension type and the installed Liferay version. Therefore:

A Custom Element Client Extension allows a frontend application to be exposed inside Liferay as a browser custom element. For example:

<employee-dashboard></employee-dashboard>

The implementation could be created using technologies such as:

• React
• JavaScript
• TypeScript
• Other frontend frameworks

Conceptually:

This allows the frontend application to evolve with less coupling to Liferay’s Java/OSGi implementation.

A Global CSS Client Extension loads custom CSS resources into configured Liferay contexts. It can be useful for:

• Branding
• Corporate styling
• Common visual customization
• Portal-wide CSS adjustments

For example:

.portal-header {
   font-weight: 600;
}

.company-banner {
   border-radius: 8px;
}

Instead of modifying Liferay’s internal theme source directly, the custom CSS can be managed as an extension.

A Global JavaScript Client Extension allows custom JavaScript resources to be introduced into selected Liferay contexts. Typical use cases include:

• Analytics integration
• Client-side event handling
• Third-party scripts
• Common browser-side behavior

However, global JavaScript should be used carefully because code executed globally can affect multiple pages.

OAuth 2 Client Extensions are particularly important when an external application needs secure access to Liferay APIs. Instead of embedding credentials directly into application code, OAuth 2 can be used to establish controlled API access. Conceptually:

For example, a Spring Boot microservice may authenticate and then call:

GET /o/headless-delivery/v1.0/sites/{siteId}/blog-postings

or a custom Object API such as:

GET /o/c/employees

Client Extensions work naturally with Liferay’s Headless APIs. A modern architecture might look like:

The frontend does not need direct access to Liferay’s internal Java services. Instead, it communicates through supported APIs.

Yes. This is an important architectural combination. Suppose we have an Employee Object. The generated API could expose an endpoint similar to:

GET /o/c/employees

A React-based Client Extension could retrieve the entries:

fetch(’/o/c/employees’)
   .then(response => response.json())
   .then(data => {
      console.log(data.items);
   });

Conceptually:

Yes. One of the major advantages of the Client Extension architecture is the ability to integrate Liferay with independently deployed services. For example:

The backend does not necessarily need to be implemented using Java. Possible technologies include:

• Spring Boot
• FastAPI
• Node.js
• .NET
• Go
• Serverless functions

Security depends on the Client Extension and integration architecture. Important mechanisms can include:

• OAuth 2
• Liferay permissions
• API authorization
• HTTPS
• CORS configuration
• Secure credential management
• External service authentication

A common machine-to-machine pattern is:

The key principle is:

Sensitive credentials should be handled by trusted backend services.

Yes, when the extension accesses Liferay resources through Liferay’s APIs, the API operation remains subject to the applicable authentication and permission checks. For example:

A frontend Client Extension should therefore not be considered a security boundary. Hiding a button does not remove the user’s backend permission.

Client Extensions can be combined with Liferay Objects to execute external business logic. Consider:

This approach helps keep sophisticated integration logic outside the Liferay runtime.

An Object Validation Client Extension can support externally implemented validation behavior for Object entries where the corresponding Client Extension mechanism is available. For example, consider:

The validation service could check:

• Department budget
• Vendor status
• Spending policy

Conceptually:

This is valuable when validation is too sophisticated to represent using simple configuration.

A useful rule is:

whereas:

They solve different problems and are frequently used together.

Therefore, a powerful pattern is:

Suppose the requirement is:

Create an Employee Portal where employees can view their profile, submit leave requests and see their leave history.

Step 1: Create Liferay Objects

Create:

Employee
LeaveRequest

Employee fields:

employeeId
firstName
lastName
email
department
designation

Leave Request fields:

startDate
endDate
leaveType
reason
status

Step 2: Create the Relationship

One employee may have many leave requests:

Step 3: Use Generated APIs

The published Objects expose APIs conceptually similar to:

GET  /o/c/employees
GET  /o/c/leaverequests
POST /o/c/leaverequests

Step 4: Create a React Client Extension

Create:

employee-dashboard

The UI might contain:

+----------------------------------+

Step 5: Connect React to Objects

Conceptually:

Example:

fetch(’/o/c/leaverequests’)
   .then(response => response.json())
   .then(data => {
      console.log(data.items);
   });

Step 6: Add Workflow

A Leave Request can follow:

Step 7: Add External Integration

Suppose approved leave must also reach an HR system. The architecture could become:

Not necessarily. A major purpose of Client Extensions is to allow functionality to be implemented without placing all custom code inside the Liferay JVM.

No. Client Extensions are excellent for external integrations, frontend customizations and loosely coupled architectures. OSGi remains appropriate when deep access to Liferay’s Java services, runtime behavior, or internal extension points is required.

Yes. Custom Element Client Extensions are commonly used to integrate modern frontend applications with Liferay.

Yes, provided that authentication, authorization, networking and CORS requirements are correctly configured.

Yes. A common pattern is:

with communication through HTTP APIs and OAuth 2.

Yes. The external service does not have to use Java. For example:

This architecture is particularly useful for AI, machine learning, scientific computing and specialized Python workloads.