Liferay

Liferay DXP 2026.Q3 - Release Webinar - Replay

2026-09-02T01:01:24Z

Hi everyone! I'm pleased to announce that the recording of the 2026.Q3 Release Webinar is now available for you to replay at your leisure!

The recording includes details on key new features in the Q3 release like Design Libraries, CNE AWS Ready and Kubernetes Ready, as well as key new modules moving out of Beta status:
•    Liferay Data Platform - GA
•    Digital Sales Room - GA
•    AI Hub - GA
•    Content Marketing Platform - Release

For more details and a link to the recording and PDF you can visit:

https://www.liferay.com/web/lr/quarterly-release-webinar-q3-2026-recording

Any questions, you know where to find me!

All the best,

Ben

Enabling ModSecurity in Liferay PaaS

2026-08-18T19:21:59Z

Liferay's documentation does a good job of explaining how to turn ModSecurity on, how to provide your own configuration, and how to send the audit log to the Liferay Cloud Console.

But, as I recently discovered while working with a client, there is a pretty big gap between:

ModSecurity is enabled and I can see logs.

and:

I'm getting the ModSecurity information I actually need, reliably, without overwhelming the logging pipeline.

We spent quite a bit of time working through that gap.

This post isn't intended to replace the official documentation. Think of it as the next chapter: some practical configuration guidance that became apparent only after working through a real-world implementation.

Start with the Liferay Documentation

If you haven't already enabled ModSecurity, start with Liferay's official Web Application Firewall documentation.

In webserver/LCP.json, enable ModSecurity using:

{
    "env": {
        "LCP_WEBSERVER_MODSECURITY": "DetectionOnly"
    }
}

Liferay supports three values:

Off — ModSecurity does not process rules.
DetectionOnly — rules are evaluated, but disruptive actions aren't executed.
On — rules are evaluated and enforcement actions can be executed.

Liferay recommends starting with DetectionOnly, testing and tuning the rules, and moving to On only after you're comfortable that legitimate traffic won't be disrupted.

That's good advice. Don't skip that step.

Also remember that if you provide your own:

webserver/configs/[ENV]/modsec/modsecurity.conf

you're not augmenting the default Liferay configuration.

You're replacing it.

Your file needs to provide all of the necessary ModSecurity configuration. That detail becomes important very quickly.

Local Log Files and Containers Don't Mix Particularly Well

The default audit-log configuration typically writes to something like:

/var/log/modsec_audit.log

That's perfectly reasonable on a traditional server.

The server starts, it runs for months or years, and logs accumulate on its filesystem until something rotates or archives them.

A PaaS container doesn't work that way.

Containers can be replaced, restarted, rescheduled, or scaled. A log file living only inside one webserver container belongs to the lifetime of that container.

So if the goal is to retain ModSecurity output independently of a particular container, writing only to a local file isn't a very useful long-term strategy.

Liferay's documentation already provides the key change:

SecAuditLog /dev/stdout

This sends the audit output to standard output, allowing it to appear with the webserver service logs in the Liferay Cloud Console making it part of the platform logging stream, but more importantly it means you get ModSec logs from all containers (even those that autoscale up/down) and can download/retain them for as long as you require.

But this is also where things get interesting.

`/dev/stdout` Doesn't Mean "Dump Everything"

During our troubleshooting, we reached a configuration that looked approximately like this:

SecAuditEngine On

SecAuditLogParts ABIJDEFHZK

SecAuditLogType Serial
SecAuditLog /dev/stdout
SecAuditLogFormat JSON

At first glance, that seems reasonable.

Turn auditing on.

Capture lots of information.

Use JSON because structured logging is cool.

Send it all to stdout.

What could possibly go wrong?

Quite a lot, actually.

`SecAuditEngine On` Can Generate a Lot of Data

SecAuditEngine controls which transactions receive an audit record.

The available values are:

SecAuditEngine Off
SecAuditEngine On
SecAuditEngine RelevantOnly

On means audit every transaction.

RelevantOnly means audit transactions that generated a warning or error, or whose response status matches SecAuditLogRelevantStatus.

For a security audit log, logging every ordinary request usually isn't what you're looking for.

A normal page can involve dozens or hundreds of requests. Add images, JavaScript, CSS, APIs, probes, monitoring requests, and normal application traffic, and On can generate an enormous amount of audit data.

Our working configuration changed this to:

SecAuditEngine RelevantOnly

For example:

SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"

For a WAF, that's much closer to what you normally want:

Tell me about the interesting transactions. Don't create another copy of my entire access log.

Then There Was the `E`

The second major finding was buried inside this innocent-looking setting:

SecAuditLogParts ABIJDEFHZK

Those letters aren't a format.

They tell ModSecurity which parts of the HTTP transaction to include in the audit record.

And one of those letters can make a very big difference:

E tells ModSecurity to include the response body.

Think about what that means.

If the response is a 300 KB HTML page, you can end up putting that response into the audit record.

Now combine:

SecAuditEngine On

with:

SecAuditLogParts ...E...

and:

SecAuditLogFormat JSON

and:

SecAuditLog /dev/stdout

You've potentially asked ModSecurity to serialize large response bodies into JSON for every request and push all of it through the container logging pipeline.

That turned out to be a very important combination in our troubleshooting.

The change that ultimately helped was removing E:

- SecAuditLogParts ABIJDEFHZK
+ SecAuditLogParts ABIJDFHZK

Same auditing capability.

Same rules.

Same request processing.

But the response body is no longer being stuffed into the audit output.

And that's an important distinction:

Removing E does not disable response-body inspection.

SecResponseBodyAccess controls whether ModSecurity examines response bodies.

SecAuditLogParts controls what gets recorded in the audit log.

Those are two different decisions.

So What Do All Those Letters Mean?

Rather than copying a value from a sample configuration, you should understand what you're asking ModSecurity to retain.

`A` — Audit Log Header

Contains the audit entry header. This part is mandatory.

`B` — Request Headers

Contains the HTTP request headers. This is normally very useful when investigating why a rule matched.

`C` — Request Body

Contains the request body when one exists and request-body inspection is enabled.

This can be useful, but request bodies can also contain substantial amounts of data or sensitive information.

`D` — Reserved

Reserved for intermediary response headers. It is not currently implemented in ModSecurity 3.x.

`E` — Response Body

Contains the response body when response-body inspection is enabled.

This was the important one in our investigation.

Response bodies can be large, and including them in centralized audit output can dramatically increase both individual record size and overall log volume.

Unless you have a specific business or forensic requirement for storing response bodies, I would leave E out.

`F` — Final Response Headers

Contains the final response headers. Useful without carrying the potentially large cost of storing the response body.

`G` — Reserved

Reserved for the actual response body and not currently implemented.

`H` — Audit Log Trailer

Contains the audit-log trailer and additional transaction information.

`I` — Not Implemented in ModSecurity 3.x

Older ModSecurity documentation describes I as a reduced multipart request body that could be used instead of C.

The ModSecurity 3.x reference lists it as not implemented.

`J` — Uploaded File Information

Contains information about files uploaded using multipart/form-data.

`K` — Not Implemented in ModSecurity 3.x

In older ModSecurity versions, K represented matched-rule information. In ModSecurity 3.x it is listed as not implemented.

`Z` — End of Audit Entry

Marks the end of the audit entry. Like A, this is mandatory.

Choose the Parts You Actually Need

The ModSecurity 3.x documented default is:

ABCFHZ

The configuration we were working with contained:

ABIJDEFHZK

and the critical operational change was:

ABIJDFHZK

removing E.

If I were designing a brand-new configuration today, though, I wouldn't start by asking:

What long sequence of letters should I copy?

I'd ask:

What information does the security team actually need?

Then select the parts accordingly.

In particular, make deliberate decisions about:

C - request body
E - response body
J - uploaded file information

Those can materially affect log size and potentially the sensitivity of the information you're retaining.

Native or JSON?

This is another place where two different settings are sometimes conflated.

The audit parts are selected with:

SecAuditLogParts ...

The audit format is selected separately:

SecAuditLogFormat Native

or:

SecAuditLogFormat JSON

The default ModSecurity format is Native. JSON is also supported.

JSON can be very useful.

If you're feeding logs into a SIEM, writing automated analysis, or extracting rule IDs, anomaly scores, messages, and transaction fields programmatically, JSON is much easier to work with.

But JSON isn't required to make ModSecurity logging work.

My recommendation is to make this a business/use-case decision, not a technical checkbox.

Use Native when:

humans are primarily reading the logs;
you want the familiar ModSecurity audit representation;
you don't need structured downstream processing.

Consider JSON when:

you're feeding the records into security tooling;
you're building automated filtering or analytics;
you need structured fields rather than text parsing.

But regardless of the format, control what you're putting into each record.

Changing from Native to JSON doesn't make a huge response body suddenly small.

Don't Forget the Other ModSecurity Log

One thing that caused some confusion during our work was that ModSecurity information can show up through more than one logging path.

The detailed transaction-oriented information goes to the audit log.

But the familiar messages that look something like:

ModSecurity: Warning. Matched ...

are emitted through Nginx's error logging path.

So if those are the messages you care about seeing in the Liferay Console, make sure Nginx is also writing its error log to stdout:

error_log /dev/stdout warn;

Nginx supports these logging levels:

debug
info
notice
warn
error
crit
alert
emerg

Selecting a level includes that level and all more-severe levels.

In our case, warn was the right normal operating level.

During troubleshooting you might temporarily use notice, info, or even debug.

But don't leave highly verbose logging enabled just because more data feels safer.

Sometimes more logs just means more hay around the needle.

Be Careful with `SecDebugLogLevel 9`

Along the same lines, we used very verbose ModSecurity debug logging while troubleshooting.

That's appropriate when you're trying to understand why something isn't behaving correctly.

It isn't something I want running indefinitely.

For normal operation we brought the level back down:

SecDebugLogLevel 3

rather than:

SecDebugLogLevel 9

Level 9 can be useful when troubleshooting, but once you understand the problem, turn the noise back down.

A Practical PaaS Configuration

Pulling the important pieces together, the configuration pattern I'd start from looks more like this:

SecRuleEngine ${LCP_WEBSERVER_MODSECURITY}

SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"

SecAuditLogParts ABIJDFHZK

SecAuditLogType Serial
SecAuditLog /dev/stdout

SecDebugLogLevel 3

And in Nginx:

error_log /dev/stdout warn;

Then make an explicit decision about the audit format.

For Native:

SecAuditLogFormat Native

or simply rely on the native default.

For structured output:

SecAuditLogFormat JSON

And again, review SecAuditLogParts rather than simply copying my string.

The important operational characteristics are:

SecAuditEngine RelevantOnly

rather than On, and:

E is not included in SecAuditLogParts

unless you have a deliberate reason for retaining response bodies.

What About Access Logs?

You may also want the normal Nginx request record in the same centralized stream:

access_log /dev/stdout main;

That can be helpful when correlating a ModSecurity event back to the corresponding request.

Whether you want all access-log traffic in the Console is a separate operational decision.

Again, resist the temptation to turn on everything simply because you can.

And Then Download the Logs

Getting the logs into the Liferay Console solves the container-lifetime problem, but the Console shouldn't necessarily be your organization's permanent audit archive, especially since logs are only kept for 30 days.

The Liferay command-line tool can retrieve service logs:

lcp log -p <project>-<environment> -s webserver

and constrain the export by time:

lcp log \
    -p <project>-<environment> \
    -s webserver \
    --since "<start_time>" \
    --until "<end_time>" \
    >> webserver-logs.txt

For an organization that needs longer-term security retention, I'd automate this.

For example, create a scheduled job to download the logs once a week, filter out the log messages not related to ModSec, and then keep those files for as long as you need.

If you're using JSON audit output, that processing gets particularly easy because you can parse fields instead of relying entirely on string matching.

The Bigger Lesson

The biggest lesson from this exercise wasn't a magic ModSecurity directive.

It was that logging in a container platform needs to be treated as a pipeline, not as a file.

There's the application generating the information.

There's ModSecurity deciding what should be audited.

There's Nginx deciding what goes to its error and access logs.

There's stdout.

There's the container runtime.

There's the platform logging infrastructure.

And finally there's the Console where a human sees the result.

You can have a perfectly valid ModSecurity configuration and still create a terrible logging configuration.

In our case, these were all individually reasonable choices:

Audit everything.
Include the response.
Use JSON.
Send it to stdout.

Together, they weren't reasonable.

The final approach was much simpler:

Audit the relevant transactions.
Don't include giant response bodies unless you actually need them.
Send the useful output to stdout.
Keep normal logging at a sensible verbosity.
Export what you need for long-term retention.

That's a configuration you can live with.

And, more importantly, it's one the logging pipeline can live with too.

When a CVE Isn't a Liferay Vulnerability

2026-08-17T16:56:54Z

Security scanners are very good at finding things.

Run one against a Liferay DXP installation and it will inventory third-party libraries, determine their versions, compare those versions against vulnerability databases such as the NVD, and produce a list of CVEs.

Then somebody opens a Liferay Support ticket.

We're running version X of library Y. CVE-Z says that version is vulnerable. When will Liferay upgrade it?

Sometimes the answer is exactly what you would expect: Liferay upgrades the library.

But quite often the answer is something closer to:

Liferay DXP is not affected by this vulnerability.

That answer can be frustrating, particularly when the scanner has assigned the finding a High or Critical severity. The JAR is there. The version matches. The CVE exists. How can Liferay say it isn't vulnerable?

Because those are actually three different statements.

The library is present.

A vulnerability exists in that version of the library.

That vulnerability can be exploited through Liferay DXP.

A security scanner can usually establish the first two. Establishing the third requires understanding how the software actually works.

And that is where things get interesting.

The Scanner Isn't Wrong

Let's start by giving the scanner some credit.

If the scanner says that Liferay contains a particular version of a third-party library and that version is associated with a CVE, it may be completely correct.

The mistake is treating that information as proof that the resulting Liferay installation is exploitable.

Software Composition Analysis tools generally work from something resembling this model:

That's useful information, but it is only the beginning of vulnerability analysis.

A CVE usually applies to some particular behavior within a library. Exploiting it may require a certain class to be used, a particular feature to be enabled, a specific configuration, attacker-controlled input to reach a particular method, or some combination of all of these.

If the application never exposes that attack surface, the vulnerable code can physically exist inside the JAR without providing an exploitable path through the application.

The scanner has identified a potential vulnerability.

Now someone has to determine whether it is a reachable vulnerability.

Spring Is a Good Example

Consider Spring 6.2.9 as an example.

There are several CVEs associated with Spring components around these versions, including:

CVE	Area	Important Exploitation Condition
CVE-2025-41242	Spring MVC path traversal	Requires particular Spring static-resource handling combined with a Servlet container that does not reject the malicious path sequences.
CVE-2025-22228	Spring Security `BCryptPasswordEncoder`	Requires use of the affected password encoder behavior with passwords longer than 72 characters.
CVE-2025-41249	Spring annotation detection	Relevant when Spring Security method security is enabled and authorization annotations occur in particular parameterized type hierarchies.

These aren't hypothetical qualifications added by Liferay. They come directly from Spring's own security advisories. For example, Spring says CVE-2025-41242 depends on several conditions and specifically notes that default Tomcat and Jetty security behavior prevents the vulnerability. CVE-2025-41249 similarly identifies @EnableMethodSecurity as part of the affected scenario.

CVE-2025-22228 affects BCryptPasswordEncoder.matches() when passwords exceed 72 characters and the first 72 characters match. Again, that is a real vulnerability, but an application has to actually use that Spring Security functionality in an exploitable authentication path before it becomes an application vulnerability.

