Skip to main content

Creating OSGi Modules and Sharing Packages

  Overview This guide walks through creating two OSGi modules in Liferay 7.4 and sharing a Java package between them using the standard API + Implementation pattern. This is the most common and correct approach for exposing reusable services in a Liferay-based architecture. In OSGi, a bundle (module) does not expose its internal packages by default — everything is private unless explicitly exported. To share code between modules, the standard practice is to split functionality into: · An API module — contains interfaces/DTOs and exports the package · A Service (Implementation) module — implements the interface, imports the package, and registers the implementation as an OSGi component/service The consuming module then simply imports the API package and looks up the service using @Reference injection. Step 1: Create the API Module Using Liferay Workspace + Blade CLI, generate a new API module: blade create -t api -p com.sgc.greeting greeting-api This generates a Gradle module unde...

Liferay DXP 7.4 Introduction & Architecture,

Liferay DXP 7.4 Introduction & Architecture



Liferay DXP 7.4 features a modular, enterprise-grade architecture that bridges the gap between traditional portal functions and modern, decoupled digital experiences. It emphasizes low-code extensibility, headless-first delivery, and a modular core based on OSGi standards.


  1. High-Level Multi-Tier Architecture

Liferay DXP 7.4 follows a standard enterprise multi-tier model to ensure fault tolerance and scalability. Each tier is independently scalable and replaceable, providing a robust foundation for production deployments.

Tier

Description & Responsibilities

Web Tier

Handles static content delivery (images, CSS) and integration with SSO solutions like SAML 2.0 or OpenID Connect. Acts as the entry point for all client requests, managing SSL termination and load balancing.

Application Tier

The core workhorse running on a Java Virtual Machine (JVM). Hosts the Liferay DXP runtime and supports application servers including Tomcat 9, JBoss EAP, and Wildfly. Manages all business logic, portlet rendering, and API processing.

Database Tier

Manages persistent data using supported RDBMS engines such as MySQL, Oracle, PostgreSQL, or SQL Server. Uses connection pooling (HikariCP) and supports primary/replica configurations for high availability.

Search Engine

Standardized around Elasticsearch (running as a separate JVM process) for high-performance full-text indexing and retrieval. Communicates with the Application Tier via the Elasticsearch REST API on port 9200.


    2. The Modular Core (OSGi)
     

The foundation of Liferay 7.4 is the OSGi (Open Service Gateway Initiative) framework, specifically Apache Felix. OSGi transforms the platform from a monolithic application into a dynamic collection of independently managed components.

  • Decoupled Modules: Functionality is broken into small, independent bundles (JARs). Each bundle declares its own dependencies, exported packages, and imported packages in a MANIFEST.MF descriptor, enforcing clean separation of concerns and eliminating classpath pollution.

  • Dynamic Lifecycle: Modules can be installed, started, stopped, or updated without restarting the entire application server. This enables zero-downtime deployments for individual modules and significantly accelerates the development feedback cycle.

  • Service Registry: Modules publish and consume services through a central OSGi registry, allowing for clean separation between service contracts (interfaces) and implementations, and supporting dynamic substitution of implementations at runtime.

  • Declarative Services: Using @Component and @Reference annotations, developers register OSGi services and inject dependencies declaratively without manual registry interaction. The framework manages the lifecycle and wiring automatically

    3. Modern Extension Patterns

 A major architectural shift in 7.4 is the move away from tightly coupled custom code (Hooks, EXT plugins) toward modern, loosely-coupled extension mechanisms. This transition is critical for upgrade safety and long-term maintainability.
  • Client Extensions: Allow developers to integrate external applications built in React, Angular, or Vue without deploying code directly into the Liferay core JVM. Client Extensions communicate through public Headless APIs exclusively, making them upgrade-safe and technology-agnostic. They are described by a client-extension.yaml file and can be deployed as Docker containers, CDN-hosted static resources, or independent microservices.

  • Liferay Objects: A low-code architectural feature that allows non-developers to define custom data models, field relationships, validation rules, and REST/GraphQL APIs directly through the administration UI. Objects auto-generate database tables, API endpoints, and default UI views upon publication with zero Java code required

    4. Headless & Decoupled CMS
   

