LDEV-6455 - read spooler tasks with the class loader that created them

[shane-tw]

Ticket

LDEV-6455

Problem

SpoolerEngineImpl.getTask() deserializes task files with the core class loader. Since mail moved into an extension, MailSpoolerTask and the jakarta.mail types it holds live in the extension's RPC class loader (declared via maven="org.lucee:mail:1.1.0.8-RC"), so reading the file fails with ClassNotFoundException: org.lucee.extension.mail.spooler.MailSpoolerTask and the file is deleted. Spooled cfmail is stored fine and then silently lost.

Fix

The engine is handed the live task in add(), so it already knows the loader that defines the task class. It now remembers that loader per task class and deserializes each file with the loader of the class that wrote it, the same rule Java serialization itself follows. The core loader remains the default, so core tasks are read exactly as before. No other class loaders are consulted.

A file whose task class cannot be resolved is no longer deleted. It is skipped, logged, and read once the class becomes known again (for example after a restart, as soon as the extension queues its next task). Files that fail for any other reason are still deleted as before.

Verification

test/tickets/LDEV6455.cfc spools a mail with a sendTime a day out, then lists spooler tasks, which reads the file back. Fails on 7.1 as it stands, passes with this change.

The second commit replaces the class loader search from the first one; the first commit is kept for history.

🤖 Generated with Claude Code

[shane-tw]

This is okay to close if you want. At least the test case should help.
Edit: I'll have Claude take another look later anyway but it's probably better a human try

[shane-tw]

I've had claude rework/simplify this PR now, ready for re-review. Passed the full test suite again

[michaeloffner]

A fix for LDEV-6455 has landed on 7.1 in commit a884d212e.

Approach: on deserialization, when the core engine class loader cannot resolve a task class, the class is resolved on demand against the currently installed extension — via the cfmail tag's registered ClassDefinition (getTag("mail").getTagClassDefinition().getClazz().getClassLoader()). That loader is reused for the rest of the same object graph. It sits in JavaConverter.ObjectInputStreamImpl.resolveClass, so it covers both the spooler reload (SpoolerEngineImpl.getTask) and ObjectLoad.

Why resolve on demand rather than cache the creating loader: a spool task is written now and read later, and the read can happen in a different class loader context than the write (after a restart, or after an extension update). So the read must resolve the class against whatever loader currently provides it, not a loader remembered from write time. Resolving from the current tag registration works straight after a restart (the tag library is registered at startup) and tracks extension updates.

Also added test/tags/MailSpoolSerialization.cfc (an ObjectSave → ObjectLoad round-trip of a real MailSpoolerTask, which exercises both the write side — the 1.1.0.6 NotSerializableException — and the read side — the ClassNotFoundException) and bumped the loader to 7.1.1.4-SNAPSHOT.

[michaeloffner]

@shane-tw thanks for digging into this and for the clear writeup — the diagnosis is exactly right, and your LDEV6455.cfc (sendTime a day out, so no mail server is needed) is a nicer test than mine.

I went a different route for the fix, and I want to explain why we can't take the cached-loader approach.

Remembering the loader that created the task (the taskLoaders map populated in add()) ties reading to the write-time class loader instance. But the point of the spooler is persistence: a task is written now and read later, and the read can happen in a different class loader context than the write. That breaks the cache in exactly the cases persistence exists for:

• After a restart, the map is in-memory, so it is empty. The .tsk files that survived the restart — the whole reason the spooler writes to disk — then cannot be resolved, because the one thing needed to read them (the creating loader) did not survive. They sit unread until some later add() happens to repopulate the map, which in a quiet app may never come. Keeping the file instead of deleting it avoids data loss, but the task still is not delivered.
• After an extension update, the cached instance is stale; the task has to be read against the new loader.

So the read has to resolve the class fresh, against whatever loader currently provides it, rather than a loader remembered from write time. That is what the landed fix does (resolve via the current cfmail tag registration), so it works right after a restart and tracks extension updates. The one thing no loader strategy can fix is serialization format compatibility across an incompatible class change (serialVersionUID) — that is inherent.

Your "keep the file on ClassNotFoundException instead of deleting it" is a good improvement in its own right, and we will likely fold that in as a safety net on top. Thanks again for the work.