And who knows? By the time you're reading this there may be several more CVEs associated with these versions.

That's the nature of modern software.

What matters is what happens next.

Presence Is Not the Same as Exploitability

When Liferay's application security team evaluates one of these reports, the CVE number and library version are just the starting point.

The real questions look more like this:

What exactly is the vulnerable code?
What conditions are required to exploit it?
Does Liferay use that code?
Is the vulnerable capability enabled?
Can an attacker reach it?
Can attacker-controlled input reach the vulnerable path?
Does Liferay's own configuration or surrounding architecture prevent the exploit?

Only after answering those questions can you determine the actual risk to Liferay DXP.

This concept is often called reachability.

Imagine a third-party JAR containing 5,000 classes. One method in one class contains a vulnerability.

If Liferay never loads that class, never invokes that method, never enables the associated feature, and provides no path for attacker-controlled input to reach it, replacing the entire JAR may change the version number reported by your scanner without materially improving the security of the platform.

That's an important distinction.

Security isn't about achieving the highest possible dependency version number.

It's about eliminating exploitable attack paths.

What Happens When Liferay Investigates a CVE?

Liferay has a dedicated application security team continuously reviewing vulnerabilities reported against both Liferay code and the third-party software included with DXP.

Often the CVE has already been investigated before a customer reports it through Support.

The analysis goes deeper than the CVE headline.

The team looks at what causes the vulnerability, what is required to exploit it, and how a working exploit would behave. Then they compare those requirements against the way the affected library is actually being used by Liferay DXP.

The team also leverages tools like Konvu and other AI tools during the analysis to ensure it's not a cursory review.

You can read more about CVEs the security team has reviewed along with their classifications here: https://support.liferay.com/security-vulnerabilities.

Sometimes that analysis concludes that Liferay is affected.

Sometimes it concludes that Liferay is not affected.

There are even cases where the answer depends on configuration.

That's exactly the kind of application-level context that a simple dependency/version scan cannot provide.

The Log4j 1 Lesson

Anyone who dealt with enterprise security scanning during the later years of Log4j 1 probably remembers this problem particularly well.

Log4j 1 reached end of life, but applications continued using it for years afterward. As vulnerabilities were discovered, scanners accumulated an increasingly alarming collection of findings.

Some of them were severe.

CVE	Component	Attack Surface
CVE-2019-17571	`SocketServer`	Deserialization through the Log4j network logging server.
CVE-2021-4104	`JMSAppender`	JNDI behavior associated with JMS logging configuration.
CVE-2022-23302	`JMSSink`	JNDI and deserialization behavior through the JMS sink.
CVE-2022-23305	`JDBCAppender`	SQL injection through the database logging appender.
CVE-2022-23307	Chainsaw	Deserialization in the Chainsaw logging viewer.

These vulnerabilities were real. Nobody was disputing that.

But look at the affected functionality.

Liferay wasn't running a Log4j SocketServer.

It wasn't using Chainsaw.

It wasn't using the JDBCAppender.

It wasn't using the vulnerable JMS logging components.

There was no route through a normal Liferay DXP installation for an attacker to reach those vulnerable features.

That didn't stop scanners from finding them.

From the scanner's perspective, everything was working exactly as designed:

The scanner had no idea whether Liferay was using JDBCAppender, SocketServer, or anything else inside the library.

It only knew the library was there.

But Sometimes "Not Vulnerable" Isn't Enough

This creates a practical problem.

A Critical CVE sitting on a security report is difficult for many organizations to accept, even when the vendor has analyzed it and determined that the product is not affected.

Security policy might say every Critical CVE must be eliminated.

An auditor might require remediation.

A customer's vulnerability management platform may refuse to close the finding.

And eventually someone asks:

Why doesn't Liferay just upgrade the library and make the scanner happy?

The Log4j 1 situation became a good example of how this can play out.

Apache had stopped maintaining Log4j 1, while moving directly to Log4j 2 represented a much larger technical change.

An intermediate solution was reload4j.

Reload4j is a binary-compatible fork of Log4j 1.2.17 designed specifically to harden the old Log4j implementation against these kinds of vulnerabilities. Among other changes, it addressed the JMSAppender, JMSSink, SocketServer, Chainsaw, and JDBCAppender issues.

Liferay adopted reload4j for earlier DXP releases while eventually moving DXP 7.4 to Log4j 2.

That gave Liferay a migration path without forcing a risky architectural change into older supported releases merely to satisfy dependency scanners.

The Three Basic Outcomes

When a vulnerability is identified in a third-party dependency, there are generally three reasonable outcomes.

The Product Isn't Affected

The investigation can establish that the vulnerable capability isn't reachable through Liferay.

No code change may be necessary.

I tend to prefer not affected or not exploitable in Liferay's usage over the phrase false positive here.

The CVE itself isn't false.

The scanner may have correctly identified the library.

What is false is the conclusion that the CVE necessarily represents an exploitable Liferay vulnerability.

This decision should never be made casually. It requires understanding both the vulnerability and Liferay's use of the affected library.

Patch or Harden the Dependency

Sometimes the vulnerability matters, but upgrading isn't practical.

The upstream project may be abandoned. The fixed version may contain incompatible changes. The affected capability may be something Liferay doesn't need at all.

In those cases, a focused patch or hardened dependency can make more sense than a major upgrade.

Removing unused vulnerable functionality can be particularly effective because code that no longer exists has a remarkably small attack surface.

Of course, maintaining patches to somebody else's software has a cost too. Whenever possible, fixes should remain aligned with or be contributed back to the upstream project rather than creating a permanent private fork.

Upgrade the Dependency

And sometimes upgrading really is the correct answer.

If a compatible maintenance release contains the fix, upgrading can be relatively straightforward.

The difficulty increases significantly when remediation requires a major version change.

At that point this isn't a security patch anymore.

It is a software upgrade.

Why Not Just Upgrade Every Time?

If you've ever upgraded Liferay itself, you already know the answer.

Software libraries are dependencies because applications depend on them.

Changing a major dependency can introduce:

API incompatibilities
behavioral changes
transitive dependency changes
classloading differences
OSGi package compatibility issues
configuration changes
unexpected runtime regressions

Even a library that compiles successfully after an upgrade can behave differently at runtime.

Then the updated platform has to be tested.

Liferay releases go through extensive testing precisely because changing something deep in the platform can have consequences far away from the code that changed.

This leads to a somewhat counterintuitive security principle:

An unnecessary security upgrade is not risk free.

Suppose Liferay establishes with high confidence that a particular CVE cannot be exploited through DXP.

Upgrading to a new major version of that dependency may therefore reduce essentially zero exploitable security risk while introducing new compatibility and regression risk.

That isn't automatically a good trade.

Security engineering should minimize total platform risk, not maximize dependency version numbers.

And engineering resources aren't infinite either.

Every week spent forcing unnecessary third-party upgrades through development, compatibility work, automated testing, manual testing, stabilization, and release engineering is time not being spent fixing actual vulnerabilities or improving the product.

I would much rather see those resources focused on exploitable security issues and meaningful improvements to Liferay DXP.

There Is One Important Catch: Your Code

There's another side to this discussion that customers building their own Liferay extensions need to understand.

When Liferay says a third-party CVE is not exploitable in Liferay DXP, that assessment applies to Liferay's use of the library.

Your customization can change that answer.

Suppose Liferay bundles a library containing a vulnerable feature but never uses that feature.

Then you create an OSGi module that imports the library and starts using exactly that functionality.

You may have just created the attack surface that didn't previously exist.

The same principle applies if you:

enable functionality that Liferay leaves disabled,
expose a library API through a custom REST endpoint,
pass attacker-controlled input into code that Liferay only uses with trusted data,
introduce a vulnerable appender, parser, serializer, or network listener,
or change security-related configuration around a bundled dependency.

At that point, the original Liferay analysis may still be completely correct.

Liferay isn't vulnerable. Your customization is.

This is one reason security analysis for customized Liferay installations can't stop with Liferay's own vulnerability statements.

Your code is part of the application too.

Don't Replace Liferay JARs Just to Silence a Scanner

This leads to one final warning.

When customers encounter one of these findings, there can be a temptation to "fix" the problem themselves by dropping a newer version of the affected JAR into Liferay.

Don't do that casually.

Liferay is a large application with carefully managed dependency versions, OSGi package relationships, transitive dependencies, and runtime expectations.

Replacing a platform dependency underneath it can create subtle failures that are extremely difficult to diagnose.

It can also move the installation outside the configuration Liferay Support has actually tested and supports.

You may successfully make the CVE disappear from the scan while introducing an entirely different production problem.

That's not security improvement.

That's vulnerability-report whack-a-mole.

What Should You Do With a Scanner Finding?

Security scans are still valuable.

When one identifies a third-party CVE in Liferay, report it. Include the library, version, CVE, scanner output, and any information you have about how you believe the vulnerability could be exploited.

But the most useful question isn't:

When will you upgrade this JAR?

A better set of questions is:

Is Liferay DXP affected by this CVE?

Is the vulnerable functionality used by Liferay?

Under what configuration would the vulnerability become exploitable?

Does the assessment apply only to Liferay out of the box, or are there concerns for custom OSGi modules?

Those questions get us much closer to the thing we actually care about.

Risk.

A CVE Is the Beginning of the Investigation

A CVE deserves attention.

A Critical CVE deserves serious attention.

But a CVE attached to a third-party JAR isn't automatically proof that the application containing that JAR is vulnerable.

Good vulnerability management requires more than matching version numbers.

It requires understanding attack surfaces, reachability, configuration, data flow, and how the affected software is actually being used.

Sometimes that investigation should result in an immediate dependency upgrade.

Sometimes it should result in a targeted patch.

And sometimes the technically correct answer really is:

Liferay DXP is not affected.

That doesn't mean the CVE was ignored.

Quite the opposite.

It means someone did the work that the scanner couldn't.

And that is exactly what we should want from a product security team.

The goal isn't to make every CVE identifier disappear from a dependency report at any cost. The goal is to keep exploitable vulnerabilities out of the platform while avoiding unnecessary changes that introduce new compatibility and operational risk.

So the next time a scanner finds a CVE in a third-party library bundled with Liferay, don't stop at:

Is this version listed in the NVD?

Ask the more important question:

Can an attacker actually reach and exploit it through our Liferay environment?

The scanner gives you the starting point.

It doesn't always give you the verdict.

Liferay DXP 2026.Q3 Release Webinar

2026-09-02T00:57:46Z

Hi everyone,

I'm super excited to announce that the Release Webinar for the 2026.Q3 release of Liferay DXP is coming in just a couple of weeks - on Wednesday, August 26th.

Of particular interest in Q3 are:

AI Hub, Content Marketing Platform (CMP), Liferay Data Platform (LDP) and Digital Sales Rooms (DSR) all move to GA status - and introduce new features
Cloud Native adds GA support for GCP Ready and Kubernetes Ready
New Design Libraries feature brings a central place to build and reuse design assets across multiple sites.

And, much more across the platform!

Attending live lets you hear about all of the new features coming as well as letting you participate in a live Q&A with members of our Product Management team.

While we will, as always, record and share the session for those that can't make it, the Q&A section is only available if you attend live!

Click the links below to Register for the session that best suits your timezone.

(Both sessions are identical, you only need to attend one!)

SESSION A - EMEA/APAC	SESSION B - AMERICAS
Topic: 2026.Q3 Release Webinar	Topic: 2026.Q3 Release Webinar
Date: August 26, 2026 (Listed by Time Zone)	Date: August 26, 2026 (Listed by Time Zone)
08:00 - UTC 09:00 - UK/IRE (BST) 10:00 - Central Europe (CEST) 12:00 - Dubai (GST) 13:30 - India (IST) 16:00 - Singapore (SGT) 17:00 - Japan (JST) 18:00 - Sydney (AEST)	2:00 pm - Los Angeles (PDT) 3:00 pm - Mexico City (CST) 4:00 pm - Chicago (CDT) 5:00 pm - New York (EDT) 6:00 pm - Recife (BRT) 9:00 pm - UTC 7:00am - Sydney (AEDT) (August 27)

To learn more, you can also check out the Release Webinar landing page.

See you there!

Cheers,

Ben

======================================================

SESSION REPLAY AND PDF

So, the event is over, but the memories remain - you can now access the recording of the session along with a PDF of the presentation here.

======================================================

OIDC SLO in Liferay DXP

2026-08-05T17:04:04Z

If you've searched for information about OpenID Connect (OIDC) Single Logout (SLO) in Liferay, you've probably come across answers stating that it isn't supported. That answer was accurate for a long time, and it still occasionally appears in support discussions today.

Beginning with Liferay DXP 2026.Q1, however, that answer is no longer correct.

Liferay now supports the OpenID Connect Back-Channel Logout specification, allowing an OpenID Provider (OP) to notify Liferay that a user's central authentication session has ended so the corresponding portal session can be terminated as well.

This isn't every logout mechanism defined by the OpenID Connect specifications, and that's an important distinction. In this post we'll look at what is supported today, how it works, how to configure it, and what it means for production deployments.

Understanding the Terminology

If you're familiar with SAML, the terminology can be a little confusing because OpenID Connect uses different names for similar concepts.

SAML	OpenID Connect
Identity Provider (IdP)	OpenID Provider (OP)
Service Provider (SP)	Relying Party (RP)

Liferay's OpenID Connect implementation only acts as a Relying Party (RP).

In other words, Liferay delegates authentication to an external OpenID Provider such as Keycloak, Microsoft Entra ID, Okta, or another standards-compliant identity provider. Liferay does not become an OpenID Provider itself.

That distinction explains why only certain OpenID Connect specifications apply to Liferay.

There Isn't Just One "OIDC Logout"

One of the biggest sources of confusion is that people talk about "OIDC Single Logout" as though it were a single feature.

It isn't.

OpenID Connect defines multiple specifications for ending authenticated sessions, each designed for different scenarios.

Some involve browser redirects. Others use hidden iframes. Others avoid the browser entirely and rely on secure server-to-server communication.

As of Liferay DXP 2026.Q1, Liferay implements the Back-Channel Logout specification.

Support for RP-Initiated Logout, where Liferay requests that the OpenID Provider terminate the user's single sign-on session, is planned for a future release. As always, roadmap items are subject to change.

Understanding which logout specification is being discussed is important because saying "OIDC logout is supported" or "OIDC logout isn't supported" doesn't tell the whole story.

Why Back-Channel Logout Exists

Consider a fairly typical enterprise deployment.

A user authenticates through Keycloak (or any OIDC OP) and gains access to several applications.

The user now has active authenticated sessions in each application.

Later, an administrator disables the account or terminates the user's identity provider session.

Without Single Logout, the user has technically been logged out of the identity provider, but every application still has its own active session.

The user may continue working in Liferay until the portal session expires naturally.

The same may be true for Grafana, Jenkins, or any other relying party.

That's clearly not ideal.

Back-Channel Logout solves this problem by allowing the OpenID Provider to notify every participating application that the central authentication session has ended.

Each application can then invalidate its own local session immediately.

How Back-Channel Logout Works

Unlike browser-based logout mechanisms, Back-Channel Logout is entirely server-to-server.

The user's browser isn't involved.

There are no redirects.

There are no hidden iframes.

Instead, the OpenID Provider sends a signed Logout Token directly to each registered relying party.

The overall flow looks like this.

From the user's perspective, nothing happens in the browser until they attempt another request.

The next interaction with Liferay discovers that the authenticated session no longer exists, and the user must authenticate again.

Liferay's Implementation

Liferay's implementation follows the OpenID Foundation's Back-Channel Logout specification.

Rather than implementing provider-specific integrations, Liferay focuses on standards compliance, allowing it to interoperate with any OpenID Provider that implements the same specification.

