Liferay Ops Console

Liferay Ops Console is a Control Panel module for the boring, high-stakes work on a running DXP instance: deploy artifacts, manage OSGi folders and bundles, query the database, tail logs, and keep a short audit trail — without SSHing into the box or juggling three admin tools.

What it is

It ships as a Liferay Workspace OSGi web module (com.opsconsole.web). Company admins open Control Panel → System → Liferay Ops Console. Source lives on GitHub: codepapu/liferay-ops-console-workspace.

Why it exists

Day-two Liferay ops still looks like this in too many teams: upload a JAR via Gogo or a shared drive, hope osgi/modulesis writable, open a SQL client for “just one SELECT,” then dig through liferay.*.log when something fails. The Ops Console collapses that into one admin surface that already understands Liferay home, OSGi folders, and portal permissions.

If your only path to delete a stuck JAR under osgi/modules is SSH, you do not have an ops UX — you have a dare.

Shape of the module

Classic Liferay MVC portlet + Clay UI, packaged as an OSGi web bundle:

• Portlet — actions and resource endpoints for upload, delete, bundle lifecycle, DB JSON, log tail, audit export.
• Utilities — OsgiFolderManager, BundleLifecycleManager, DatabaseExplorer, LogFileExplorer, OpsAuditLog, CacheOps, AdminGuard.
• UI — tabbed JSP fragments + Bootstrap tables with search / pagination; Logs uses a fixed-height terminal console.

The tabs

Seven tabs, one job each. The first viewport of the console should feel like an ops desk — not a marketing page.

Overview

Release string, JVM, heap, disk free on Liferay home / OSGi modules, DB connectivity, cache clear (CacheRegistry + MULTI_VM + SINGLE_VM), and a recent audit strip. Use this tab to confirm the box is the one you think it is before you deploy or delete anything.

Deploy

Upload supported artifacts and let Liferay's auto-deploy / OSGi folders do the rest:

• .jar / .war / .lpkg → deploy/
• Client-extension .zip → osgi/client-extensions/

OSGi folders

Browse managed folders: modules, configs, client-extensions, portal, war, static, deploy. Upload, download, edit text configs where allowed, and — in v1.0.0 — delete files one-by-one or in bulk.

• Path escape and symlink checks keep deletes inside the chosen folder.
• Locked JARs (common under static) are renamed to *.deleted when a hard delete fails — restart clears them.
• Searchable table + pagination so a fat modules directory stays usable.

Bundles

Filter by BSN / state, then start, stop, refresh, update, or uninstall. System bundles and the Ops Console itself are protected from casual self-destruction.

Database

Live JDBC against the portal DataSource: list tables, preview with offset/limit, run SELECT, export CSV, and — when unlocked — edit cells, insert rows, delete rows. Writes require an explicit confirm token.

# portal-ext.properties — prefer this on shared / prod support boxes
ops.console.db.read.only=true

Logs

Discover Liferay and Tomcat log files, then tail them in a fixed-height black console with ERROR / WARN / INFO colouring. Live poll and Follow are available but default off so the page does not hammer disk on open.

Audit

Persistent JSONL under data/ops-console/audit.jsonl, searchable table, clear action, and CSV export. Useful for “who deleted that JAR?” — not a substitute for centralized logging.

Security model

• Company admin / omniadmin only (AdminGuard).
• OSGi path traversal and symlink rejection.
• Bundle self-modification blocked.
• DB writes need confirm token I_UNDERSTAND; DDL (DROP / TRUNCATE / ALTER / …) blocked.
• Optional hard read-only DB mode via portal property.

End-to-end flow

1. Sign in as administrator.
2. Control Panel → System → Liferay Ops Console.
3. Overview — confirm home path, disk writable, DB URL.
4. Deploy — upload module or client-extension zip.
5. OSGi — verify the file landed; edit .config if needed; delete leftovers when cleaning a bad deploy.
6. Bundles — filter BSN, start / stop / refresh.
7. Database — preview or SELECT; export CSV if you need evidence.
8. Logs / Audit — confirm what happened and who did it.

Ship it

From the workspace root, with liferay.workspace.home.dir pointing at your DXP home:

cd liferay-ops-console-workspace
./gradlew :modules:liferay-ops-console:deploy

Or build the module and drop com.opsconsole.web-1.0.0.jar into osgi/modules.

Takeaways

• Ops UX belongs in Control Panel when the work is already Liferay-shaped (OSGi folders, bundles, portal JDBC).
• Delete and DB write are features — gate them harder than deploy.
• Audit is for local accountability; pair with real logging in prod.
• Ship the same JAR you tested — Workspace deploy or release asset, not a laptop rebuild on the server.