portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Müller (JIRA) <jetspeed-...@portals.apache.org>
Subject [jira] Commented: (JS2-663) Problem with cacheing key generation
Date Fri, 08 Jun 2007 08:11:26 GMT

    [ https://issues.apache.org/jira/browse/JS2-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502713

Joachim Müller commented on JS2-663:

Thanks a lot, this should close the issue. 

There is one issue I found during reading the code (JetspeedContentCacheKey ):

this.sessionAttribute = context.getRequestParameter(attributeName);

should be 

this.sessionAttribute = context.getSessionAttribute(attributeName);

Unfortunately I can not test the code under real conditions in the near future. So I leave
it to you to close the issue.

> Problem with cacheing key generation
> ------------------------------------
>                 Key: JS2-663
>                 URL: https://issues.apache.org/jira/browse/JS2-663
>             Project: Jetspeed 2
>          Issue Type: Bug
>          Components: Aggregation
>    Affects Versions: 2.1, 2.2
>            Reporter: Joachim Müller
>            Assignee: David Sean Taylor
> The key for the portlet content cache consists off the principals name and the OID of
the portlet fragment. 
> This has some problems:
> 1.)  For the anonymous user (principal name = "guest"), all anonymous users will be served
the portlet content from the cache, regardless the session preferences they changed (i.e.
language settings).
> 2.) We do use the ability of jetspeed to inject servlet-request parameters into portlet
requests  (not according to JSR-168, but pretty usefull). Caching does not take the URL request
parameters into account. Changing the request parameters will not be reflected by the porlets
content if it's chached.
> I would propose to make the cache key generation configurable (via spring). The default
jetspeed cache key generation can use the principals name/fragments OID. As an alternative
the cache key should be possible to build upon session ID, query parameter and fragments OID.
The interface should provide the cache key generator implementations with the appropriate
parameters (i.e. request) to obtain the informations it needs.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

View raw message