Once OpenID Connect is configured, Liferay exposes the following endpoint:

/o/open_id_connect/backchannel_logout

When the OpenID Provider determines that a user's authenticated session has ended, it sends a signed Logout Token to this endpoint.

Liferay validates the token.

If validation succeeds, Liferay identifies the corresponding authenticated portal session and invalidates it.

That's the entire logout flow from Liferay's perspective.

Configuring Back-Channel Logout

The good news is that there isn't much additional configuration required inside Liferay.

If OpenID Connect is already configured, enabling Back-Channel Logout primarily involves registering Liferay's logout endpoint with your OpenID Provider.

The process typically looks like this:

Configure OpenID Connect normally in Liferay.
Configure your OpenID Provider as you normally would.
Register Liferay's Back-Channel Logout endpoint:

https://your-liferay-host/o/open_id_connect/backchannel_logout

Enable Back-Channel Logout support in your identity provider, if required.

The exact steps for registering the endpoint vary by provider, but the concept remains the same regardless of whether you're using Keycloak, Microsoft Entra ID, Okta, or another standards-compliant implementation.

Security Considerations

At first glance, exposing a logout endpoint may seem concerning.

What prevents someone from sending arbitrary HTTP POST requests and logging users out?

The answer is the Logout Token.

The OpenID Provider sends a cryptographically signed Logout Token that identifies the authenticated session being terminated.

Liferay validates that token before taking any action.

If validation fails, the logout request is rejected.

In other words, the endpoint isn't a public "log out any user" API.

It only accepts properly signed logout notifications from the configured OpenID Provider.

Operational Considerations

Although the implementation itself is straightforward, there are a few operational details worth remembering.

The OpenID Provider Must Reach Liferay

Back-Channel Logout is initiated by the OpenID Provider, not the user's browser.

That means your identity provider must be able to reach Liferay's Back-Channel Logout endpoint.

In practice, this means paying attention to reverse proxy configuration, firewall rules, DNS resolution, TLS certificates, and public endpoint accessibility.

If the OpenID Provider cannot successfully deliver the Logout Token, Liferay has no way of knowing that the central authentication session has ended.

Browser Behavior

Because this is a server-to-server protocol, users won't necessarily notice anything immediately.

If they're actively viewing a page inside Liferay, nothing visibly changes.

The logout is detected the next time the browser communicates with the portal.

This behavior is expected and is one of the defining characteristics of the Back-Channel Logout specification.

Clustered Liferay Environments

Back-Channel Logout does not introduce a special clustering requirement.

If a Liferay environment is using OpenID Connect Single Sign-On, each node already participates in the same authentication model. Once the OpenID Provider ends the session and Liferay processes the Logout Token, subsequent attempts to use that authenticated session should fail regardless of which cluster node receives the request.

The important operational concern is therefore not session replication between Liferay nodes. It is ensuring that the OpenID Provider can reach Liferay's Back-Channel Logout endpoint and that the Logout Token can be validated successfully.

What Isn't Supported Yet?

Another OpenID Connect specification is RP-Initiated Logout.

Instead of the identity provider initiating logout, the relying party starts the process.

For example, imagine a user clicking Log Out inside Liferay.

Rather than only invalidating the local portal session, Liferay could also request that the OpenID Provider terminate the user's central single sign-on session.

That, in turn, would allow the identity provider to notify every participating application.

The flow would look something like this.

Support for RP-Initiated Logout is planned for a future Liferay release, although, as with any roadmap item, plans may change.

When both specifications are available, they complement one another rather than replace one another.

Back-Channel Logout allows the OpenID Provider to terminate application sessions.

RP-Initiated Logout allows an application to terminate the user's central identity provider session.

Together they provide a more complete single logout experience.

Final Thoughts

The important takeaway is that saying "Liferay doesn't support OIDC Single Logout" is no longer accurate.

Beginning with Liferay DXP 2026.Q1, Liferay supports the OpenID Connect Back-Channel Logout specification, allowing standards-compliant OpenID Providers to securely terminate authenticated portal sessions without relying on browser redirects or provider-specific integrations.

If your organization already uses OpenID Connect for Single Sign-On, enabling Back-Channel Logout helps ensure that when the user's central authentication session ends, their Liferay session ends as well. That's an important improvement for both security and operational consistency across multiple applications.

Support for RP-Initiated Logout would make the logout story even more complete, but the existing Back-Channel Logout implementation already addresses one of the most important challenges in federated authentication: keeping application sessions synchronized with the identity provider.

As more organizations adopt centralized identity platforms, standards-based logout becomes just as important as standards-based login. It's good to see Liferay continuing to build on the OpenID Connect specifications in a way that improves interoperability while remaining provider agnostic.

For more information, check out Liferay's documentation for OIDC.

Bringing Liferay to Cross-platform Development

2026-08-05T14:11:00Z

Liferay already provides a mature platform for content, permissions, users, sites, workflows, and headless APIs. What has been missing is a practical way to use that platform as the backend for a modern application.

Liferay previously offered dedicated mobile libraries, but those tools were ultimately deprecated or removed in favor of Headless Delivery. That was probably the right architectural move, even if retiring the mobile SDK without replacing the developer experience left a pretty obvious gap. API-first competitors such as Contentful have already shown why separating the backend from the presentation layer makes sense.

KDXP is intended to fill that gap: not by bringing back another platform-specific mobile SDK, but by providing a Kotlin Multiplatform framework over Liferay’s headless APIs for Android, iOS, desktop, and web.

The gap is obvious: searching YouTube for “Liferay Kotlin” currently returns the KDXP setup demo on the first page. Searching for “Liferay multi-platform” does the same.

Those results do not mean KDXP is finished. They do suggest that developers looking to combine Liferay with modern cross-platform development currently have very few options.

The first setup demo walks through connecting KDXP to a local Liferay installation, configuring OAuth, and creating an application-backed site.

Watch the KDXP Liferay Setup demo:
https://youtu.be/mlPIv3XQ-GY?si=aSFYDsVCN0vhPTLd

This is the first step toward giving Liferay developers a shared application layer across Android, iOS, desktop, and web.

YouTube results captured August 4, 2026.

Connect with me on LinkedIn:
https://www.linkedin.com/in/nestorledon/

No More Rebuild-and-Redeploy: Instant Hot Reload for Liferay React Client Extensions

2026-08-02T23:42:05Z

The Rebuild-and-Redeploy Loop Every Client Extension Developer Knows

If you've built a React-based client extension (CX) for Liferay DXP, you know this rhythm well.

You tweak a component - adjust some padding, change a label, wire up a new prop. You save the file, switch to your terminal, and kick off a build. Gradle picks it up, packages it into a client extension bundle, and pushes it to your running Liferay instance. Twenty or thirty seconds later, sometimes more depending on your machine and workspace size, it's finally deployed. You switch back to the browser, hard-refresh, and check whether the padding looks right.

It didn't. So you do it again.

Multiply that by the dozens of small adjustments that go into any real UI, and the wasted time adds up fast. An afternoon of front-end polish can turn into an afternoon of watching a progress bar.

This isn't really a Liferay problem - it's what frontend development looked like everywhere before tools like Vite made Hot Module Replacement (HMR) the default. Most React developers left that world behind years ago. Client extension developers are still living in it by default, because a client extension isn't a standalone web app you serve yourself. It's a bundle Liferay loads from a URL declared in client-extension.yaml, and that bundle only changes when you rebuild and redeploy it.

Liferay Already Gives You the Fix — Here's Where It Stops

To be fair, this isn't an unsolved problem. Liferay's own frontend team has documented a way to skip the redeploy step, using a file called client-extension.dev.yaml. Instead of pointing your custom element's entry at a bundled production file, you point it at your local Vite dev - server http://localhost:5173, say , so Liferay loads the source straight from Vite while you work.

That alone is worth doing: no more waiting on Gradle for every change. But if you've tried it, you've probably noticed it doesn't fully deliver on the promise of HMR.

For plain JS or CSS, it behaves close to what you'd expect. For a React custom element, saving a file still triggers a full page reload instead of an in-place swap of just the component you changed. You lose whatever state you were looking at, and you don't get the sub-second feedback loop Vite is known for elsewhere.

Getting genuine component-level HMR — the kind where only the changed component re-renders and state survives means adding Vite's client script and a small React Refresh runtime shim as their own dev-only entries, loaded in a specific order, on top of the dev.yaml file. It works, but it's fiddly, and it's boilerplate you end up rewriting for every client extension in your workspace.

Two other things tend to bite people once a project grows past a single extension:

Port collisions. Every client extension wants its own Vite dev server. With five, ten, or twenty of them in the same workspace not unusual on a larger DXP project - you end up manually tracking which port belongs to which project so they don't collide.
Imports that only make sense at runtime. Some packages your custom element imports things like @liferay/oauth2-provider-web/client, or shared @clayui components — aren't meant to live in your local node_modules. In production, Liferay serves them once from a shared registry so every client extension on the page reuses the same instance instead of shipping its own copy. Vite's dev server doesn't know that convention exists. The moment your code imports one of those packages, Vite either can't resolve it or bundles a second, disconnected copy of something that's supposed to be a singleton.

None of this is exotic. It's documented, and any experienced CX developer can wire it up by hand. The problem is that "by hand" means redoing a multi-step setup, correctly, for every extension, on every project, indefinitely.

Introducing liferay-cx-hmr-setup

We built liferay-cx-hmr-setup, an npm CLI tool, to take care of all of that in one pass. Run it once against your Liferay workspace, and it configures instant, component-level HMR for every React client extension it finds — no hand-written YAML, no manually authored refresh scripts, no port spreadsheet.

bash

npx liferay-cx-hmr-setup

From that point on, your regular npm run dev behaves the way you'd expect from any modern React project: save a file, see the change on the actual Liferay page in well under a second.

How It Works, In Plain Words

Here's what happens when you run the CLI:

It scans your Liferay workspace and finds every client extension built with Vite.
For each one, it checks which local ports are already claimed by neighboring extensions and assigns the next free one.
It generates or updates that extension's client-extension.dev.yaml, pointing its entries at localhost on the assigned port.
It adds a small dev-only preamble script and registers it to load ahead of your main entry point, so Vite's client and the React Refresh runtime are ready before your component code runs.
It updates vite.config for that project: turning on CORS so the portal's origin can load it, and registering a plugin that recognizes Liferay-provided imports and leaves them for the browser to resolve at runtime instead of bundling them.

None of this is a new mechanism — it's the same dev.yaml and Vite dev server approach Liferay already supports. The tool just handles the repetitive, error-prone parts of setting it up so you're not redoing them by hand for every extension.

What Gets Set Up Automatically

Automatic Port Allocation Across Your Whole Workspace

On a workspace with a couple of client extensions, hand-assigning ports isn't a big deal. On one with fifteen or twenty, it becomes its own small chore, and it's easy to introduce a collision without noticing until two dev servers refuse to start at the same time.

The CLI handles this by checking every neighboring client extension project, reading which ports are already taken, and picking the next open one: 5173, 5174, 5175, and so on. That port gets written into both the extension's Vite config and its client-extension.dev.yaml, so the two never drift out of sync. Scaffold a new client extension later, run the CLI again, and it slots in without disturbing anything already running.

Letting Liferay's Runtime Packages Do Their Job

Rather than making you manually mark specific imports as external in vite.config, the tool ships a small Vite plugin that recognizes packages Liferay provides at runtime and leaves those import statements alone instead of trying to resolve or bundle them locally.

That matters because these packages are either missing from your local node_modules entirely, or present only as a type-checking dependency, not something meant to be duplicated inside your bundle. With the plugin in place, your dev environment resolves those imports the same way production does, against whatever Liferay has published for the page, instead of a second, disconnected copy Vite tried to guess at.

Zero-Config Wiring: dev.yaml, the Refresh Preamble, and CORS

This is the part that used to take the most trial and error. The CLI generates client-extension.dev.yaml for the extension, along with the small refresh script it points to, and makes sure the refresh entry loads ahead of the client entry — order matters here, and it's an easy detail to get backwards by hand. It also turns on the CORS headers your Vite dev server needs so the browser doesn't block requests coming from the portal's origin, and links the externals plugin from the previous section into your vite.config automatically.

Run the CLI again after scaffolding a new client extension, and all of this gets set up for the new project too. You're not maintaining a growing pile of hand-edited config as the workspace grows.

Getting Started

You'll need a React client extension project that already uses Vite as its bundler (the standard approach since Create React App was deprecated), Node and npm installed, and a Liferay DXP instance you can reach locally.

1. Run the CLI

bash

npx liferay-cx-hmr-setup

This scans your workspace and configures every Vite-based client extension it finds, as described above.

2. Deploy the Dev Manifest

bash

./gradlew :client-extensions:my-cx:deployDev

This tells Liferay, for this extension, to load whatever's being served from your local Vite dev server instead of the last built bundle. You only need to re-run this if the extension's entries or assigned port change, not for ordinary code changes.

3. Start Coding

bash

npm run dev

Vite boots on the port assigned to that extension. Open the page where the extension is placed, keep it next to your editor, and change something small — a color, a string of text. It updates before you've moved your cursor back to the browser window.

Component edits swap in place with state preserved wherever React Refresh can manage it. CSS updates apply immediately, with no reload at all.

What This Changes About Your Day-to-Day

The time savings compound quickly on any project with real UI work. Instead of a 20–30 second round trip for every change, you get the sub-second feedback loop of a standalone React app, which matters most exactly when you need it most: while you're iterating on layout, spacing, and visual details that take several attempts to get right.

It also removes friction when onboarding someone new onto a CX-heavy codebase. Instead of walking them through hand-writing dev YAML and refresh scripts for their first extension, you point them at one command.

Importantly, none of this touches your production path. client-extension.dev.yaml, the preamble script, and your Vite dev config are all dev-only additions. Your actual client-extension.yaml and the Gradle build your CI/CD runs stay exactly as they were. Turning this on for local development carries no risk to what actually ships.

Give It a Try

liferay-cx-hmr-setup is a new tool, available now on npm, built to solve the exact friction we kept running into on our own client extension-heavy projects. If you try it and hit a rough edge, or think of a feature that would make it more useful, we'd like to hear about it.

Every report and suggestion helps make this more useful for the next team building React client extensions on Liferay.

Service Builder Compatibility Matrix

2026-07-31T18:51:50Z

Why This Matters

When you update Blade CLI and create a new Liferay Workspace, the generated workspace normally uses the latest Liferay Workspace Gradle plugin. That plugin selects versions for a number of supporting build tools, including the Service Builder plugin.

For new projects targeting the latest Liferay release, this is usually what you want.

The detail worth paying attention to is that Service Builder generates Java code against the service APIs and conventions of a specific Liferay release line. As Liferay evolves from one quarterly release to another, such as from 2026.Q1 to 2026.Q2, the service tier can change.

The latest Service Builder plugin knows how to generate code for the latest platform version, but that does not always mean it is the right choice for an older target platform.

For example, if your workspace is targeting 2024.Q1, using the newest Service Builder plugin may generate service code that does not line up with the APIs available in that Liferay version.

The important point is simple:

Your Service Builder plugin version should match the Liferay DXP version you are targeting in your workspace.

The Compatibility Matrix

The Developer Experience team at Liferay has put together the following compatibility chart. Use it to select the Service Builder plugin version that corresponds to the Liferay quarterly release configured in your workspace.

