Kief Morris wrote:
> I don't see anybody assigned to tackling the Catalina 4.0 FileStore
> implementation, or the Manager implementation for swapping active
> sessions to disk, so I've started messing around with this. If anyone
> else is interested in working on this (or already working on this) speak
> up!
>
None of the other "volunteers" listed in the STATUS.html document have spoken up
much lately, either, so if you want to tackle a piece with someone else's name on
it, announce your intention and go for it.
>
> So far I'm looking to implement the FileStore class by cribbing code
> from StandardManager's load() and unload() methods, to store session
> data in individual files named with the session ID. I've also created a
> class called PersistentManager which will use this store.
>
It might be possible to extract this code into a shared utility class if it is
really reusable.
>
> I'd be interested in hearing comments on how the architect (Craig?)
> who drafted up the Store class intended it to interact with Manager
> and the rest of the container. I could also use some pointers in a
> few areas, in particular:
>
The general idea was that a Manager implementation interested in supporting
persistence or swapping of sessions would choose a Store implementation (see
below for config stuff), and would then call the load() and save() methods on it
whenever the Manager's policies so dictated. This could be after every request
(as Shai proposed), at startup/shutdown only (replacing the primitive mechanism
used in StandardManager today), or dynamically for swapping or session moving.
There hasn't been a lot of direct thought for how session migration would affect
the Store interface, so I'm certainly open to necessary changes.
>
> - How exactly does the Container decide which Manager implementation
> to load? I've found in startup.Catalina.createStartMapperContext():
> mapper.addRule(prefix + "/Manager",
> mapper.objectCreate
> ("org.apache.catalina.session.StandardManager",
> "className"));
> ... but I'm guessing there's a way to override this in server.xml?
>
You can replace the existing Manager implementation on a per-webapp basis by
nesting a <Manager> element inside a <Context> element, like this:
<Context path="/examples" docBase="examples" ... >
...
<Manager className="org.apache.catalina.session.MyManager"
... (other property setting attributes) ... />
...
</Context>
This design pattern can be carried one stage further to allow a Manager
implementation to pick which Store it wants to use. Two patterns I've used
elsewhere in Catalina are:
* Define a "storeClass" property on your Manager implementation,
so you can set the fully qualified class name of the Store implementation
by saying <Manager ... storeClass="org.apache.catalina.session.MyStore"/>.
* Create another level of nesting inside <Manager> called <Store>. This is
probably better, because you can now configure the properties of the
Store implementation using <Store> attributes.
>
> - I'll need to figure out how to make the choice of Store class configurable.
> Any pointers on this would be appreciated.
>
The second alternative above seems like the best approach to me.
>
> - The FileStore implementation I'm using needs to get access to the
> Container. Is there a recommended way to do this? At this point I've
> actually modified the Store interface to add setManager() and getManager()
> methods, which the Manager uses when instantiating its Store - this
> way the Store can get at most of the things it might need.
>
That makes sense to me -- in fact, I cannot imagine a Store implementation that
would not need this. It should be added to the official Store interface so that
all implementations have to support it.
If we use the second configuration approach, you can set up the configuration
rules to call setManager() for you to establish this link, with an "set parent"
rule, so that it happens for you automatically.
>
> Thanks,
> Kief
Craig
