DXP 7.4 vs Earlier Versions

Liferay has evolved dramatically from its early portal days to the enterprise-grade, API-first, cloud-native platform it is today. If you've worked on Liferay 6.x or even 7.0–7.2, you'll notice significant changes in architecture, development approach, tooling, and deployment. This blog covers all 14 key areas where Liferay DXP 7.4 stands apart.

LIFERAY PORTAL

DXP 7.4 vs Earlier Versions

Key Differences Every Developer Must Know

14 Categories | Architecture · APIs · Frontend · DevOps · Low-Code

01	Architecture — The Most Fundamental Change

The shift in architecture is the single most important change to understand. Everything else in Liferay 7.4 flows from this foundational decision.

❌ Earlier Versions Monolithic portal — everything bundled together Plugin SDK with WAR-based deployment Required full server restart for changes Tightly coupled components

✅ Liferay DXP 7.4 Fully OSGi modular architecture Each feature is an independent module/bundle Dynamic module loading and unloading at runtime Hot deployment — no server restart required

🔑 Key Impact: In Liferay 7.4, you can deploy, update, or remove a single module while the portal is running — something impossible in older versions. This dramatically speeds up development cycles.

02	Development Framework

The tools and patterns available to developers have expanded significantly, replacing legacy hooks and EXT plugins with modern, standards-based alternatives.

❌ Earlier Versions Portlet MVC (legacy pattern) Hooks — for overriding portal behaviour EXT Plugins — for deep core customization JSP-based development throughout

✅ Liferay DXP 7.4 MVC Portlet framework (clean, annotation-driven) REST Builder for generating REST APIs GraphQL APIs out of the box Client Extensions for UI extensions Headless architecture for decoupled frontends

💡 Tip: EXT plugins and Hooks are fully removed in 7.4. Any migration from older versions must replace these with OSGi modules, REST Builder services, or Client Extensions.

03	Frontend Modernization

Liferay moved away from its proprietary AlloyUI framework and embraced the modern JavaScript ecosystem, giving developers the freedom to use familiar tools.

❌ Earlier Versions AlloyUI — Liferay's proprietary JS framework JSP-heavy rendering throughout jQuery-based interactions No support for modern JS bundlers

✅ Liferay DXP 7.4 React — first-class support for components Vue.js via Client Extensions Clay UI — Liferay's modern design system JS modules with proper bundling and tree-shaking

Clay UI provides a complete design system including accessibility-compliant components, icons, forms, and data tables — consistent across the entire DXP 7.4 interface.

04	Headless & API-First Development

This is one of the most significant upgrades in DXP 7.4 — a complete shift to an API-first philosophy that enables entirely new integration patterns.

❌ Earlier Versions No built-in headless layer Portal was the only way to access content Limited REST support via third-party plugins Tight coupling between backend and presentation

✅ Liferay DXP 7.4 Headless REST APIs — fully documented GraphQL APIs for flexible data querying API-first design throughout the platform Swagger/OpenAPI documentation auto-generated

What This Enables

• Mobile apps consuming Liferay content via REST
• External portals and SPAs fetching data headlessly
• Microservices integrating with Liferay data models
• Third-party systems reading/writing portal objects via API

05	Search Improvements

Search in Liferay shifted from a basic, limited capability to a deeply integrated, production-grade search experience powered by Elasticsearch.

❌ Earlier Versions Basic built-in search (Lucene-based) Limited query customization Slow full-text indexing No advanced search widgets

✅ Liferay DXP 7.4 Deep Elasticsearch integration Advanced search queries with filters and facets Significant indexing performance improvements Custom search widgets and blueprints Faster search with relevance tuning

⚠️ Note: In production Liferay DXP 7.4 deployments, always use an external Elasticsearch cluster. The embedded sidecar is for development only.

06	Configuration Framework

Configuration management changed from static property files to a dynamic, UI-driven system that supports runtime changes without restarts.

❌ Earlier Versions portal-ext.properties — single flat file portlet.properties — portlet-level config Changes required server restart No UI for configuration management

✅ Liferay DXP 7.4 System Settings UI — browser-based admin panel Instance Settings — per-instance configuration OSGi .config files — file-based OSGi config Dynamic configuration updates at runtime

OSGi Configuration Example

• # bundles/osgi/configs/
• com.example.MyConfiguration.config
• 
  
