Geoff,
> > The work dir is configured in the cli.xconf, and is simply created
> > with new File(workDir). The cache directory is made from the work
> > dir with cache-dir appended.
>
> Sorry for my ignorance - I don't see any caching set up in cli.xconf,
> so I assume that means you are inheriting the definitions from
> cocoon.xconf? That eliminates one class of problems (unless you're
> not using the default cocoon.xconf - if that's the case, send your
> transient and peristent store decl. declaration here
No, it inherits from cocoon.xconf.
> I noticed you have <work-dir>../temp/docs</work-dir>
> After a run of the cli is that dir (really the cache dir under it)
> empty?
The cli.xconf is configured to drive the documentation webapp, not the default one, so
it's a little strange. At some point I'll move that one into the documentation system
and create a more natural one in the root. I've simply got <work-dir>work</work-dir>
which creates $COCOON-2.1/work.
> > Once I worked out what was going on with your EventCache, I removed
> > it, and it made no difference.
>
> Whew.
:-)
> > Removing it enabled me to get it to switch to using a persistent
> > store by putting a <cache> element into cocoon.xconf, but the is
> > persistent store (DefaultStore) doesn't survive a restart of the
> > CLI, either, i.e. the first store.get() returns nothing and the
> > second store.get() does.
>
> Huh?
> - No cache element is needed in cocoon.xconf because it's defined in
> cocoon.roles (and if you just removed the event-cache by deleting the
> xconf entry you probably didn't really remove it) - The cache role is
> a wrapper around transient-store and persistent-store which come
> predifined in cocoon.xconf
Okay. All I was doing was switching from transient to persistent, but your explanation
below tells me I don't need to do that.
> These components work together like this:
>
> Cache wraps transient-store which uses persistent-store (if and only
> if *<parameter name="use-persistent-cache" value="true"/> is set on
> transient-store in cocoon.xconf which it is by default)
>
> All new items go into the transient-store, and if configured, older
> items are moved into persistent-store when they are bumped off the
> bottom of the stack, or on container shutdown. All this happens by
> default out of the box and is working correctly (unless you
> delete/fail to reuse the cache-dir as Jetty does) for the servlet
> mode.
As far as I can see, I reuse the cache-dir. Or at least, there's a file in the cache-dir
that gets updated, and I use the same cache-dir each time.
> Sorry if that is all obvious to you but that last paragraph makes me
> think you've got some things turned around in your head - probably
> because of the Jetty behavior.
I had got some things wrong, but the Jetty behaviour only went to prove my wrong
understanding, rather than convince me otherwise!
Anyway, I've done some more research, including downloading the source for Avalon
(for the first time!) and stepped through the code for the Store.
I don't know if this is a problem, but in AbstractJispFilesystemStore, the get and store
methods don't seem to match up:
get():
value = m_Database.read(this.wrapKeyObject(key), m_Index);
and
store():
KeyObject[] keyArray = new KeyObject[1];
keyArray[0] = this.wrapKeyObject(key);
m_Database.write(keyArray,
(Serializable) value);
So one uses a wrapped key object, and the other uses an array of wrapped key
objects with one element. Does this mean it's not using the same key, and thus can
never get at stuff in the persistent store? Is this correct?
[I've still to work out how to compile Avalon, so I can't try it myself yet!]
Regards, Upayavira