Liferay Quarterly Version	Service Builder Version
`2023.Q3`	`1.0.463`
`2023.Q4`	`1.0.470`
`2024.Q1`	`1.0.478`
`2024.Q2`	`1.0.485`
`2024.Q3`	`1.0.488`
`2024.Q4`	`1.0.490`
`2025.Q1`	`1.0.496`
`2025.Q2`	`1.0.503`
`2025.Q3`	`1.0.510`
`2025.Q4`	`1.0.513`
`2026.Q1`	`1.0.514`
`2026.Q2`	`1.0.532`

The Service Builder version listed for a quarterly release applies to the patch releases within that quarterly release line.

How To Choose The Right Version

Start with the Liferay version your workspace is targeting.

In a Liferay Workspace, this is typically configured in gradle.properties using the liferay.workspace.product property:

liferay.workspace.product=dxp-2024.q1.10-lts

The quarterly release portion of that value is the part you need to match against the table.

Workspace Target Platform	Quarterly Release	Service Builder Version
`dxp-2024.q1.10-lts`	`2024.Q1`	`1.0.478`
`dxp-2026.q1.8-lts`	`2026.Q1`	`1.0.514`
`dxp-2026.q2.0`	`2026.Q2`	`1.0.532`

Once you know the matching Service Builder version, pin it in the same gradle.properties file:

com.liferay.portal.tools.service.builder.version=1.0.478

So a workspace targeting 2024.Q1 might include:

liferay.workspace.product=dxp-2024.q1.10-lts
com.liferay.portal.tools.service.builder.version=1.0.478

After changing the property, rebuild your Service Builder modules as usual:

blade gw buildService
blade gw jar

Or, if you prefer compiling directly:

blade gw buildService
blade gw compileJava

NOTE: If you have previously generated the service classes but didn't specify the right version of the SB plugin, you should clear out all of the generated code. The buildService task does not see a change in plugin version as a reason to regenerate a class, only a change to service.xml or. one of the impl classes will do that, and only targeted to those classes that need to be updated as a result of the change. Purging all of the previously generated classes will ensure that SB generates all of the right classes for your version of Liferay DXP.

When To Recheck The Matrix

You should recheck this matrix whenever you change your workspace target platform.

For example, if you move from:

liferay.workspace.product=dxp-2024.q1.10-lts

to:

liferay.workspace.product=dxp-2026.q2.0

then you should also update:

com.liferay.portal.tools.service.builder.version=1.0.532

The target platform and Service Builder version should move together. Treat them as related build configuration, not as independent settings.

Practical Workflow

Set or update liferay.workspace.product.
Find the matching quarterly release in the compatibility matrix.
Pin com.liferay.portal.tools.service.builder.version to the matching version.
Run buildService.
Compile the module.
Commit both the generated service code and the workspace configuration change together.

That last point matters. If generated Service Builder code changes because the plugin version changed, future maintainers need to see the configuration change that explains why the generated code changed.

Looking Ahead

The Liferay Dev Tools team is working on ways to make this selection automatic in the future. A future version of Blade CLI, the Liferay Workspace plugin, or both may be able to select the appropriate Service Builder version based on the configured target platform.

Until then, this matrix gives you a practical way to avoid generating service code that does not align with your Liferay DXP version.

Batch Imports Audit

2026-07-29T12:05:29Z

Introduction

Liferay's Batch Engine is the workhorse behind bulk data movement into Liferay. Instead of creating records one REST call at a time, you POST (or PUT, or DELETE) an array of items to a /batch endpoint for the entity you care about — Objects, Commerce catalogs, channels, product specifications, whatever — and the Batch Engine takes it from there. It queues the work as an asynchronous import task, processes the records, and updates that task's status as it goes, from INITIAL through to COMPLETED (or FAILED).

That async, fire-and-forget model is exactly what you want when an external system needs to push thousands of records into Liferay without waiting around for a synchronous response. It's also exactly what makes the next question so important: once you've fired that batch off, how do you know what actually happened to it?

Problem Overview

This came up for real on a large-scale B2B commerce project we've been building. The setup is a common one:

Product data — categories, specifications, products, pricing, you name it — lives in an external PIM system, not in Liferay.
An integration middleware layer owns the sync: it reads from the PIM and calls Liferay's Headless Batch APIs to push data in.
Liferay is the consumer, not the source of truth. From Liferay's side, batches just show up.

And, inevitably, some of those batches fail. The reasons vary:

Invalid data — a field that doesn't match the expected format or type;
Duplicate data — an external reference code or any other field that's already in use;
Internal Batch Engine errors — timeouts, constraint violations, anything else that can go wrong mid-import.

Here's the problem: Liferay doesn't ship a UI for any of this. When the middleware team says "we pushed 500 products and something failed," the only way to find out what, exactly, is to go spelunking through application logs or query the database directly — and that's assuming you have that kind of access to a client's environment in the first place.

But Liferay already has the answer. Every batch import task the Batch Engine runs is persisted — its status, timing, item counts, and errors — in its own tables (BatchEngineImportTask and BatchEngineImportTaskError). The data we needed was sitting right there. It just wasn't visible to anyone.

Solution Overview

So we built Batch Import Audit: a Control Panel tool that puts the Batch Engine's own record-keeping in front of the people who actually need it — support engineers, integration developers, and admins — without anyone touching a database client.

The tool adds a new Monitoring category to the Control Panel, with a Batch Import Audit app underneath it. Conceptually, the relationship to the underlying data is simple:

BatchEngineImportTask the source for the main list: one row per import task, with its class name, execute status, initiating user, start/end time, and total vs. processed item counts.
BatchEngineImportTaskError is the source for what went wrong: when a task fails, this is where the record-level detail lives — which item failed, and why.

The list view gives you every import task the Batch Engine has ever run, newest first, with filters for:

Initiator — which user (or integration account) triggered the import
Execute Status — e.g. completed, failed, in progress
Class Name — which entity type was being imported (catalogs, channels, products, etc.)
External Reference Code — find the task that touched a specific record, by its ERC

The details view is where the actual troubleshooting happens. Open any task and you get its full metadata — batch size, content type, import strategy, operation, timing — along with the original request payload, unpacked and pretty-printed exactly as it was submitted. For failed tasks, this is also where the task-level error information and the underlying error records surface, so you can see not just that something failed, but which record and why, without ever leaving the browser.

You can view and easily copy the task content of the failed batch import task, to analyze it separately: in your IDE or using AI.

If you want to find out when/how a specific entity was imported - you can perform a search using it's ERC field, and see the task details:

Summary

For any project where Liferay is on the receiving end of a data pipeline it doesn't control — PIM systems, ERPs, legacy migrations — batch import failures aren't a matter of if, they're a matter of when. Batch Import Audit doesn't change how the Batch Engine works; it just makes the information the Batch Engine was already recording actually visible, so troubleshooting a failed import is a filter and a click instead of a support ticket and a database query.

If you're dealing with the same kind of integration setup and this looks useful, the code is available in this repo — take a look, adapt it, or open an issue with questions, feedback, or ideas for where it should go next.

Leave your comments and feedback.

Stand with Ukraine

Enjoy 😏

Vitaliy Koshelenko

Liferay DXP Architect at Solteq

vitalii.koshelenko@solteq.com

Installing Liferay DXP 2026.Q1 on Red Hat JBoss Web Server 6.2.3

2026-07-30T16:59:19Z

Liferay’s official Tomcat installation guide is a useful starting point, but it is not quite enough for installing Liferay DXP 2026.Q1 on Red Hat JBoss Web Server 6.2.3.

The reason is straightforward: JBoss Web Server is Tomcat, but it is Red Hat’s supported Tomcat distribution, and the current Liferay documentation contains a few assumptions that do not line up cleanly with a modern 2026.Q1 install.

I've reported these issues, so by the time you go looking, they might be fixed...

In this post, we will install Liferay DXP 2026.Q1 on JWS 6.2.3 using RHEL 10 as the reference operating system. The same pattern applies to other Linux distributions, but the package manager and service integration details will vary.

Liferay DXP 2026.Q1 download options: WAR, OSGi dependencies, admin tools, and the Tomcat bundle.

Well, that was the plan until I found you can't get a developer download of JWS. Instead, we're going to use Apache Tomcat 10.1.57 and rename the directory to JWS to pretend it's the real deal.

Why JBoss Web Server?

When someone asks for “JBoss” in the context of a Tomcat-based Liferay deployment, they may not mean JBoss EAP. They may mean Red Hat JBoss Web Server (JWS).

JBoss Web Server is a separate Red Hat middleware product. Under the covers, JWS 6.x includes Apache Tomcat 10.1, Apache HTTP Server integration options, production-ready connectors such as mod_cluster, Tomcat native libraries, APR, OpenSSL integration, and Red Hat’s middleware support lifecycle.

This matters for enterprise environments because many organizations standardize on Red Hat-supported middleware even when the upstream runtime is Apache Tomcat. They may need:

A fully supported Tomcat 10.1 runtime.
Longer enterprise compliance windows.
Red Hat support channels.
Supported Apache HTTP Server connector integration.
FIPS or hardened runtime requirements.
Standardized deployment through RHEL subscriptions, archives, or container images.

For RHEL 10, Red Hat also provides a Tomcat 10.1 package directly through the operating system. JWS is still relevant when the client’s middleware standard is Red Hat Middleware Runtimes rather than base RHEL packages.

Version Alignment

Before touching files, get the compatibility story clear.

Liferay DXP 2026.Q1 supports Tomcat 10.1 and RHEL 10. JWS 6.x provides Tomcat 10.1, so the servlet container version lines up.

The Java version is where older documentation can mislead you. The Liferay Tomcat install page currently shows a Java 8 example in setenv.sh. Do not use that for 2026.Q1. For this installation, use JDK 21.

JWS 6.x supports multiple modern Java versions, but Liferay 2026.Q1 should be run on JDK 21. Do not let the server default to a newer Java such as JDK 25, and do not copy older Java 8 examples from older Liferay documentation.

Liferay 2026.Q1+ is only compatible with JDK 21, no exceptions.

On RHEL 10:

$ sudo dnf install java-21-openjdk-headless unzip tar
$ sudo alternatives --config java
$ java -version

On other distributions, the equivalent commands are usually:

# Debian or Ubuntu
$ sudo apt install openjdk-21-jdk-headless unzip tar

# SUSE
$ sudo zypper install java-21-openjdk-headless unzip tar

# Fedora
$ sudo dnf install java-21-openjdk-headless unzip tar

The important part is not the package manager. The important part is that the runtime used by JWS is Java 21.

Downloads

Download these Liferay files:

DXP WAR
OSGi Dependencies
Admin Tools
Bundled with Tomcat

The Tomcat bundle is not the runtime we are deploying, but it is still useful. It shows the directory structure, scripts, ROOT.xml, and runtime assumptions Liferay expects when it owns the Tomcat layout. All of the locations, contents, etc for the Liferay Tomcat bundle works, so if you have local issues, comparing your installation to the Liferay Tomcat bundle can often expose differences that might be contributing to the issues.

For separate installation of JWS, use the Red Hat Customer Portal:

Create or use a Red Hat Developer account.
Confirm that your account has access to the no-cost Individual Developer Subscription or the client’s Middleware Runtimes subscription.
Go to Red Hat Customer Portal downloads.
Select Red Hat JBoss Web Server.
Download the JWS 6.2.3 application server archive.

I'm testing locally on my Mac, so the generic JWS application server ZIP is usually enough because the Tomcat runtime itself is Java-based. For other Linux platforms, you might want the native component downloads if you are specifically testing platform-native Apache HTTP Server integration, APR, OpenSSL, or connector behavior.

Target Layout

The official Liferay Tomcat page assumes that Liferay Home is the parent directory of the Tomcat folder. That works for the Liferay-provided Tomcat bundle, but it is not always the best fit for JWS.

For this install, use explicit paths:

/opt/jws-6.2.3              JBoss Web Server installation
/opt/jws-6.2.3/tomcat       Tomcat runtime
/opt/liferay                Liferay Home

As indicated earlier, I'm using Apache Tomcat 10.1 since I can't get a JWS download. I manually created the /opt/jws-6.2.3 directory, exploded the apache-tomcat-10.1.57.tar.gz file I downloaded and renamed the directory to tomcat to match what JWS would have.

I prefer /opt/liferay for Liferay Home because it keeps Liferay’s mutable runtime data separate from the application server installation. Because of the runtime directory updates, you might also consider /var/run/liferay or something similar.

Create the Liferay Home structure:

$ sudo mkdir -p /opt/liferay/{data,deploy,license}
$ sudo mkdir -p /opt/liferay/{logs,osgi,tools}
$ sudo chown -R tomcat:tomcat /opt/liferay

If the tomcat user does not exist yet, create it first:

$ sudo groupadd -g 53 -r tomcat
$ sudo useradd -c "tomcat" -u 53 -g tomcat \
  -s /sbin/nologin -r tomcat

Red Hat’s JWS post-install scripts can also create and configure the service user when using the archive installation flow.

Install JBoss Web Server

Extract the archive:

$ sudo unzip jws-6.2.3-application-server.zip -d /opt
$ sudo chown -R tomcat:tomcat /opt/jws-6.2.3

Set a few working variables while installing:

$ export JWS_HOME=/opt/jws-6.2.3
$ export CATALINA_HOME=$JWS_HOME/tomcat
$ export CATALINA_BASE=$CATALINA_HOME
$ export LIFERAY_HOME=/opt/liferay

If you want systemd management on RHEL, run the JWS post-install script:

$ cd /opt/jws-6.2.3/tomcat
$ sudo sh .postinstall.systemd
$ sudo systemctl enable jws6-tomcat.service

If you're using your package manager to install JWS, you may actually have pieces installed in separate locations. The CATALINA_HOME environment variable where the static files and binaries are installed and CATALINA_BASE environment variable where dynamic, changeable components are installed (like the web apps that are deployed) will be set up by the installation, you won't have to set them yourself, but you'll have to know about them to install the right parts in the right places. It will also handle the systemd service setup, but you'll need to do the service enabling.

You'll still do the LIFERAY_HOME setup stuff.

JWS Tomcat Cleanup

We're going to be replacing the ROOT web application with Liferay's app, so if there's an $CATALINA_BASE/webapps/ROOT folder, you're going to want to delete it. Check out the other web apps that might be in that folder, you may want to purge those as well.

Install Liferay Files

Expand the OSGi dependencies into Liferay Home:

$ sudo unzip liferay-dxp-osgi-*.zip -d /opt/liferay/osgi
$ sudo chown -R tomcat:tomcat /opt/liferay/osgi

Install the tools somewhere predictable:

$ sudo unzip liferay-dxp-tools-*.zip \
  -d /opt/liferay
$ sudo chown -R tomcat:tomcat /opt/liferay/tools

If you have artifacts to deploy such as a DXP license file, OSGi modules or portlet war files, themes, etc. you can put them in /opt/liferay/deploy for Liferay to pick up when it starts.

Now deploy the DXP WAR as the root web application:

$ sudo rm -rf $CATALINA_BASE/webapps/ROOT
$ sudo mkdir -p $CATALINA_BASE/webapps/ROOT
$ sudo unzip liferay-dxp-*.war -d $CATALINA_BASE/webapps/ROOT
$ sudo chown -R tomcat:tomcat $CATALINA_BASE/webapps/ROOT

Configure Liferay Home Explicitly

Do not rely on Liferay guessing the correct home directory.

Create /opt/liferay/portal-ext.properties:

liferay.home=/opt/liferay

Then pass the same value as a JVM system property (in setenv.sh as shown below). This avoids startup timing problems and makes the location obvious from the process definition:

-Dliferay.home=/opt/liferay

In production, portal-ext.properties will usually also contain database settings, mail settings, clustering-related settings, and environment-specific configuration.

liferay.home=/opt/liferay

