beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlin Rogers" <carlin.rog...@gmail.com>
Subject Re: BEEHIVE-1094
Date Sat, 05 Jan 2008 00:25:07 GMT
I updated BEEHIVE-1094 with a patch for trunk in SVN. It is based off
of Poorna's wok with a few modifications.

It will solve this issue for the case where a page flow is destroyed
when a user changes from one page flow to another and the current page
flow gets removed from the session (destroyed) and replaced by the new
page flow.

However, this does not solve the case when the session times out and
the "current" page flow is destroyed, via valueUnbound(). In this case
there is no request so no way for valid contextual services based on a
request.

I'm not sure how a user could detect the session time out case within
the onDestroy() method to avoid calling a control.

What do folks think about committing these changes and documenting the
issue for the session time out case?

Kind regards,
Carlin


On 12/21/07, Carlin Rogers <carlin.rogers@gmail.com> wrote:
> Hi Poorna,
>
> I have a couple of thoughts on the patch you rpovided. I think it will
> be OK but still leaves the issue that without a new callback a user
> cannot write their current onDestroy() and know that they will always
> have a valid contextual services based on a request. In the case of a
> session timing out and a valueUnbound, the request will still be null.
> At least this improves the current issue of destroying a page flow
> when a user moves to another page flow.
>
> I'd recommend that if we introduce these changes, that we don't just
> make SessionBindingEvent a public inner class of the
> DeferredSessionStorageHandler (DSSH). The DSSH is an internal class
> and not designed to be used directly by a developer. Therefor, I'd
> recommend that if the SessionBindingEvent event is to be made public
> it no longer be an inner class, and place it in another package other
> than "internal".
>
> Also, is there a need for the call to get the ControlContainerContext
> instance in the PageFlowManagedObject.destroy() method? I don't think
> we need it.
>
> I'll be away on holiday for a while but can look at this again with
> you when I return. Thanks for the contribution. Happy new year!
>
> Kind regards,
> Carlin
>
> On 12/20/07, Carlin Rogers <carlin.rogers@gmail.com> wrote:
> > Sorry Poorna, I have not completely looked through the patch. I'll try
> > to review it later today. A new callback onDestroy(request, session)
> > sounds reasonable. We definitely need to make sure these changes are
> > backward compatible. I do not know of any way to create control
> > container context without requiring a request.
> >
> > Kind regards,
> > Carlin
> >
> > On 12/19/07, Poorna Ramasamy <pramasam@bea.com> wrote:
> > > Did anyone get a change to look at this?
> > >
> > > regards,
> > > ~Poorna
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Poorna Ramasamy
> > > Sent: Wednesday, December 12, 2007 10:24 PM
> > > To: Beehive Developers
> > > Cc: Carlin Rogers
> > > Subject: RE: BEEHIVE-1094
> > >
> > > Attached diff is the new solution I have in my mind now. That is,
> > > request is being tracked right from where the pageflow is removed from
> > > session using the SessionBindingEvent. At the destroy method if request
> > > is available, context is created or else onDestroy(session) is called
> > > without context.
> > >
> > > But I feel, with this approach, customers would not be certain about the
> > > context being associated with onDestroy(session). If session
> > > invalidation occurs, onDestroy(session) will be called without context.
> > > So to overcome this, I feel, a new callback onDestroy(request, session)
> > > is required here. Does this sound reasonable? Or if there is a way in
> > > which I can create control container context without requiring "request"
> > > object, please let me know.
> > >
> > > regards,
> > > ~Poorna
> > >
> > >
> > > Notice:  This email message, together with any attachments, may contain information
 of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,
 proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use
of the individual or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this by email and then
delete it.
> > >
> >
>

Mime
View raw message