Lyfre 2.0 — AI Assistant for Liferay DXP

Lyfre is an AI assistant that lives inside Liferay DXP. It answers questions about portal content, users, commerce, and custom objects, draws live charts, and opens guided forms for admin changes. Version 2.0 rebuilds it as OSGi modules running in Liferay itself — no Spring Boot microservice — and every portal call runs as the signed-in user. This is the playbook version of how it is built and why the pieces exist.

Demo

A three-minute tour of Lyfre 2.0 on Liferay DXP 2026.Q2: questions about portal data, Data Insights charts, an image question, a guided form, and the language switcher. Same native players as on Workbench.

Earlier 1.0 walkthroughs, from the Spring Boot era:

What Lyfre is

Most “chat with your docs” widgets sit outside the portal. Lyfre lives inside it: site-aware, permission-aware, and able to read Headless resources and drive admin write flows only when the signed-in user is allowed to. The widget is a React custom element; the brain is a JAX-RS OSGi module at /o/lyfre-chatbot using LangChain4j tool calling.

What’s new in 2.0

• OSGi rewrite — the Spring Boot microservice and site initializer are gone; everything server-side is a Liferay module.
• Caller identity— Headless and JSONWS calls replay the user’s own session (or OAuth2 / Basic header), so Liferay permissions decide every answer. No service account.
• Streaming answers over Server-Sent Events, with stop and history restored after a page reload.
• Image questions — attach a PNG or JPEG screenshot; a vision model reads it.
• Data Insights — live charts and KPIs with date range chips, table view, and PNG export.
• Any OpenAI-compatible provider — Groq, NVIDIA, OpenAI, OpenRouter, Gemini, Mistral, xAI, Ollama — with optional fast and fallback models, and a per-instance override.
• LangChain4j 1.21, plus repair for tool names that gpt-oss models sometimes garble.

Architecture

Four projects ship together in one Liferay workspace:

• lyfre-chatbot-rest — OSGi JAX-RS module: chat API, read tools, forms, Data Insights, diagnostics, System Settings and Instance Settings.
• lyfre-site-setup-api — company-scoped setup configuration and shared constants.
• lyfre-site-bootstrap — on startup, idempotently creates the Lyfre site, master page with the widget, pages, and opt-in sample data.
• lyfre-app — the only client extension: a React 18 custom element (assistant-ui, Tailwind v4, shadcn).

Chat experience

• Docked or floating panel with light / dark theme, in 12 languages (English plus 11 Indian languages).
• Hierarchical suggestions: categories → topics → sample questions; reopen from the composer anytime.
• Create & manage — admin-only suggestion tree that opens guided forms without a chat round-trip.
• Markdown replies with source links and paginated tables for large result sets.
• Emoji feedback on answers, voice input, and text-to-speech.
• Improve text — one click fixes spelling and grammar in a form field, with Undo.

Read & write

Read tools (all signed-in users)

Portal search, sites, pages, web content, documents, taxonomy, commerce, custom objects, fragments, organizations, asset libraries, picklists, forms, workflow tasks, notifications, and more. Tool arguments come from the model, so they are validated server-side and results are capped in size before anything goes back to it.

Writes (portal administrators)

• The model never writes. It can only open a form; the admin reviews the fields and confirms.
• Schema-driven create, update, delete, and document upload for ~50 entity types.
• The admin check runs on the server for every submit — hiding a button in the UI is not security.
• Every confirmed write is audited (who, site, entity, outcome — never field values) and shown in the system check.

Forms flow

1. User opens a form via Create & manage, or the model asks to open one.
2. Widget loads schemas from GET /chat/forms/schemas and renders the form dialog.
3. Submit hits POST /chat/forms/submit or POST /chat/forms/upload.
4. The module validates every field, rejects unknown ones, checks the caller is a portal administrator, then calls Headless as that user.
5. A success or error card shows the result — never a false positive.

REST endpoints

Core surface under /o/lyfre-chatbot; guests are rejected on the whole application:

POST /chat                  → message (+ up to 3 images) in; reply + optional form
POST /chat/stream           → same, as Server-Sent Events
POST /chat/cancel           → stop the running turn
GET  /chat/history          → restore the caller's own conversation
POST /chat/feedback         → emoji reaction on an answer
GET  /chat/forms/schemas    → all interactive form definitions
POST /chat/forms/submit     → JSON field values (admin)
POST /chat/forms/upload     → multipart document upload (admin)
POST /chat/forms/improve-text → fix spelling and grammar (admin)
GET  /chat/diagnostics      → read-only health checks (admin)
GET  /ready                 → READY

Reliability

• System check under Create & manage — Headless probes, AI provider check, answer feedback, and recent writes, run in parallel without mutating data.
• 210 JUnit tests on the module, vitest on the widget, and a Semgrep gate before every push.
• Rate limits, request size limits, and time- and size-bounded in-memory stores; a fallback model when the main one times out.
• LLM key in System Settings → Third Party → Lyfre Chatbot (or the GROQ_API_KEY env variable) — never in the browser, responses, logs, or git.

Takeaways

• Portal-native AI means the user’s own permissions, site context, and Headless — not scraping HTML or a service account.
• Forms-first writes with an explicit confirm beat tool hallucination for admin CRUD.
• An OSGi module beats a sidecar microservice when the assistant is really part of the portal: one deploy, one identity, no extra infrastructure.