partial refresh vs partial execution: the XPages JSF Lifecycle, and Why Refreshing One Area Still Recomputes the Whole Page

You click one button in XPages and a validator on a completely unrelated field blocks you — because by default the whole page runs a round of the JSF lifecycle, not just your button's area. XPages has two independent 'partial' knobs: partial refresh (refreshMode/refreshId) controls which HTML fragment goes back to the client; partial execution (execMode/execId) controls which components run the server-side lifecycle. This uses the six JSF phases to explain the difference, why partial refresh alone still recomputes the whole page on the server, and how partial execution scopes the server work down.

NotesThread: The Rules for Background Threads in Domino — init Each Thread, Give It Its Own Session

Want to run Domino local calls on a background thread in Java? A plain new Thread won't do — it has no Notes runtime. You either extend NotesThread and override runNotes(), implement Runnable handed to NotesThread, or call sinitThread()/stermThread() yourself. And every thread needs its own Session and its own recycle — you can't share across threads. This covers the three NotesThread patterns, the sinitThread/stermThread pairing rule, the one-session-per-thread law, and why a background thread can't get sessionAsSigner.

@Command vs @PostedCommand: Why Your Formula Doesn't Run in the Order You Wrote It

You compute a field, then call an @Command to do a UI action — and the action runs first, your computation second. Here's why: @Command mostly runs in the order you wrote it, but @PostedCommand always defers until after every other @function finishes, so a @PostedCommand at the top of your formula runs last. Worse, some @Command functions are themselves deferred. This uses the official order-of-evaluation rules to explain the difference, which @Commands are inherently deferred, and when to use which.

sessionAsSigner: Running XPages Code as the Signer — Who the Signer Is, and Where It Bites

XPages gives you three global session objects: session is the current user, sessionAsSigner is the XPage's signer, and sessionAsSignerWithFullAccess is the signer plus full access. Using it to let a user do what their ACL forbids (write a restricted DB, bypass Readers) is handy — but 'who counts as the signer' is decided per design element, so a script library uses its own signer, not the XPage's, and mixed signatures give inconsistent elevation. This covers the three identities, how the signer is determined, and the setConvertMime / full-access traps.

The Four XPages Scopes: How Long Each Lives, What to Put in Each, and What Blows Up

XPages has four scopes — requestScope, viewScope, sessionScope, applicationScope — with lifetimes from a single request to the whole application. Pick the wrong one and values vanish or leak across users; but the sharpest trap is that scopes get serialized to disk, so stuffing a NotesDocument, NotesView, or an SSJS function into one eventually throws NotSerializableException. This covers how long each scope lives, how unqualified names resolve tightest-first, what's safe to store, and why you keep a UNID or view name rather than the object.

Field Notes from panagenda's MakeNotesFaster Webinar: Slow Notes Is Usually Configuration, Not Old Laptops

In panagenda's MakeNotesFaster webinar, Christoph Adler breaks HCL Notes 14.5.1 FP1 client performance on Windows down to two decisions: run the right version, configure it right. Here are the points most useful to admins — one brutal real-world customer number, why ODS quietly steals startup time on every open, whether you should delete cache.ndk regularly (he debunks the myth outright), keeping the data directory off network shares, the three traps in an antivirus exclusion set, and the Monday-morning checklist he closes with.

The Two Jobs of dircat: You Think It Only Builds the Directory Catalog — Since Domino 12 It Also Runs Entitlement Auditing

See dircat (Directory Cataloger) in show tasks and most people think 'directory catalog' — aggregating multiple Domino Directories into one lookup-friendly directory. That's its day job. But since Domino 12 the task quietly took a second one: aggregating each server's entitlement data into entitlements.nsf, a licensing-compliance audit with nothing to do with directories. This covers dircat's real job (condensed vs extended catalogs, and why DIRCAT5.NTF isn't CATALOG.NTF), its hidden second role since Domino 12, and how one task with two jobs bites.

Who Is the Domain Administration Server? One Domino ACL Setting Behind Entitlement Aggregation, CertMgr, and AdminP

An additional server cold-boots and floods the console every 5 seconds with 'Error connecting to server…', trying to reach every server in the domain. The culprit wasn't entitlement config at all — it was a single ACL setting that had quietly made this server the 'domain administration server.' This piece covers how many meanings 'administration server' has in Domino, what actually decides the domain-admin identity, which subsystems it silently drives (domain-wide entitlement aggregation, CertMgr, AdminP), and how to split those responsibilities apart.

Wiring Domino IQ RAG to a Remote Model: certstore Trust, the API Key, and the HTTPS Endpoint

Domino 14.5.1 FP1 added a Remote mode to RAG — the site's FP1 roundup already covered what changed. This piece doesn't repeat that; it fills in the wiring: how the Remote-mode configuration document is filled out, the HTTPS-only endpoint and API Key, and the step that trips people up — the remote AI server's trusted roots go into certstore.nsf, not the JVM truststore that the DRAPI path consumes.