Now, the big question: does this work with EHCache?
The documentation seems to imply that serializability is necessary only for objects spooled to disk, but from looking at the source, I was unable to ascertain what happens when an element is overflown from the memory store to the disk store. Probably it would be trivial to add a check and don't move the element to disk store if it's not an instance of Serializable.
BUT we should also consider this:
"The Disk Cache is not meant to be persistence mechanism. The data file for each cache is deleted, if it exists, on startup. No data from a previous instance of an application is persisted through the disk cache. The data file for each cache is also deleted on shutdown."
Given this, I'm afraid that both EHCache and JCS are not appropriate for persisting objects like Logicsheet and Pagesheet to disk (I wonder how JISP handles persisting non-serializable objects, in the first place).
What I'd suggest to do at this point is:
1) Ship 2.1.5 with EHCache as the default store, configured with a memory store large enough for at least running the samples with a decent cache hit ratio.
2) Provide a few alternative, commented-out, configurations in cocoon.xconf with estimates like: "If your JVM is started with -Xmx256m use this value as a starting point".
3) Configure EHCache with a ZERO-sized disk store. What we're shipping is a configuration suitable for first-time users, which don't need a persistent store and should be shielded from having to configure it. Expert users will know how to fine-tune their setup, if we document how.
4) Drop the damn store janitor! I have the impression it's not needed anymore. Please correct me if I'm wrong.
Ugo
