Kief Morris wrote:
> Craig R. McClanahan typed the following on 09:38 AM 12/26/2000 -0800
> >> 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.
>
> Sounds reasonable. Would it be useful in areas other than sessions,
> e.g. for storing web application state?
>
Hmm ...
One of the things we haven't talked about yet is dealing with servlet context
attributes, which is pretty much all the "web application state" information that is
kept by the container itself, outside of user sessions. There might be a way to
leverage technology like this for context attributes as well.
I need to go back and read up on the spec requirements for distributed containers
some more.
>
> >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.
>
> What I'm thinking at the moment is to create PersistentManager, which will
> be configurable to set the different policies you suggest, so users can tweak
> it for their needs. The StandardManager could have its load() and unload()
> code stripped, so it provides a bare-bones implementation.
>
Sounds good. I only added load/unload to the basic StandardManager because I needed
"save sessions across restart" before I had time to build the rest of the
persistence infrastructure.
>
> A separate DistributedManager class could then be implemented, probably
> sharing a fair amount of code with PersistentManager.
>
> >* 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.
>
> This sounds like the best approach. I'll start digging around into how to
> do this: if you can give me any pointers, good starting places, etc. I'd
> appreciate it.
>
> One issue: there are likely to be attributes specific to certain Store
> implementations. Namely, FileStore needs to have a directory to
> store its serialized sessions into, but this doesn't seem appropriate
> for the Store interface. How should this work?
>
This actually works in a very slick fashion. (I didn't invent this, but I wish I
had ;-).
When XmlMapper is processing the server.xml file, it's primary job is to apply
"rules" that match the nesting pattern of XML elements -- in our case, the pattern
would be "Server/Service/Engine/Host/Context/Manager/Store". One of the rules we
will set up is the "set properties" rule, which uses Java reflection APIs on the top
object on the stack (which will be the Store instance you just created), and matches
up XML attribute names with public JavaBeans property names, and calls all the
matching setXxxx methods for you.
The net result of this is that implementation classes like FileStore or JDBCStore or
WhateverStore can have their own particular configuration properties, and nothing
special has to be done to the configuration file processing code to accomodate this
-- all you have to do is make sure you specify the right fully qualified class name.
A consequence of this, of course, is that it is not possible to create a DTD that
fully describes the valid contents of a server.xml file, but IMHO the tradeoff is
well worth it.
>
> >> - The FileStore implementation I'm using needs to get access to the
> >> Container.
> >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.
>
> A patch follows.
>
> >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.
>
> Cool!
>
> Thanks,
> Kief
> ---
> Kief Morris
Craig
