portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Sean Taylor" <da...@bluesunrise.com>
Subject RE: cvs commit: jakarta-jetspeed/src/java/org/apache/jetspeed/services/rundata DefaultJetspeedRunData.java
Date Tue, 14 May 2002 18:41:46 GMT

See comments below
> -----Original Message-----
> From: Glenn Golden [mailto:ggolden@umich.edu] 
> Sent: Tuesday, May 14, 2002 6:18 AM
> To: 'Jetspeed Developers List'
> Subject: RE: cvs commit: 
> jakarta-jetspeed/src/java/org/apache/jetspeed/services/rundata
>  DefaultJetspeedRunData.java
> David (et al) - 
> Comments on the StateManager.  In general, I want to stress 
> the difference between the API and the implementation.
> The StateManager API doesn't use the HTTP session so that it 
> can be be independent of it.  I think an API is stronger if 
> it is independent of other APIs, as much as possible.
> Now, the implementation of the StateManager could use the 
> session. Currently it's not.  We can revisit this.
> Yes, I am suggesting we move much of what we store in the 
> session (User
> getTemp()) into StateManager.  The main reason is to achieve 
> proper scope. Information related to a user's portal page 
> display in a browser window is not properly stored in the 
> session, as the session is scoped for ALL browser windows 
> from the user.  (Well, there can be multiple sessions for a 
> user depending on his cookies and browser, but there can 
> easily be multiple windows in a session).

+1 (your preaching to the choir)

I wasn't speaking of the interface, but the implementation.
I thought I was discussing the implementation, and its break for the
standard servlet specification for storing state.
In the impl., we could still store portlet session state using the
servlet interfaces, and maintain proper scoping.
We would also get all the benefits that I listed in the previous email.

> And moving this stuff into our own API makes it cleaner than 
> taking direct advantage of either a Turbine feature or the 
> HTTP servlet session - from an API standpoint.
> So when considering the StateManager use, don't think of how 
> it's implemented, think of the API, and the scope 
> distinctions of the different sets of information we need to 
> store.  Then I think the advantages are clear.

Im not arguing against the State Manager interface/service

> Of course, once we start to use this, we want the 
> implementation to be strong enough for us!  The next thing I 
> plan to do with the implementation is tie it in with the HTTP 
> session's timeout so that we get automatic cleanup when the 
> session expires, using the binding interface.  I'm not quite 
> sure how this will work.

It would be a lot easier the other way... 

> If there is concern about the hashmap and thread safeness, I 
> am happy to address these issues as well.

I think you already have ;-)

> Here are the cons David listed for us: I'll address them:
> > - have to duplicate a service that already exists
> I think this is really a statement of the implementation, as 
> there is no API that has the same scope and the scope that we need.

Yes, I was talking about the implementation. Is that allowed here on a
apache dev list or what?

> > - no standard life cycle events from servlet api
> Again, I think this is aimed at the implementation, and I 
> want to tie in with this as just mentioned.
> > - can't take advantage of servlet session sharing from some
> > server impls
> If we implement by storing specialized objects in the session 
> (known only to the StateManager implementation; Jetspeed 
> proper would still use our StateManager API), we can take 
> advantage of this, if desired.
> > - its not standard
> It becomes *our* standard, to fill a gap where no other 
> standard exists.  I think we will have / already have a 
> number of API *standards* for Jetspeed like this that we will 
> rely upon.

There will soon be a standard PortletSession interface.
In the meantime I fully support your work in creating the StateManager
service in Jetspeed as our standard, and moving all get/set Temp code to
make use of it. My concerns were stated in the last email, I will
reiterate again that I would like for my session state to have life
cycle events and possibly take advantage of servlet containers that
replicate state on multiple nodes if needed.

Again, I am +1 on moving all Jetsped code regarding session state to
using the StateManager interface.
Im just questioning the implementation, and would like some
clarification on justification on the benefits of the current
(if I am allowed to discuss implementation, that is)


To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>

View raw message