jdbc.default.driverClassName=org.postgresql.Driver
jdbc.default.url=jdbc:postgresql://db.example.com:5432/lportal
jdbc.default.username=liferay
jdbc.default.password=change-me

Do not use the bundled Hypersonic database outside local testing.

Configure `setenv.sh`

This is one of the places where the official documentation is incomplete for modern Java.

Your JWS Tomcat bin/setenv.sh should include the normal Liferay memory and runtime options, but it also needs the Java module access flags required by Liferay on Java 21.

Create or update:

/opt/jws-6.2.3/tomcat/bin/setenv.sh

Use this as a starting point:

# Ensure use of JDK21 for Liferay/Tomcat
export JAVA_HOME=/usr/lib/jvm/java-21-openjdk
export PATH="$JAVA_HOME/bin:$PATH"

# Set this to your real liferay home. Exporting as
# an environment var ensures visibility within the
# running process.
export LIFERAY_HOME=/opt/liferay

CATALINA_OPTS="$CATALINA_OPTS -Dfile.encoding=UTF-8"
CATALINA_OPTS="$CATALINA_OPTS -Djava.net.preferIPv4Stack=true"
CATALINA_OPTS="$CATALINA_OPTS -Duser.timezone=GMT"
CATALINA_OPTS="$CATALINA_OPTS -Dliferay.home=$LIFERAY_HOME"

CATALINA_OPTS="$CATALINA_OPTS -Xms2560m -Xmx2560m"
CATALINA_OPTS="$CATALINA_OPTS -XX:NewSize=1536m" 
CATALINA_OPTS="$CATALINA_OPTS -XX:MaxNewSize=1536m"
CATALINA_OPTS="$CATALINA_OPTS -XX:MetaspaceSize=768m"
CATALINA_OPTS="$CATALINA_OPTS -XX:MaxMetaspaceSize=768m"
CATALINA_OPTS="$CATALINA_OPTS -XX:SurvivorRatio=7"

export JDK_JAVA_OPTIONS="${JDK_JAVA_OPTIONS} \
 --add-opens=java.base/java.lang=ALL-UNNAMED \
 --add-opens=java.base/java.lang.invoke=ALL-UNNAMED \
 --add-opens=java.base/java.lang.reflect=ALL-UNNAMED \
 --add-opens=java.base/java.net=ALL-UNNAMED \
 --add-opens=java.base/java.util=ALL-UNNAMED \
 --add-opens=java.base/sun.net.www.protocol.http=ALL-UNNAMED \
 --add-opens=java.base/sun.net.www.protocol.https=ALL-UNNAMED \
 --add-opens=java.base/sun.util.calendar=ALL-UNNAMED \
 --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED \
 --add-opens=jdk.zipfs/jdk.nio.zipfs=ALL-UNNAMED"

Make it executable:

$ sudo chmod 750 /opt/jws-6.2.3/tomcat/bin/setenv.sh
$ sudo chown tomcat:tomcat /opt/jws-6.2.3/tomcat/bin/setenv.sh

The --add-opens arguments are not optional noise. Without them, Liferay may start with reflective access warnings or fail later when a code path hits Java’s stronger module boundaries.

Two things to note here...

First, the memory settings are just what Liferay uses for a vanilla demo environment. You may need to increase those to handle your expected capacity and load. Liferay provides a performance white paper where they provide a suitable starting set of JVM parameters for a production environment, but of course load testing and tuning are necessary to get the right settings for your environment.

Secondly, if you're using the systemd service to start/stop JWS, you might expect that you'd manage the environment and JVM parameters "the systemd way", but you'd be wrong. Per the Red Hat JWS 6.2 Installation Guide, you still apply Tomcat environment variables and JVM parameters in the setenv.sh script.

Configure Tomcat for Liferay

The Liferay Tomcat bundle is useful here. Compare its configuration files against the JWS Tomcat configuration and copy the relevant Liferay-specific pieces.

The important items are:

conf/Catalina/localhost/ROOT.xml
conf/catalina.properties
conf/server.xml
conf/web.xml
conf/logging.properties
scripts in bin/

The most important JWS-specific check is conf/catalina.properties.

Liferay’s support-tomcat.jar must be visible to Tomcat’s common class loader. Add it at the beginning of common.loader:

common.loader="${catalina.home}/webapps/ROOT/WEB-INF/
  lib/support-tomcat.jar",...

Also confirm that the HTTP connector in server.xml uses UTF-8:

<Connector
    port="8080"
    protocol="HTTP/1.1"
    connectionTimeout="20000"
    redirectPort="8443"
    URIEncoding="UTF-8" />

If you are fronting JWS with Apache HTTP Server, a load balancer, or OpenShift routing, also review proxy headers, secure scheme handling, and the connector strategy before putting the node behind real traffic.

Start and Validate

Start JWS:

$ sudo systemctl start jws6-tomcat.service
$ sudo systemctl status jws6-tomcat.service

Watch the logs:

$ sudo tail -f /opt/jws-6.2.3/tomcat/logs/catalina.out

Confirm these items during first startup:

Java reports version 21.
Liferay Home resolves to /opt/liferay.
OSGi modules are loaded from /opt/liferay/osgi.
The database connection is not using Hypersonic in production.
No startup failure points to missing Java module access.
support-tomcat.jar is visible through common.loader.
The portal is deployed as ROOT.

After logging in, confirm the resolved Liferay Home path from Control Panel:

Global Menu -> Control Panel -> Server Administration 
  -> Properties -> System Properties

Search for:

liferay.home

It should point to /opt/liferay.

Operational Notes

For production, the application server install is only part of the work.

You still need to decide how to manage:

Database backup and restore.
Document Library storage.
Search engine configuration.
TLS termination.
Reverse proxy headers.
Session strategy (Sticky sessions still recommended).
Clustering.
Marketplace and hot deploy policies.
Patch and quarterly update workflow.
SELinux context and filesystem permissions.
Systemd restart behavior and memory limits.

On RHEL systems with SELinux enabled, do not treat permissions as only Unix ownership. Validate SELinux contexts for any directory JWS needs to read or write, especially /opt/liferay, log directories, custom mounts, and shared storage.

Tradeoffs

Installing Liferay on JWS gives you a supported enterprise Tomcat runtime, but it also means you own more of the assembly.

The Liferay Tomcat bundle is easier because Liferay has already made the runtime decisions for you. JWS is more appropriate when the client’s platform standards require Red Hat middleware support, Red Hat packaging, or a supported Tomcat distribution that fits existing operational controls.

The cost is that you must be explicit:

Explicit Java version.
Explicit Liferay Home.
Explicit JVM options.
Explicit Tomcat common class loader configuration.
Explicit ownership and service management.

That is not a bad tradeoff, but it should be intentional.

Upgrades

So this is a considerable tradeoff. Using a Liferay Tomcat Bundle or Docker Image makes upgrading Liferay software "easy" (excludes work necessary for addressing your own customizations).

Under JWS, you're going to be doing much of this manually, but its not too complicated.

You still download the Liferay DXP war file, the OSGi dependencies zip and the tools zip.

Delete the contents of the $CATALINA_BASE/webapps/ROOT dir and expand the new war file like we did above.

The OSGi dependencies zip has to be handled with care. Delete the marketplace, portal, portal-war, state and static directories from /opt/liferay/osgi. The other folders will contain your own artifacts, you don't want to delete them or you discard your own deployed work. Unzip the OSGi dependencies zip like we did above.

Tools will also need to be handled with care. Your property files in the various /opt/liferay/tools directory will get clobbered when you unzip the tools zip. Copy them and restore them after unzipping the tools zip file.

You might also want to check the Liferay Tomcat bundle for changes in other key files like setenv.sh, catalina.properties, etc.

Final Thoughts

The main mistake to avoid is treating the Liferay Tomcat documentation as a complete JWS installation guide. It is a good reference, but for Liferay DXP 2026.Q1 on JWS 6.2.3 you need to correct three assumptions:

Use JDK 21, not the older Java examples.
Add the required Java --add-opens options.
Define Liferay Home explicitly instead of relying on the Tomcat parent directory.

Once those are handled, the deployment model is familiar: JWS supplies Tomcat 10.1, Liferay supplies the WAR and OSGi dependencies, and /opt/liferay becomes the stable runtime home for configuration, modules, logs, data, and operational tooling.

References

Beyond the Prototype: What’s New in the Liferay Fragments Repository

2026-07-23T13:49:00Z

The Evolution of the Library

When I wrote about scaling Liferay fragments with AI and automation earlier this year, the repository was already transitioning from a experimental lab into a structured UX library. The goal was simple: prove that custom fragment design could be accelerated using AI tools without sacrificing maintainability or performance.

Since then, the repository has expanded significantly in both scope and capability. What started as a modest collection of components and navigational experiments has grown into a comprehensive, community-driven resource for Sales Engineers, solutions architects, and frontend developers looking to deliver polished, production-ready Liferay DXP experiences without building every component from scratch.

Key Enhancements at a Glance

If you haven’t checked out the repo recently, here is what has changed behind the scenes:

1. Fully Verified for 2026 LTS

Every fragment in the collection has been systematically tested and validated against the latest 2026 LTS release. You can import these components into your modern environments knowing that markup, CSS classes, and Client Extension hooks are fully aligned with current platform standards.

2. Built-in Visual Gallery

Choosing the right fragment shouldn't require importing six different zip packages just to see how they render on a page. The repository now includes a Visual Gallery right in the documentation, allowing you to quickly browse visual previews, review layout options, and select exact components before touching your DXP instance.

3. Complete Backwards Compatibility

While the primary branch targets 2026 LTS, real-world deployment often involves supporting legacy or client-specific environments. The repository now maintains packaged, version-specific release archives to ensure seamless backwards compatibility across prior DXP versions.

4. Instant "Drop-and-Go" Deployment

We’ve retained and refined our automated zip-based release workflow. Download the packaged release file, place it straight into your DXP /deploy directory, and let the platform handle the rest — no manual import wizards required.

Featured Fragments to Explore

Here are a few of the standout components currently available in the collection:

Automated Meter Reading: A utility fragment built for industrial and utility use cases. It handles numeric input formatting, backspace logic, and auto-advancement out of the box, pushing data directly to Liferay Objects via callback functions.
Commerce Dynamic Badge Overlay: A real-time product overlay fragment that dynamically applies badges (such as New, Low Stock, or Featured) over Commerce product card components based on live data triggers.
Collection-Based Date Displays: Configurable date-mapping UI components that format and bind complex temporal data directly from asset collections and data providers.

How to Get Involved

This repository thrives when it reflects real customer scenarios and field requirements. Whether you’re preparing a high-impact demo or building out a custom portal, there are several ways to contribute:

Submit Pull Requests: Built a custom fragment for a recent prospect or client solution? Open a PR and share it with the wider ecosystem.
Suggest New Features: Have an idea for a component that would solve a common demo hurdle? Open an issue on GitHub or reach out directly with your concept.

Get Started Today

Stop reinventing the wheel on every project. Take a look through the visual gallery, grab the latest release, and drop these components into your next environment:

👉 Explore the Repository: github.com/peterrichards-lr/liferay-fragments

Liferay AI Hub Practical Recommendations: Agents, Instructions, Prompts & Guardrails

2026-07-22T16:23:41Z

I've recently been working on a project to create a Chatbot using AI Hub. Although the documentation at https://learn.liferay.com/w/ai-hub/integrating-ai-hub-with-liferay-dxp is very helpful at completing this task, there are some things that it leaves out. I thought these might be helpful to others, so I thought I'd share them here.

1. The building blocks (quick orientation)

When you're using AI Hub, you're going to be defining a bunch of different things:

Agent — a single task with its own workflow (a canvas of nodes). Built-in agents (Change Tone, Fix Spelling and Grammar, Improve Writing, Liferay Search, Make Longer, Make Shorter) are read-only; custom agents are yours to edit. An agent has input variable(s), one output variable, an optional set of data sources, and optional guardrails.

Instruction — a reusable block of guidance applied at runtime across many agents (tone, brand voice, policy). It carries a rule plus the response to give when the rule fires, and a scope (Everywhere / CMS only / Click-to-Chat only).

Guardrail — an enforced safety check that runs outside the model, so it holds even when a prompt tries to talk around it. Input guardrails screen the user message; output guardrails screen the model reply. Guardrails attach per-agent.

Data source — a crawled website (same domain, up to 3 link levels deep, max 500 pages) that agents query by semantic search. Attach to the agents that need grounded answers.

Supervisor (AI Assistant / Chatbot) — the router. The AI Assistant lives in the CMS editor; a Chatbot is a deployable widget scoped to a chosen set of Assigned Agents. Either one reads the request and routes it to the best-matching agent(s), and can combine agents for one request.

Titles and descriptions are functional, not cosmetic

Across all of AI Hub, an agent's title and description are the primary signal the supervisor uses to select it. Wherever a supervisor sits in front of agents (the CMS AI Assistant and every deployed chatbot alike), it compares the user's request against each available agent's title and description and routes to the best match. They are not just labels for humans: a vague or inaccurate description means the right agent may never be picked, while a sharp one that names the trigger and the result makes routing reliable. Treat writing them as part of building the agent, not an afterthought.

2. Agent vs. Instruction: which one to build

This is the most common design decision. The rule of thumb: an agent does work; an instruction shapes how all work is done.