• 
  
• enabled=B"true"
• apiUrl="https://api.example.com"
• timeout=I"5000"

07	Client Extensions — New in DXP 7.4

Client Extensions are an entirely new concept introduced in Liferay DXP 7.4. They allow developers to extend the portal's UI and behaviour without writing any OSGi code.

🆕 New Feature: Client Extensions exist entirely outside the OSGi container. They are deployed independently and communicate with the portal via REST APIs. This means zero portal restarts and no OSGi knowledge required.

What You Can Build with Client Extensions

• Remote React apps — full SPA rendered as a portlet
• Custom JS widgets — vanilla JavaScript components
• Theme CSS — custom stylesheets applied portal-wide
• Custom element components — Web Components integration
• Frontend token definitions — design token overrides

Client Extensions are deployed as ZIP packages and can be hosted externally or on any static hosting service — completely decoupled from the Liferay server.

08	Workspace & Build Tools

The build tooling underwent a complete overhaul, replacing Ant-based Plugin SDK with a modern Gradle-powered workspace that manages the entire development lifecycle.

❌ Earlier Versions Plugin SDK — Ant-based build system Manual WAR packaging and deployment No structured workspace concept Dependency management was manual

✅ Liferay DXP 7.4 Liferay Workspace — structured Gradle project Gradle-based build with dependency management Single workspace contains all modules and themes Blade CLI for scaffolding and module creation

Common Workspace Commands

• # Create workspace
• blade init -v 7.4 my-workspace
• # Initialize bundle (downloads DXP/CE)
• ./gradlew initBundle
• # Create new portlet module
• blade create -t mvc-portlet -p com.example.demo demo-portlet
• # Deploy all modules
• ./gradlew deploy

09	Security Enhancements

Security has been significantly hardened in DXP 7.4, with modern authentication standards and a more granular permission system.

❌ Earlier Versions Basic username/password authentication Limited SSO integration options No built-in OAuth2 support Coarse permission framework

✅ Liferay DXP 7.4 OAuth2 authentication — built-in provider Improved permission framework with fine-grained control Token-based API access for headless calls Better SSO integrations (SAML, OpenID Connect) Two-factor authentication support

10	Performance Improvements

Liferay 7.4 delivers measurable performance gains across startup time, caching, indexing, and service loading — primarily as a result of the modular OSGi architecture.

❌ Earlier Versions Slow startup — full monolith initialization Basic caching with limited configurability Full index rebuilds on content changes All services loaded regardless of usage

✅ Liferay DXP 7.4 Faster startup — only active modules initialize Better caching with Infinispan / Ehcache config Optimized incremental indexing Modular service loading — load only what you need

11	DevOps & Cloud Support

Liferay DXP 7.4 was designed from the ground up to support modern cloud-native deployment patterns — a major departure from the on-premise-only focus of earlier versions.

❌ Earlier Versions Primarily on-premise deployment Manual WAR copying to app server No native Docker/container support Limited CI/CD integration

✅ Liferay DXP 7.4 Official Docker images available Kubernetes-ready deployment CI/CD pipeline support (Jenkins, GitHub Actions) Cloud deployment on DXP Cloud or any Kubernetes cluster

Docker Quick Start

• # Run Liferay DXP 7.4 via Docker
• docker run -it -m 8g -p 8080:8080 \
• liferay/dxp:7.4.13-u92

12	UI / UX Improvements

The administrator and content author experience has been significantly modernized in DXP 7.4, making the portal more intuitive and powerful.

❌ Earlier Versions Dated admin interface (Control Panel) Basic page builder with limited drag-and-drop Limited content management tools No master page templates

✅ Liferay DXP 7.4 Modern admin interface with refreshed design Improved Page Builder with drag-and-drop fragments Master Page Templates for consistent layouts Content Page editor with live preview Experience segmentation and personalization

13	Content Management Enhancements

Liferay 7.4 brings a major uplift to content management — making it both more powerful for editors and more accessible via API for developers.

❌ Earlier Versions Basic Web Content management Manual digital asset management Content only accessible through the portal UI No content APIs for external consumers

✅ Liferay DXP 7.4 Advanced Web Content with structured types Digital Asset Management (DAM) improvements Headless Content Delivery via REST/GraphQL Content APIs for external apps and mobile Collections and content sets for dynamic display

