Mailing-List: contact dev-help@beehive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Beehive Developers" <dev@beehive.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of richfeit@gmail.com designates
 64.233.184.199 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=S3Ki3tST0j4AUn2eK8t+kdyTYuruDi3iOOtf9StQ+IzmUYA55EFWAyVxMucxXEnAe5Kcgfx2ViFUwbWNw2Q7myWQZzXVLH4fFDXz1xtwTRbbNDCegeXtfkz9PxLCWbd7olnaqcIXttX2VRMcrUZ73hSKdf4Di8duqxPi6lg7NyI=
Message-ID: <43D7AC11.8060207@gmail.com>
Date: Wed, 25 Jan 2006 09:49:21 -0700
From: Rich Feit <richfeit@gmail.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Beehive Developers <dev@beehive.apache.org>
Subject: Re: DeferredSessionStorageHandler and StorageHandler
References: <40f026540601200908u1e9235a0lce69327148e70469@mail.gmail.com>
In-Reply-To: <40f026540601200908u1e9235a0lce69327148e70469@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hey Daryl,

It solves a set of problems that involve multiple requests to different 
page flows.  Consider this:
    - request A: hits x.jpf
    - request A: nests y.jpf
    - request B: hits z.jpf, blowing away the nesting stack
    - request A: returns from y.jpf, gets EmptyNestingStackException
or...
    - request A: hits x.jpf
    - request B: hits y.jpf, making it the current page flow
    - request A: forwards to a JSP that expects x.jpf to be current

The solution is to defer the committing of the nesting stack and the 
current page flow (and shared flow, and JSF backing bean) until the end 
of a chain of forwarded requests -- that way, the request state is 
internally consistent.  You can still end up with faulty app behavior 
with two concurrent requests, but this gets rid of situations where our 
framework itself gets confused (EmptyNestingStackException, 
NoPreviousPageException, etc.).

The StorageHandler was originally the plug point where we could allow 
storing page flow instances in alternate locations (e.g., database or 
request).  One thing that would be nice to change would be to have a 
base class to support deferred-until-end-of-request storage in general, 
so the logic could be used with locations other then the session.  
Ultimately we should be able to have a storage handler that applies 
per-pageflow, overriding the webapp-wide one.

Does this answer your question?

Rich

Daryl Olander wrote:
> Rich,
> Just curous what problem the DeferredSessionStorageHandler solves and in
> general why we talk to the session thorugh the StorageHandlers?  The tags
> store everything directly in the session.  Under what senarios do we ever
> see having different implementations of this?
>
>