Liferay DXP 7.4 is designed as a Headless CMS, architecturally separating content management from the presentation layer. This enables Liferay to serve as a central content hub for multiple frontends — web, mobile, kiosk, or third-party system — simultaneously.

  • API-First: Built-in, OpenAPI 3.0-compliant REST APIs and GraphQL endpoints provide full CRUD operations for users, pages, content, documents, and custom Objects. All APIs are browsable through the integrated Swagger UI at /o/api and secured with OAuth 2.0 and role-based permission scoping.

  • REST Builder: A Gradle-based code generation tool used to accelerate the development of custom, secure headless APIs with automated scaffolding. Developers define the API in an OpenAPI descriptor file and REST Builder generates resource interfaces, implementation stubs, client SDK classes, and test helpers automatically, enforcing a design-first API development approach.

    5. Frontend & UI Architecture

The frontend architecture of Liferay DXP 7.4 is built around a cohesive design system and component model that empowers both developers and non-technical business users to build and manage digital experiences efficiently.

  • Clay & Lexicon: The platform uses the Clay CSS framework as the official implementation of the Lexicon Design System. Clay provides a comprehensive library of accessible, consistent UI components — buttons, forms, tables, modals, navigation — used across all Liferay admin interfaces and end-user-facing pages. Clay ensures WCAG 2.1 accessibility compliance and supports RTL (right-to-left) layouts for Arabic and Hebrew interfaces.

  • Fragments: Small, reusable UI components composed of HTML, CSS, and JavaScript. Fragments are the primary building block of the Page Builder, allowing business users to assemble pages via drag-and-drop without developer involvement. Fragments can expose configurable properties through fragment-configuration.json, making them customisable without code editing. They consume Style Book tokens automatically, ensuring visual consistency across pages.





 

Comments

Popular posts from this blog

service builder with crud operation in liferay

   Crud and Search opration in Liferay:      ->  Liferay use service builder techniq for Crud opration.    ->  Service builder purform by  Service.xml file.    ->  Service.xml file create table in database and also create class and diffrent method.   1)      Create service.xml file.             ->Create service.xml file in WEB-INF and write below code.             ->CODE:        < service-builder package-path = "com.test" >         < namespace > qr </ namespace >           < entity name = "Searchclass" local-service = "true"                     ...

How to create new site programmaticly in liferay with validation

Create site in liferay <%@page import="javax.portlet.PortletPreferences"%> <%@page import="com.liferay.portal.kernel.util.ParamUtil"%> <%@page import="com.liferay.portal.kernel.util.HtmlUtil"%> <%@page import="com.liferay.portal.kernel.util.StringPool"%> <%@page import="com.liferay.portal.kernel.util.UnicodeProperties"%> <%@page import="com.liferay.portal.service.LayoutSetPrototypeServiceUtil"%> <%@page import="com.liferay.portal.model.LayoutSetPrototype"%> <%@page import="com.liferay.portal.service.GroupLocalServiceUtil"%> <%@page import="java.util.List"%> <%@page import="com.liferay.portal.kernel.bean.BeanParamUtil"%> <%@page import="com.liferay.portal.theme.ThemeDisplay"%> <%@page import="com.liferay.portal.model.Group"%> <%@page import="com.liferay.portal.kernel.util.WebK...

The Ultimate Guide to Liferay DXP Performance Tuning: Speed Up Your Portal

The Ultimate Guide to Liferay DXP Performance Tuning: Speed Up Your Portal In the enterprise web space, milliseconds equal millions. Whether you are running a B2B commerce storefront, a customer support portal, or an employee intranet on Liferay DXP, slow load times will devastate your user experience and destroy your SEO rankings. Out of the box, Liferay is configured to run on almost any machine. This means its default settings are highly conservative to ensure compatibility, not maximum performance. If you are launching a production environment without tuning your server, you are leaving massive amounts of speed and scalability on the table. In this comprehensive, deep-dive guide, we are going to explore the critical layers of Liferay performance tuning. We will cover backend Java Virtual Machine (JVM) configuration, Database Connection Pooling, Elasticsearch optimization, and Frontend caching strategies. By the end of this guide, you will have a blazing-fast, enterprise-grade...