If…	Then…
The user needs a discrete task performed (translate, summarize, search, generate)	Build an AGENT
You want a consistent rule applied across many agents (brand tone, "never give financial advice", always answer in the user's language)	Write an INSTRUCTION
The behavior needs its own inputs, output, data sources, or a multi-step workflow	Build an AGENT
The behavior is a one-line policy that shouldn't be copy-pasted into every prompt	Write an INSTRUCTION
You need enforcement that survives a cleverly worded prompt (PII, jailbreak, harmful output)	Add a GUARDRAIL (not an instruction)

Why it matters: instructions are defined once and reused, so they keep tone and policy consistent without editing each agent. Reserve new agents for genuinely new capabilities — every custom agent is a maintained asset (and, on some tiers, a limited one, e.g. up to five custom agents on Activate).

3. One forking agent vs. several agents the supervisor picks between

When a job has several branches (e.g. translate to Spanish, French, or German), you can build one agent with a large branching workflow, or several small single-purpose agents that a chatbot / the AI Assistant routes between. Prefer several focused agents.

Why separate agents usually win

Routing is what the supervisor is for. The AI Assistant and chatbots already compare the request to each available agent and pick the best match — even combining two (translate + shorten) for one request. Small, clearly-described agents make that routing accurate.
Descriptions drive selection. Each agent's title and description are how the supervisor decides. One giant forking agent has a single description, so the router can't see the branches inside it — a French request may never reach the French branch. Separate agents each advertise exactly what they do.
Simpler workflows, easier testing. A focused workflow is easier to reason about, duplicate, and debug than one canvas with many conditional paths.
Independent governance. Guardrails and data sources attach per-agent. Separate agents let you ground or lock down only the branch that needs it, instead of one agent carrying every rule.
Permissions and reuse. Per-agent permissions and reuse across chatbots are cleaner when each capability is its own agent.

When a single forking workflow is justified

The branches are internal steps the user should never pick between (e.g. detect language → normalize → translate as one pipeline).
The branches share heavy setup (same data sources, same pre/post-processing) and splitting would duplicate a lot of workflow.
You're near an agent-count limit and the branches are minor variations of one task.

Practical pattern: build one small agent per user-visible capability, give each a sharp description, assign the relevant set to a chatbot (or let the CMS AI Assistant see them), and let the supervisor route. Use forking inside an agent only for steps the user shouldn't have to name.

4. How to formulate an agent's prompt

An agent node has a Prompt (the LLM's standing instruction) and a User Message template that injects inputs via placeholders like {{text}}. Liferay's own example is a strong template — it works because it stacks four things:

Role — "You are an expert translator." Give the model a clear persona.
Scope — "Your sole task is to translate the provided text to Spanish…" State the one job and bound it.
Edge cases — "If the text is already in Spanish, return it unchanged." Name the tricky inputs and say what to do.
Output format — "Output only the translated text, with no explanations or commentary." Constrain the shape of the reply.

Recommendations: keep one job per agent (matches the routing model); write the prompt as standing behavior and put the variable content in the User Message template; reference inputs by their exact variable names; specify the output format explicitly (the supervisor may chain your output into another agent, so clean, comment-free output matters); and don't bake policy that belongs in a reusable instruction or a guardrail into the prompt.

Naming for routing: the description isn't decoration — it's how the supervisor finds the agent. Write descriptions that name the trigger and the result ("Translates text to French") rather than vague labels ("Language helper").

5. How to write instructions

State both halves. Every instruction is a rule plus the response when it fires — e.g. "Do not provide financial advice. If the user asks for investment recommendations, reply that you aren't authorized to give financial advice." Don't write the rule without the fallback response.
Scope deliberately. Set Where to Use — Everywhere, CMS only, or Click-to-Chat only — so a rule meant for the public chatbot doesn't reshape the authoring assistant.
Use the trigger when it should be conditional. Leave When to Use blank to apply to all in-scope requests, or set a contextual trigger to fire only in specific situations.
Write once, reuse. Put tone, brand voice, and cross-cutting policy in instructions rather than repeating them inside each agent prompt.
Remember precedence. Liferay's read-only system instructions take priority and can't be overridden by custom instructions — design around them, not against them.

The precedence rule has another important interpretation. Liferay’s read-only system instructions are the system-level prompts, instructions represent the your system-level prompts. They combine to constrain the agents from going off the rails regardless of what their individual prompts might be.

6. Adjusting guardrails

Guardrails run through Google Cloud Model Armor, outside the model; use them for anything that must hold regardless of prompt wording. Instructions ask the model to behave; guardrails enforce.

Input guardrails (screen the user message)

Malicious URI Filter — blocks harmful links.
Prompt Injection and Jailbreak Filter — catches attempts to override the agent's instructions.
Sensitive Data Protection — scans for and protects PII before it reaches the model.

Output guardrails (screen the model reply)

Set a Responsible AI threshold (None, Low and Above, Medium and Above, or High) for each of Hate Speech, Dangerous, Sexually Explicit, and Harassment. Higher categories block more aggressively.

Recommendations

Attach selectively. Guardrails apply per-agent and each run adds cost and latency. Put strict input guardrails on public, user-facing agents (chatbots on external sites); lighter rules may suffice for internal CMS authoring agents.
Pair input and output. Combine input screening (injection, PII, malicious links) with output screening (harmful/off-policy content) for full coverage.
Tune thresholds to audience. Raise output thresholds for public deployments; relax them where over-blocking would frustrate trusted internal users.
Enable multilanguage detection when non-English input is expected, so screening isn't limited to English.
Use guardrails, not prompts, for safety. Because they sit outside the model, guardrails hold even when a prompt tries to talk its way around the rule. Never rely on prompt wording alone for security-critical limits.

7. Set External Reference Codes (ERCs) with business meaning

Every AI Hub component (agents, chatbots, instructions, and the rest) carries an External Reference Code (ERC), a unique identifier used for system identification. By default this is an opaque UUID. Even if the ERC isn't something you interact with much today, set it to a value that carries business meaning rather than leaving the generated UUID in place.

For an instruction that governs response formatting, for example, prefer an ERC like <PROJECT>-RESPONSE-FORMATTING over a random UUID. The convention is cheap to adopt and pays off in several ways:

Readable and stable. A meaningful ERC is a durable, human-legible handle for the component: easier to reference in tickets, runbooks, and conversations than a UUID.
Portable across environments. A deterministic, business-meaningful code lets you line up the same logical component across dev, test, and production instead of reconciling different generated IDs.
Future-proofs for headless / API access. Plans for headless API access aren't confirmed, but if and when that day comes, a valid, well-chosen ERC is exactly the stable key an API call would target. Setting sensible ERCs now puts you ahead of the game rather than retrofitting them later.

Recommendation: adopt a simple, consistent ERC naming convention early, e.g. <PROJECT>-<COMPONENT-TYPE>-<PURPOSE>, and apply it to every agent, chatbot, and instruction as you create them, while the set is still small.

8. One-page cheat sheet

Goal	Do this
New capability / discrete task	Build a custom agent (duplicate a built-in, edit its workflow, use meaningful name and description for proper selection)
Same rule across many agents	Write an instruction (rule + response + scope)
Must-hold safety limit	Add a guardrail (input and/or output)
Ground answers in real content	Attach a data source and Sync Now
Several user-visible variants	Separate focused agents; let the supervisor route
Hidden internal branching	One agent, forking workflow
Deploy conversation to a page/site	Chatbot with a curated set of Assigned Agents
Writing help inside the editor	The CMS AI Assistant (built-in + custom agents)
Identify a component	Set a business-meaningful ERC (e.g. `<PROJECT>-RESPONSE-FORMATTING`), not a UUID
Watch spend	Track Liferay Tokens (LRT) balance on the Activity page

Conclusion

Hopefully these tips will help you make the most of your AI Hub agent building experience!

Leave a comment below if you have suggestions and/or questions.

KDXP: One Kotlin Codebase for Liferay Apps Everywhere

2026-07-16T01:28:45Z

Liferay already provides an impressive enterprise backend: authentication, users, roles, sites, documents, content, custom Objects, permissions, workflows, and headless APIs.

What it has lacked is a modern, unified client framework for building applications across every major platform.

That is the goal of KDXP.

KDXP is a Kotlin Multiplatform and Compose Multiplatform SDK that allows developers to build Android, iOS, Desktop JVM, and Web applications from one shared codebase.

Current capabilities include:

OAuth 2.0 Authorization Code + PKCE
Site discovery and switching
Liferay Objects
Documents and users
Manifest-driven branding and navigation
Role-aware navigation
Adaptive mobile, tablet, and desktop layouts
Site-aware deep links

The long-term vision is simple:

One codebase. All platforms. Powered by Liferay.

KDXP is currently in active development, and I am looking to connect with Liferay partners and enterprise teams interested in pilots, feedback, or collaboration.

Learn more:
KDXP for Liferay on LinkedIn

Contact:
Nestor Ledon

No More Guesswork: Deploy Your Liferay OSGi Modules in the Right Order, Automatically

2026-07-06T22:06:22Z

A Problem Every Liferay Developer Has Faced

If you have worked on a Liferay DXP project with more than a few custom modules, this scene will feel familiar.

You deploy all your modules together. Most of them start up without any trouble. But a few fail, and when you open the logs, you find a bundle that stopped right after it started.

The reason is almost always the same. One module tries to start before the module it depends on is even ready. Say your service module depends on your API module, and both get deployed at the same time. The service module may try to start first, find that the API module is not active yet, and simply fail.

The usual fix is to stop, work out the correct order by hand, and deploy the modules one at a time. It gets the job done, but it takes time, and it is a step you end up repeating with almost every build.

The Solution: A Plugin That Handles the Order For You

To take this manual work off your plate, we built a Gradle plugin called io.github.ankitt-29.deploy-ordered.

In simple terms, the plugin looks at your entire Liferay workspace, works out which module depends on which, and deploys everything in the correct order on its own. It does not stop at deploying and hoping for the best, either. It connects to Liferay's Gogo shell and confirms that every module has actually started successfully before moving on to the next set of modules.

The result: no manual restarts, no guessing which module should go first, and no repeated deploy attempts. Just one command, and the plugin takes care of the rest.

How It Works, In Plain Words

Here is the simple version of what happens behind the scenes:

It scans your workspace and finds every OSGi module you have.
It builds a dependency map, so it knows exactly which module needs which other module to be ready first.
It groups modules into waves. Modules with no dependencies go into Wave 1. Modules that depend only on Wave 1 modules go into Wave 2. This continues until every module has its place.
It deploys one wave at a time. The plugin drops a wave's modules into your Liferay deploy folder, waits a short while, and then checks the Gogo shell to confirm each one has reached the Active state (or Resolved, for fragment bundles). Only once a wave is confirmed healthy does it move on to the next one.

By the time any module starts, everything it depends on is already active and ready.

Before You Begin: Two Things to Set Up

Getting started needs just two small steps.

1. Enable the Gogo Shell

The plugin uses Liferay's Gogo shell to check whether your bundles are active. This shell is switched off by default, so you will need to turn it on once.

Open (or create) the portal-ext.properties file in your Liferay bundle, and add this line:

properties

module.framework.properties.osgi.console=localhost:11311

Restart your Liferay server after saving this file, and the Gogo shell will be ready to use.

2. Set Your Liferay Home Path

The plugin needs to know where your Liferay home is, so it can find your deploy folder. Add this path in your gradle.properties or gradle-local.properties file:

properties

liferay.workspace.home.dir=C:/liferay/liferay-dxp

Use the actual path to your own Liferay home folder here.

Once these two things are in place, you are ready to install the plugin.

Installing the Plugin

Add this small block to the root build.gradle file of your Liferay workspace:

groovy

plugins {
id 'io.github.ankitt-29.deploy-ordered' version '1.0.2'
}

That's it. There is nothing else to configure.

Running It

With the plugin installed, deploying your modules correctly is a single command away:

bash

./gradlew deployOrdered

Run this, and the plugin will scan, group, deploy, and verify every module for you, one wave at a time, until your whole workspace is up and running.

Before You Go

This is the first release of the plugin, version 1.0.2, and it is built with one goal in mind: to save Liferay developers the time and frustration that comes from manual module ordering.

It is open for the whole Liferay community to use, and being an early release, there is always room to make it better. If you try it out and have an idea, run into an issue, or think of a feature that would make it more useful, please do share it:

GitHub: https://github.com/ankitt-29/liferay-ordered-deploy
Gradle Plugin Portal: https://plugins.gradle.org/plugin/io.github.ankitt-29.deploy-ordered

Every suggestion helps make this a better tool for the whole community. Give it a try, and let us know what you think!

Beyond GET: Could HTTP QUERY (RFC 10008) Improve Liferay Headless APIs?

2026-07-06T22:16:39Z

Introduction

One of the biggest strengths of Liferay DXP is its Headless API ecosystem. Whether we're working with Custom Objects, Web Content, Documents, Commerce, or custom REST Builder APIs, Liferay provides well-designed REST endpoints that are easy to integrate with modern frontend applications.

For simple data retrieval, the existing APIs work extremely well.

For example:

GET /o/c/employees

Filtering is also straightforward:

GET /o/c/employees?filter=department eq 'IT'

However, as applications become more sophisticated, search requirements become significantly more complex. Dynamic filters, nested conditions, relationship queries, multiple sorting options, pagination, field selection, and AI-generated search requests can quickly turn a clean URL into something difficult to read and maintain.

Recently I came across RFC 10008, which introduces a new HTTP method named QUERY.

Although the RFC is still new and not yet widely supported by frameworks such as Spring Boot or Jakarta REST, it immediately made me think about Liferay Headless APIs and how this method could improve the developer experience in the future.

This article is not a proposal to replace existing APIs, but rather an exploration of how HTTP QUERY could fit naturally into Liferay's Headless ecosystem.

The Current Experience
Suppose we have a Liferay Object called Employee.

Today we retrieve records like this:

GET /o/c/employees

If we want filtering:

GET /o/c/employees?filter=(department eq 'IT' and salary gt 50000)

Sorting:

GET /o/c/employees?sort=name:asc

Pagination:

GET /o/c/employees?page=1&pageSize=20

Selecting fields:

GET /o/c/employees?fields=id,name,email

Liferay already provides excellent support for these features.

The challenge appears when all of these capabilities need to be combined into a single request.

A real-world URL may eventually contain:

complex filter expressions
nested logical operators
relationship filters
multiple sorting fields
pagination
selected fields
nested fields

The URL becomes increasingly difficult to understand.

Why GET Starts Showing Its Limits
GET requests were designed around URL parameters.

They work perfectly for small amounts of information.

But enterprise applications often require much richer search criteria.

Consider a dynamic search screen where users can create rules such as:

Department = IT
Salary > 50,000
Experience >= 5 years
Location = India
Status = Active

The frontend eventually has to generate a filter string similar to:

(department eq 'IT' and salary gt 50000 and experience ge 5 and location eq 'India' and status eq 'Active')
Now imagine adding multiple OR groups, relationships, date ranges, and custom object fields.

The filter quickly becomes difficult to read, difficult to debug, and difficult to generate programmatically.

The Common Workaround
Many REST APIs solve this problem by creating a search endpoint using POST.

For example:

POST /employees/search
{
  "department": "IT",
  "salary": {
    "gt": 50000
  },
  "experience": {
    "gte": 5
  }
}
Technically this works very well.

However, semantically, POST usually represents an operation that creates or processes resources.
Searching does neither.
We're simply retrieving data.

This is exactly the problem that RFC 10008 attempts to solve.

What is HTTP QUERY?
RFC 10008 introduces a new HTTP method called QUERY.

Unlike GET, QUERY allows a request body while still representing a safe, read-only operation.

For example:

QUERY /o/c/employees
Content-Type: application/json
{
  "department": "IT",
  "salary": {
    "gt": 50000
  }
}

Nothing is created.
Nothing is updated.
Nothing is deleted.
The request simply asks the server to return matching data.

Conceptually, this feels like a very natural fit for search operations.

How Could This Help Liferay?

Structured Search Requests

Instead of encoding complex logic inside URLs:

GET /o/c/employees?filter=(department eq 'IT' and salary gt 50000)
Developers could send structured JSON.

{
  "filter": {
    "department": "IT",
    "salary": {
      "gt": 50000
    }
  },
  "sort": [
    {
      "field": "name",
      "direction": "ASC"
    }
  ],
  "page": 1,
  "pageSize": 20
}
JSON is easier to generate, validate, and debug than long query strings.

2. Better Support for Dynamic Liferay Objects

One of Liferay's greatest strengths is that administrators can create Objects without writing code.

Every environment may have different:

object definitions
custom fields
relationships
picklists
validations

As these object models become increasingly dynamic, representing search criteria as structured JSON becomes much more natural than constructing long filter expressions.

3. Simpler Relationship Queries

Today relationship filtering often relies on filter expressions.

Imagine instead writing:

{
  "department": {
    "name": "Engineering"
  }
}

This structure is easier for developers to understand and aligns more closely with how object relationships are represented.

4. Better Low-Code Experience

Liferay promotes low-code application development.
Visual filter builders usually generate JSON internally.

Today the flow often looks like this:
UI
 ↓
JSON
 ↓
Convert to filter string
 ↓
GET request
--------------------------------------------------------------------
With QUERY the process could become:
UI
 ↓
JSON
 ↓
QUERY request

The conversion layer disappears.

5. Better AI Integration

As AI becomes part of enterprise applications, structured APIs become increasingly valuable.
Large Language Models naturally generate JSON.

Generating:

{
  "department": "IT",
  "salary": {
    "gt": 50000
  }
}

is generally simpler than generating complex filter syntax.
For future AI-powered Liferay applications, structured query bodies could provide a cleaner integration model.

6. Easier Validation

A structured request body can be validated using existing JSON validation techniques.
Instead of parsing long filter strings, APIs could validate request objects before executing searches.
This may simplify both server-side validation and client-side development.

If HTTP QUERY eventually gains widespread adoption across browsers, frameworks, API gateways, and OpenAPI tooling, it could become an interesting addition to Liferay's Headless platform.

Developers could continue using GET for simple retrieval while choosing QUERY whenever complex, structured search criteria are required.

Final Thoughts

RFC 10008 is still relatively new, and widespread adoption will likely take time.
However, reading the specification made me think about the future of Liferay Headless APIs.
As Liferay continues investing in Headless delivery, Custom Objects, low-code development, and AI-powered applications, the ability to express rich, structured, read-only searches through HTTP QUERY feels like a natural evolution.

Perhaps this isn't something Liferay should implement today.

But it is certainly an interesting conversation for the community.

I'd love to hear what other Liferay developers think.

Would HTTP QUERY make your Headless APIs easier to consume?
Would you use it for Custom Objects?
Do you see value in structured search requests over long filter expressions?

Let's discuss.

Smooth Sailing: Migrating Liferay DXP from 7.2 to 7.4 (2026 Q1)

2026-06-20T22:26:10Z

If you are planning this upgrade, here is your definitive, step-by-step technical playbook to take your local environment, database, and codebase from 7.2 to 7.4.

Phase 1: Environment & Local 7.2 Baseline Setup

Before jumping into the new version, you must recreate a stable, working baseline of your Liferay 7.2 environment locally.

1. Upgrade the Core Runtime

Liferay 7.4 (2026 Q1) demands modern Java infrastructure.

Task: Upgrade your Java development kit from JDK 8 to JDK 21.
Why? JDK 21 provides the long-term support (LTS) foundation required by modern Liferay bundles.

2. Restore the Local 7.2 Environment

To ensure a reliable migration, test the upgrade against a real data snapshot.

Database Dump: Download a fresh database dump from your Development environment.
Import Data: Restore this dump into your local MySQL instance.
Data Folder: Unzip and sync the data/ folder (which holds your document library and file store) from your 7.2 backup.
Initialize 7.2 Workspace: Download and unzip your matching Liferay 7.2.0 bundle, connect it to your imported database, and boot it up once to ensure everything resolves cleanly.

Phase 2: Preparing the Target 7.4 Environment

With the baseline established, it’s time to build the target framework.

Download the Target Bundle: Obtain the official Liferay DXP 7.4 2026Q1 bundle.
Unzip the Bundle: Extract it to your desired local directory (this will be your new $LIFERAY_HOME).
Initial Data Sync: Copy your existing data/ directory from the old 7.2 Tomcat installation directly into the new 7.4 Tomcat directory.

**Phase 3: Database Upgrade (MySQL 5.7 to 8.*)**

Liferay 7.4 thrives on MySQL 8.*. Upgrading your database topology safely requires a strict sequence:

Step 1: Pre-Upgrade Compatibility Checks

Before moving any data, use the MySQL Shell utility to ensure your 5.7 database won’t conflict with 8.* syntax or features. Run the following command:

Bash

mysqlsh –user=root –password –host=localhost –util checkForServerUpgrade –targetVersion=8.0.35 –outputFormat=TEXT

Step 2: Backup and Migrate

Create a Full Data Backup: Export a comprehensive .sql backup of your checked 5.7 database.
Spin up MySQL 8.*: Create a brand new MySQL 8.* instance (or Docker container).
Crucial Configuration: Ensure lower_case_table_names=1 is configured in your my.cnf or set as a flag when starting your MySQL 8.0 container.
⚠️ Warning: Failing to set lower_case_table_names=1 before database initialization can cause irreversible Liferay database schema mismatches on certain operating systems.
Import Data: Use DBeaver (or your preferred database client) to import your backup SQL directly into the new MySQL 8.* instance.

Phase 4: Executing the DB Upgrade Client

Instead of upgrading on the fly, use Liferay’s dedicated DB Upgrade Client tool for a controlled, visible schema migration.

1. Configure the Upgrade Properties

Navigate to: \liferay-dxp\tools\portal-tools-db-upgrade-client\ Create or edit the portal-upgrade-ext.properties file to point directly to your new MySQL 8.* instance:

Properties

liferay.home=../../

## MySQL Configuration

jdbc.default.driverClassName=com.mysql.cj.jdbc.Driver

jdbc.default.url=jdbc:mysql://localhost:3306/lportal?useSSL=false&characterEncoding=UTF-8&dontTrackOpenResources=true&holdResultsOpenOverStatementClose=true&serverTimezone=GMT&useFastDateParsing=false&useUnicode=true

jdbc.default.username=****

jdbc.default.password=****

2. Run the Client

Open your terminal, navigate to the tool folder, and execute the upgrade script:

Windows: db_upgrade_client.bat
Mac/Linux: ./db_upgrade_client.sh

Monitor the console logs closely for any schema errors or breaking changes.

Phase 5: Core Upgrade & Target Startup

Once the database schema is officially upgraded, prepare your 7.4 server properties for its maiden launch.

1. Environment Configurations

Copy over your key portal configuration files into the new environment, ensuring you update the paths, schemas, and credentials to reflect the 7.4 layout:

portal-ext.properties
portal-setup-wizard.properties

2. Force Auto-Run Check

Open your active portal-ext.properties file and append this property to ensure missing tables or data structures auto-repair on boot:

Properties

upgrade.database.auto.run=true

3. Clean Licenses & Prep Activation

Navigate to your synced data/license/ folder and remove all old .li licenses.
Deploy your new Liferay DXP 7.4 activation key into the deploy/ folder.

4. Start the Server & Reindex

Fire up the Liferay 7.4 Tomcat server. Once the server completes its startup sequences cleanly, navigate to the Control Panel > Search and trigger a full Reindexing of all modules to ensure your search indexes match the new data structures.

Phase 6: Code Upgrade

With the platform up and running, the final step is migrating your custom applications.

Copy your custom modules and applications from your older 7.2 workspace into the new 7.4 workspace structure.
Update your build.gradle dependencies to point to the 7.4 2026Q1 target platform BOM (Bill of Materials).
Address any deprecated APIs or breaking changes within your Java classes and OSGi modules, compile, and deploy!
1. Import workspace in intellij
2. Change the workspace target version gradle.properties

liferay.workspace.product=dxp-2026.q1.0

liferay.workspace.target.platform.version=2026.q1.0

Set gradle version to latest one in settings.gradle

dependencies {

classpath group: “com.liferay”, name: “com.liferay.gradle.plugins.workspace”, version: “15.0.0”

}

Set java version to 21 in Intellij

String pool

Replace import com.liferay.portal.kernel.util.StringPool;

With import com.liferay.petra.string.StringPool;

Build.gradle

Replace compileOnly group: “com.liferay.portal”, name: “com.liferay.portal.kernel”

With compileOnly group: “com.liferay.portal”, name: “release.dxp.api”, version:”default”

Replace import javax.servlet.http.HttpSession;

With import jakarta.servlet.http.HttpSession;

Replace import com.liferay.portal.kernel.search.generic.MultiMatchQuery;

With import com.liferay.portal.kernel.search.MultiMatchQuery;

Known issue with few modules

Error: Classes found in the wrong directory: {META-INF/versions/9/module-info.class=module-info}

Replace import com.liferay.portal.kernel.captcha.CaptchaUtil

With import com.liferay.portal.kernel.captcha.Captcha;

Replace ZipWriter zipWriter = ZipWriterFactoryUtil.getZipWriter();

With ZipWriter zipWriter = _zipWriterFactory.getZipWriter();

Add @Reference private ZipWriterFactory _zipWriterFactory;

Replace compileOnly group: ‘xml-apis’, name: ‘xml-apis’, version: ‘1.0.b.2’

With compileOnly group: ‘xml-apis’, name: ‘xml-apis’, version: ‘1.4.01’

Create a new service builder with the same name or different name using the same service.xml.
Implement all finders and impl methods from old service module impl
Keep version: “default” in the build.gradle file.
Rerun the build service task and deploy task

Conclusion

Migrating from Liferay 7.2 to 7.4 might seem daunting, but breaking it down into distinct phases—Environment Setup, Database Upgrades, Tools Execution, and Code Migration—ensures a predictable, successful deployment.

Take your time with the pre-upgrade checks, keep backups at every phase, and enjoy the massive benefits of Liferay 7.4!

CE is sunsetted. What's your next move?

2026-06-19T06:12:02Z

If you're using Liferay Community Edition (CE), or are an SI that has customers who do, you probably know (well, if you've been anywhere near this site this year you definitely know!) that the final version of Liferay CE was in early 2025, and that from the 2026.Q1 release of Liferay DXP we've made a Free Tier available to anyone that wants it.

But, what does this actually mean if you're using CE today? What are your options, and where do you go from here?

On June 30th I'll be hosting two identical webinars where we'll provide an open and honest view on the three (or four) paths that you could take, and to help you move ahead with confidence.

What you'll learn:

What actually changed. What the end of Community Edition means in practice for existing CE installations.
Your four options. Enterprise, Free Tier, GitHub self-build, or staying on CE — with honest pros and cons for each path.
Free Tier in depth. What’s included, what’s not, how activation keys work, and how to get started.
When Enterprise makes sense. Clear signals that your project has outgrown the Free Tier — and how straightforward the upgrade process is.
Active promotions. Available discounts and migration support through the Core Upgrade Program, including eligibility details.
Live Q&A. Ask questions during the session and get direct answers from the Liferay team.

When is the webinar?

It's taking place on Tuesday, June 30th. There are two identical sessions to cater for as many timezone as possible. Your options are:

Session A - EMEA/APAC	Session B - Americas
09:00 BST - London	2:00pm PDT - Los Angeles
10:00 CEST - Paris/Berlin	3:00pm MDT - Denver
12:00 GST - Dubai	4:00pm COT - Bogota
13:30 IST - Mumbai	6:00pm BRT - Sāo Paulo
16:00 SGT - Singapore	7:00am AEST - Sydney (July 1st)
18:00 AEST - Sydney	9:00am NZST - Auckland (July 1st)

How do I join?

Simple - just visit here and register for your preferred session!

What if I can't make it?

Register anyway - we'll be making a recording available after the session, and if you register but can't attend we'll make a special effort to let you know!

Cheers - see you all there!

Mission-Critical Email Delivery in Liferay

2026-06-20T22:25:47Z

A Simple Question

A customer recently reached out after experiencing a six-hour outage of their mail server.

The outage had nothing to do with Liferay. The platform was healthy. Their application was healthy. Business processes continued to run normally.

The problem was that some of those business processes generated emails.

Not marketing emails.

Not newsletters.

Mission-critical emails.

The outage raised an uncomfortable question:

What happens to those emails when the mail server is unavailable?

They're lost, I responded.

That quickly led to a follow-up question:

How can I guarantee email delivery from Liferay?

And I had to give them an honest answer:

You can't.

At least not using Liferay's standard email delivery implementation.

That answer surprised them, so let's talk about how email delivery works today and why solving the problem requires a different architectural approach.

How Liferay Sends Email

When a process in Liferay wants to send an email, it typically doesn't connect directly to the SMTP server.

Instead, Liferay creates a mail message and posts it to the Liferay Message Bus (LMB).

The LMB is Liferay's internal asynchronous messaging system. It allows work to be handed off from one thread to another, letting the original process continue without waiting for the email to be delivered.

This approach has several advantages.

The user doesn't wait for SMTP communication.
Business processes complete more quickly.
Email delivery happens asynchronously.

The important detail, however, is that the LMB is an in-memory messaging system. It is not a durable message broker.

If the SMTP server is unavailable, the failure is logged, but the message is discarded.

If Liferay crashes or is restarted while messages remain queued in the LMB, those queued messages are lost.

For most organizations this is perfectly acceptable. Password reset emails, notifications, subscription updates, and workflow messages can usually tolerate occasional failures.

Mission-critical messaging often cannot.

This Isn't Really a Liferay Problem

It's important to recognize that this isn't a flaw in Liferay.

The platform was designed around immediate email delivery. For the vast majority of deployments, that's exactly the right tradeoff.

The customer's problem wasn't really about email.

The customer's problem was about preserving an important business event until it can be processed successfully.

That's a messaging problem.

And when someone asks me how to make sure something gets done reliably, I immediately start thinking about durable messaging.

Reliable Delivery Starts with JMS

When someone asks me how to make sure something gets done reliably, I immediately start thinking about JMS.

JMS, or Java Message Service, is a standard messaging API used throughout enterprise Java applications. Rather than performing work immediately, applications can place a message onto a durable queue where it waits until a consumer is ready to process it.

That distinction is important.

Instead of asking:

Can I send this email right now?

We can ask:

Can I preserve the request to send this email until it can be processed successfully?

Those are very different questions.

With JMS, the email itself becomes a message placed onto a queue.

A separate process consumes messages from that queue and performs the actual work.

When combined with a durable messaging platform, this provides several advantages:

The message survives process restarts.
The message survives application crashes.
The message survives temporary infrastructure failures.
The message remains available until it is successfully processed.

That last point is the important one.

The queue doesn't care whether the SMTP server is currently available.

It simply holds the message until a consumer successfully processes it.

Of course, JMS itself is just an API and a programming model.

To actually store, manage, and deliver messages, we need a messaging platform behind it.

That's where an Enterprise Message Bus comes in.

Introducing an Enterprise Message Bus

For the proof of concept I chose Apache Artemis as the Enterprise Message Bus (EMB).

Artemis provides durable JMS queues, persistence, retry policies, dead letter queue support, monitoring, and operational tooling.

Note: If you're using the repo Docker composition, you're going to log into http://localhost:8161 with username mailuser and password mailpass.

The important point isn't Artemis specifically.

This same architectural pattern would work with RabbitMQ, ActiveMQ Classic, IBM MQ, Amazon MQ, Azure Service Bus, or any other enterprise messaging platform capable of durable message persistence.

Artemis simply worked well for the proof of concept and is easy to run locally using Docker.

Why Apache Camel?

Once the message is sitting in a durable queue, something needs to process it.

Apache Camel is not required for this solution.

A custom Java application could consume JMS messages and perform SMTP delivery directly.

A custom solution could even move template processing out of Liferay entirely and generate emails during message processing.

There are plenty of possibilities.

For this proof of concept, however, Apache Camel dramatically reduced the amount of code required.

One of the reasons I frequently pair an Enterprise Message Bus with Apache Camel is that Camel eliminates a tremendous amount of integration plumbing.

Without Camel, we'd need to write:

JMS consumer logic.
Transaction management.
SMTP integration.
Retry handling.
Connection management.
Error propagation.

Camel already knows how to consume JMS messages.

Camel already knows how to work with SMTP.

Camel already knows how to manage transactions.

For example, the route for processing the email via camel is a Java class defining the config:

public class MailRelayRoute extends RouteBuilder {
  @Override
  public void configure() {
    from("sjms2:queue:mail.outbound?connectionFactory" + 
        "=#artemisCF&transacted=true")
      .routeId("mail-outbound-relay")
      .log("Relaying message ${header.To}")
      .bean("smtpSender", "send");
  }
}

The resulting route is surprisingly small because Camel is hiding a large amount of infrastructure code we'd otherwise have to write ourselves.

For me, Enterprise Message Buses and Apache Camel go together like peanut butter and jelly.

The broker provides durability and reliable delivery.

Camel provides connectivity and routing.

Together they allow us to focus on business requirements instead of plumbing.

The New Architecture

Instead of sending emails directly from the Liferay mail listener, the proof of concept diverts messages into a durable JMS queue.

The actual customization is surprisingly small.

A custom listener subscribes to the same mail destination used by Liferay's built-in mail sender.

When a mail message arrives:

Receive the mail message.
Serialize it as an RFC822 email.
Publish it to a durable JMS queue.
Return.

At that point Liferay's responsibility ends.

The email request has been durably persisted.

Everything that happens afterward becomes a messaging concern rather than a Liferay concern.

Preventing Duplicate Delivery

One obvious question is:

If Liferay already has a mail sender, won't both listeners process the message?

The answer is yes.

To avoid duplicate delivery, the proof of concept disables the default Liferay mail sender and replaces it with the JMS publisher.

We create a osgi/configs/com.liferay.portal.component.blacklist.internal.configuration.ComponentBlacklistConfiguration.config file that contains the following:

blacklistComponentNames=
  ["com.liferay.mail.messaging.internal.MailMessageListener"]

This ensures there is only one path for outbound email processing.

It blocks the Liferay component from running, so it won't be pulling messages from the LMB, only our customization will.

Why RFC822 Serialization Matters

Rather than creating a custom message format, the proof of concept serializes the complete email into a standard RFC822 message.

This preserves:

HTML content.
Attachments.
Reply-To addresses.
Message headers.
Message IDs.
Custom metadata.

Camel doesn't need to understand anything about Liferay mail messages.

It simply receives a standard email and forwards it appropriately.

This keeps the integration clean and loosely coupled.

Reliable Delivery Through Transactions

One small configuration detail carries a lot of weight.

The Camel route consumes messages transactionally.

from("sjms2:queue:mail.outbound?connectionFactory=" + 
    "#artemisCF&transacted=true")
  .routeId("mail-outbound-relay")
  .bean("smtpSender", "send");

If SMTP delivery succeeds, the transaction commits and Artemis removes the message from the queue.

If SMTP delivery fails, the transaction rolls back.

The message remains in the queue.

Nothing is lost.

That transactional boundary is what makes reliable delivery possible.

Repository Contents

The repository accompanying this post (https://github.com/dnebing/liferay-reliable-email-delivery) contains everything needed to build and run the proof of concept.

A Liferay Workspace.
The email diversion module.
Docker Compose configuration.
Apache Artemis.
Apache Camel JBang.
SMTP4Dev.

The Liferay Workspace contains the customization module that diverts email messages from the LMB into JMS.

The Docker composition starts Liferay DXP 2026.Q1.8, Artemis, Camel JBang, and SMTP4Dev.

Building and Running the Proof of Concept

Build the module from the Liferay Workspace:

$ cd liferay-workspace
$ ./gradlew :modules:guaranteed-email-delivery:jar

Copy the generated module into the Liferay deployment location used by the Docker composition.

$ cp modules/guaranteed-email-delivery/build/libs/*.jar \
  ../docker/liferay/files/osgi/modules/

Start the environment:

$ cd ../docker
$ docker compose up -d

Once the containers are running, verify that:

Liferay is available on port 8080.
Artemis is available on port 8161.
SMTP4Dev is available on port 5080.

Why SMTP4Dev?

For a proof of concept, I didn't want to depend on a real mail server.

SMTP4Dev is a lightweight SMTP server designed specifically for testing and development.

It accepts emails, stores them locally, and exposes a web interface for reviewing received messages.

This gives us several advantages:

No external mail dependency.
No risk of sending emails to real users.
Easy inspection of message contents.
Simple outage simulation.

Most importantly, it allows us to reproduce the original customer problem.

When SMTP4Dev is running, messages should be delivered immediately.

When SMTP4Dev is stopped, Camel cannot deliver messages, Artemis retains them in the durable queue, and the queue depth increases.

When SMTP4Dev is started again, Camel resumes processing and the backlog drains.

Generating Test Emails

To make testing easier, the repository includes a simple Groovy script that can be executed from the Liferay Script Console.

The script sends an email using Liferay's standard MailServiceUtil API.

import com.liferay.mail.kernel.model.MailMessage
import com.liferay.mail.kernel.service.MailServiceUtil

import jakarta.mail.internet.InternetAddress

def from = new InternetAddress("noreply@example.com",
  "Liferay Reliable Mail Demo")
def to = new InternetAddress("test@example.com", 
  "Test Recipient")

def subject = "Reliable email delivery test - " + new Date()

def body = "<html>" +
"    <body>" +
"        <h2>Liferay Reliable Email Delivery Test</h2>" +
"        <p>This email was generated from the Liferay Script "
      + "          Console.</p>" +
"        <p>" +
"            If SMTP4Dev is running, it should appear " +
"immediately.<br />" +
"            If SMTP4Dev is stopped, it should remain queued 
        "in Artemis" +
"            until the mail server is available again." +
"        </p>" +
"        <p>Generated at: " + new Date().toString() + "</p>" +
"    </body>" +
"</html>"

def mailMessage = new MailMessage(from, to, subject, 
  body, true)

MailServiceUtil.sendEmail(mailMessage)

out.println("Queued email using Liferay MailServiceUtil: " + 
  subject)

NOTE: The script may not copy correctly and paste into the console because it's html. Check the sendmail.groovy script in the repo, it should work fine.

Because the script uses the normal Liferay mail infrastructure, it follows exactly the same path as any other email generated by the platform.

In Liferay, open the Script Console, select Groovy, paste the script, and execute it.

Testing the Solution

With everything running normally, execute the Groovy script.

The email should immediately appear in SMTP4Dev.

Note: If using the docker container, go to http://localhost:5080 and you'll see all of the email that has been delivered.

Now stop the SMTP server:

$ docker compose stop smtp4dev

Execute the Groovy script several more times.

At this point:

Liferay continues generating email requests.
Messages are published to Artemis.
Camel attempts delivery.
SMTP delivery fails.
Artemis retains the messages.

Open the Artemis console and inspect the queue.

The queue depth should continue increasing as new messages are generated.

Nothing is lost.

Recovering from the Outage

Start SMTP4Dev again:

$ docker compose start smtp4dev

Camel reconnects and resumes processing.

Messages begin leaving the queue.

The backlog drains.

Emails appear in SMTP4Dev.

This is exactly the behavior we wanted to validate.

The six-hour mail server outage that prompted the original question no longer results in lost messages.

Artemis Retry Configuration

The proof of concept includes a retry strategy configured directly in Artemis.

<redelivery-delay>5000</redelivery-delay>
<redelivery-delay-multiplier>2.0</redelivery-delay-multiplier>
<max-redelivery-delay>300000</max-redelivery-delay>
<max-delivery-attempts>-1</max-delivery-attempts>

These settings provide:

An initial retry delay.
Exponential backoff.
A maximum retry interval.
Unlimited delivery attempts.

These values were selected to support the reliable delivery goal demonstrated in the proof of concept.

A production implementation would tune these values based on operational requirements, expected outage duration, message urgency, and business expectations.

The important part is that Artemis avoids continuously hammering an unavailable SMTP server while still preserving messages for later delivery.

Production Considerations

The proof of concept intentionally focuses on a single failure mode:

SMTP server unavailable.

That was the original customer scenario, and it is the scenario this proof of concept validates.

A production implementation would need additional handling for permanent failures.

Examples include:

Invalid recipient addresses.
Invalid sender addresses.
Oversized messages.
Malformed MIME content.
Domain resolution failures.
Mail server policy rejections.
Missing required message fields.

Retrying these messages forever usually doesn't make sense.

A production implementation would likely inspect delivery failures and make routing decisions based on the type of failure.

Some messages should remain in the send queue because the failure is transient.

Some messages should move to a dead letter queue.

Some messages should move to an undeliverable queue.

Some messages may require manual review.

Some messages may be safe to discard according to business policy.

A more complete production topology might look like this:

The correct handling depends entirely on business requirements.

A password reset email might be discarded after a reasonable expiration window.

A purchase confirmation email might require manual review.

A regulatory notification might require alerting and escalation.

The important point is that these decisions happen after the message has already been durably persisted.

The email request is never silently lost because of a temporary infrastructure failure.

What About Custom Email Code?

This solution works automatically for applications using Liferay's standard mail APIs.

If custom code bypasses Liferay's mail infrastructure and connects directly to SMTP, those messages will not pass through the durable queue.

Additional customization would be required to bring those emails into the same processing pipeline, but it's not that complicated. You're already preparing a MailMessage and then invoking Transport.send() with it. Instead of sending it, take a look at how JmsMailDivertListener is posting the mail to the JMS queue. Your custom code would do the same thing and the rest of the implementation will just work.

This is an important operational detail.

If reliable email delivery matters, you need to understand every path your system uses to send email.

Final Thoughts

The interesting thing about this project is that it started with an email question and ended with a messaging solution.

The customer wasn't really asking how to send email more reliably.

They were asking how to ensure an important business event could not be lost.

Durable messaging solves that problem.

And it solves the problem regardless of the scenario, whether it is simply sending an email or updating a record in an external system or writing a file to the filesystem... They're all the same - it's an important business event that cannot be lost, and an outcome that must be reliably satisfied. JMS and durable queues are the way to ensure that.

For reliable email delivery, once email requests are persisted in a durable queue, temporary infrastructure outages stop being catastrophic events and become operational inconveniences.

Liferay provides a clean interception point through the Liferay Message Bus.

JMS provides queue durability.

Apache Camel provides integration.

Together they create a relatively simple solution for a problem many organizations assume requires expensive proprietary infrastructure.

And perhaps the biggest lesson is this:

When something absolutely must happen, don't rely on immediate execution.

Publish (enqueue) the intent first.

Then process it reliably.

URL for the repo if you didn't see it already:

https://github.com/dnebing/liferay-reliable-email-delivery

Call for Papers for DevCon - two weeks to go!

2026-06-15T05:27:38Z

If you've been paying attention recently on liferay.dev you have probably noticed the new banner promoting DevCon. It may still be a few months until our biggest event of the year takes place in London on November 3rd and 4th (with the un-missable Unconference happening on the 5th) - but - that doesn't mean you can sit back and relax!

Our Call for Papers for DevCon 2026 is wrapping up in just two weeks - on June 30th - and we really want to hear your ideas for possible talks!

What makes DevCon special is that it's not only an event for anyone that develops with Liferay, or that is interested in Liferay at all, but it's also an event that welcomes content from independent developers, from Liferay Partners, and one where anyone with a strong story about Liferay can directly contribute to.

This year we're interested in talks that touch on:

Cloud Technologies
Security
Building with Liferay
Architecture
Developer Experience & AI-Augmented Development
Integrations
Low Code, AI Code & No Code
Agentic AI & Automation

(There's more detail on these topics in the Call for Papers submission form!)

And, of all of these, the topic that we're really interested in is how you're using AI to implement Liferay and expand it's capabilities. Maybe you're using Gemini to help you better understand how Liferay works, or you're using Claude to build Client Extensions, or using OpenAI to design your look and feel. Whatever tooling, models, or harnesses you're working with - if it's doing something with Liferay we would love to hear you talk about it!

Check out the Event site here, where you'll find a link to the Call for Papers Form. Don't miss out on your opportunity to present your ideas to Liferay Developers from all over the world!

Cheers!

Ben

Alternative tool for migrating Liferay to PostgreSQL

2026-06-14T23:51:27Z

For some time now, PostgreSQL has been gaining so much ground that even Liferay itself has made the decision to replace MySQL with PostgreSQL.

At this point, many of us are faced with the non-trivial task of performing the same operation in our on-premise installations and, above all, how to do it properly.

Liferay published a tool for this purpose, divided into two parts:

The data exporter
The migration script

Both my colleagues and I have tried to use this tool to perform this operation, but the process (at least in my case) did not achieve the desired outcome. In fact, Liferay DXP 2026 already warns in the control panel that this tool is in its Beta phase.

Faced with this inconvenience, I have been running tests to develop a tool that allows this operation to be performed.

Requirements

To carry out the procedure, you must have downloaded the tool, have an empty PostgreSQL database, and have Java 21 installed.

Procedure

The procedure to perform the migration with this tool is as follows:

Create an empty database on a PostgreSQL server
Stop the application server of the Liferay installation
Change the database connection configuration to PostgreSQL
Start the server again
Wait for the table creation process to finish
Stop the server again
Run the tool (see documentation)
Start the server again

Once the entire procedure is completed, the Liferay installation will start up using the PostgreSQL database with all the data transferred.

Liferay

Liferay DXP 2026.Q3 - Release Webinar - Replay

For more details and a link to the recording and PDF you can visit:

Enabling ModSecurity in Liferay PaaS

Start with the Liferay Documentation

Local Log Files and Containers Don't Mix Particularly Well

/dev/stdout Doesn't Mean "Dump Everything"

SecAuditEngine On Can Generate a Lot of Data

Then There Was the E

So What Do All Those Letters Mean?

A — Audit Log Header

B — Request Headers

C — Request Body

D — Reserved

E — Response Body

F — Final Response Headers

G — Reserved

H — Audit Log Trailer

I — Not Implemented in ModSecurity 3.x

J — Uploaded File Information

K — Not Implemented in ModSecurity 3.x

Z — End of Audit Entry

Choose the Parts You Actually Need

Native or JSON?

Use Native when:

Consider JSON when:

Don't Forget the Other ModSecurity Log

Be Careful with SecDebugLogLevel 9

A Practical PaaS Configuration

What About Access Logs?

And Then Download the Logs

The Bigger Lesson

When a CVE Isn't a Liferay Vulnerability

The Scanner Isn't Wrong

Spring Is a Good Example

Presence Is Not the Same as Exploitability

What Happens When Liferay Investigates a CVE?

The Log4j 1 Lesson

But Sometimes "Not Vulnerable" Isn't Enough

The Three Basic Outcomes

The Product Isn't Affected

Patch or Harden the Dependency

Upgrade the Dependency

Why Not Just Upgrade Every Time?

There Is One Important Catch: Your Code

Don't Replace Liferay JARs Just to Silence a Scanner

What Should You Do With a Scanner Finding?

A CVE Is the Beginning of the Investigation

Liferay DXP 2026.Q3 Release Webinar

SESSION REPLAY AND PDF

OIDC SLO in Liferay DXP

Understanding the Terminology

There Isn't Just One "OIDC Logout"

Why Back-Channel Logout Exists

How Back-Channel Logout Works

Liferay's Implementation

Configuring Back-Channel Logout

Security Considerations

Operational Considerations

The OpenID Provider Must Reach Liferay

Browser Behavior

Clustered Liferay Environments

What Isn't Supported Yet?

Final Thoughts

Bringing Liferay to Cross-platform Development

No More Rebuild-and-Redeploy: Instant Hot Reload for Liferay React Client Extensions

The Rebuild-and-Redeploy Loop Every Client Extension Developer Knows

Liferay Already Gives You the Fix — Here's Where It Stops

Introducing liferay-cx-hmr-setup

How It Works, In Plain Words

What Gets Set Up Automatically

Automatic Port Allocation Across Your Whole Workspace

Letting Liferay's Runtime Packages Do Their Job

Zero-Config Wiring: dev.yaml, the Refresh Preamble, and CORS

Getting Started

1. Run the CLI

2. Deploy the Dev Manifest

3. Start Coding

What This Changes About Your Day-to-Day

Give It a Try

`/dev/stdout` Doesn't Mean "Dump Everything"

`SecAuditEngine On` Can Generate a Lot of Data

Then There Was the `E`

`A` — Audit Log Header

`B` — Request Headers

`C` — Request Body

`D` — Reserved

`E` — Response Body

`F` — Final Response Headers

`G` — Reserved

`H` — Audit Log Trailer

`I` — Not Implemented in ModSecurity 3.x

`J` — Uploaded File Information

`K` — Not Implemented in ModSecurity 3.x

`Z` — End of Audit Entry

Be Careful with `SecDebugLogLevel 9`

Introducing `liferay-cx-hmr-setup`

Configure `setenv.sh`

What is HTTP QUERY?
RFC 10008 introduces a new HTTP method called QUERY.