I've been working from option 3. There are 2 key elements in the data model:
IPortalCookie, which represents a single Cookie Eric is referring to (1 key to relate to all portlet cookies). IPortletCookie, which mimics javax.servlet.http.Cookie per the portlet spec, but also provides a reference to the IPortletEntity that spawned the cookie. There isn't any scoping - as far as I've gotten - so any portlet can see all Cookies (IPortletCookies) in the request. When a portlet calls: javax.servlet.http.Cookie[] PortletRequest#getCookies() Should the returned array contain all non-portlet cookies as well? The only mention in the spec is: 11.1.5.1 The portlet can access cookies provided by the current request with the getCookies method. The returned cookie array provides the portlet with all cookie properties. I read that as yes, all Cookies returned by the normal ServletRequest should be included. On Mon, Jan 17, 2011 at 9:28 PM, Eric Dalquist <[email protected]> wrote: > Hrm, that is a good point. The spec does refer to them in the same areas > where it refers to using portlet request/response properties as HTTP headers > which also implies no scoping. 3 would also be the easiest to implement > since then the cookies have no relation to the portlet definition or entity > objects. The more I think about it the more option 3 really seems to make > sense. > > Our general plan for implementation is that uPortal will always set a > specially named portal cookie with a big-random-token value in the users > browser and store that token in the DB. Any time a portlet sets/reads a > cookie it will actually be stored in the DB and never actually sent to the > browser. The big technical reason for this is since uPortal is what the spec > calls a Streaming Portal by the time portlets have started rendering there > has already been content written to the browser. We'll have a background > task that does purging of the portal cookie and portlet cookies from the DB > to make sure these cookie stores don't just grow forever. > > -Eric > > On 1/17/11 4:40 PM, Steve Swinsburg wrote: > > You're right, it is confusing. From what I have read, there is no guarantee > the cookies from one portlet will be available to another one (which is > either 1 or 2 below) but it seems an odd use of cookies and general > knowledge around the use of cookies would probably assume 3. > regards, > Steve > > > On 18/01/2011, at 3:30 AM, Eric Dalquist wrote: > > Nick Blair is working on the cookie support for portlet 2.0 and we've come > to a bit of confusion. After re-reading the portlet spec on cookies several > times now and one thing is still not clear, how are cookies set by portlets > scoped? > > It seems like there are a few options: > > Cookies are scoped the same way Preferences are, to the instance of the > portlet entity > Cookies are scoped at the definition level, essentially Portlet A can share > a cookie among any number of users but Portlet B will never see it > Cookies are not scoped at all. All portlets work in the same general space > for cookies and a cookie set by Portlet A can be seen by Portlet B > > Does anyone here have thoughts on the intent in the spec or just what your > gut feeling would be? > > -Eric > > -- > > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