14	Low-Code Framework — Objects & Automation

Liferay DXP 7.4 introduced a powerful low-code capability through the Objects framework — allowing business analysts and citizen developers to build data models, forms, and workflows without writing a single line of code.

❌ Earlier Versions No low-code tooling All data models required custom Service Builder code No visual workflow builder Manual Java development for all business logic

✅ Liferay DXP 7.4 Objects Framework — visual data model builder Low-code data models with fields and relationships Visual Workflow Builder (Kaleo) Automation rules triggered by object actions Forms generation from Object definitions

🚀 Significance: The Objects framework can replace 80% of custom Service Builder data models in many real-world projects. Combined with headless APIs, every Object automatically gets REST and GraphQL endpoints — zero additional development needed.

Deep Dive — OSGi Container & Service Registry

In Liferay Portal 7.4, the OSGi Container and Service Registry are the core engine of the platform's modular architecture. Understanding how they work is essential for any developer building on Liferay 7.4.

What is the OSGi Container?

The OSGi container (Apache Felix in Liferay's case) is a runtime environment that manages the lifecycle of all modules — called bundles — in the system.

• Each bundle is a JAR with an OSGi manifest (bnd.bnd)
• Bundles declare what packages they export and import
• The container resolves dependencies between bundles automatically
• Bundles can be installed, started, stopped, updated, and uninstalled dynamically

Bundle Lifecycle States

State	Description
INSTALLED	Bundle has been placed in the osgi/modules/ directory
RESOLVED	All dependencies are satisfied and resolved by the container
STARTING	Bundle activator is executing — initialization in progress
ACTIVE	Bundle is running and all services are registered and available
STOPPING	Bundle activator is shutting down — services being unregistered
UNINSTALLED	Bundle has been removed from the container

What is the Service Registry?

The Service Registry is a central directory where OSGi services are published and discovered at runtime. It is the mechanism by which bundles communicate with each other without direct coupling.

• A bundle publishes a service by registering it with the registry
• Any other bundle can look up that service by its interface
• Services can come and go dynamically — the registry handles it
• Declarative Services (DS) via @Component annotation makes this seamless

Example — Publishing and Consuming a Service

// PUBLISH a service (Provider bundle)
@Component(service = GreetingService.class)
public class GreetingServiceImpl implements GreetingService {
@Override
public String greet(String name) {
return "Hello, " + name + " from Liferay DXP 7.4!";
}
}


// CONSUME a service (Consumer bundle)
@Component(service = MyPortlet.class)
public class MyPortlet extends MVCPortlet {
@Reference
private GreetingService _greetingService;
}

💡 How it works: The @Component annotation registers the class with the OSGi Service Registry. The @Reference annotation tells the container to inject the matching service automatically — no manual wiring needed.

OSGi vs Monolith — Side by Side

❌ Earlier Versions Single JVM class loading — all code visible everywhere Changes require full application restart Bugs in one module can crash everything No service versioning or isolation

✅ Liferay DXP 7.4 Class loading isolation per bundle — clean boundaries Deploy / update individual modules at runtime Module failures are isolated from other bundles Multiple service versions can coexist in the container

Summary — All 14 Differences at a Glance

#	Category	Earlier Versions	Liferay DXP 7.4
01	Architecture	Monolithic + WAR	OSGi Modular + Hot Deploy
02	Dev Framework	Hooks, EXT, JSP	REST Builder, GraphQL, Client Ext
03	Frontend	AlloyUI, jQuery	React, Vue, Clay UI
04	APIs	No headless layer	REST + GraphQL API-first
05	Search	Basic Lucene	Elasticsearch deep integration
06	Configuration	portal-ext.properties	System Settings UI + OSGi config
07	Client Extensions	Not available	Remote apps, JS widgets, CSS
08	Build Tools	Plugin SDK + Ant	Liferay Workspace + Gradle
09	Security	Basic auth only	OAuth2, SAML, token-based API
10	Performance	Slow startup, basic cache	Fast startup, optimized indexing
11	DevOps	On-premise only	Docker, Kubernetes, CI/CD
12	UI/UX	Dated admin UI	Modern builder, drag-and-drop
13	Content Mgmt	Basic WCM	Headless CMS + Content APIs
14	Low-Code	No low-code tooling	Objects, Workflow Builder, Automation