Re: PortletDD & getExpirationCache

[Eric Dalquist]

Craig,

I created https://issues.apache.org/jira/browse/PLUTO-448 for the issue. Just out of curiosity is there any plan for a 1.1.5 release? I realize from you earlier post that you're really swamped and don't want to be adding to that. I would be able to provide time to help with a 1.1.5 release if that would help. My concern here is we will be releasing uPortal on Pluto 1.1 and it would be nice to be on a released version of Pluto instead of a 1.1.5-SNAPSHOT.

Thank you,
-Eric

[EMAIL PROTECTED] wrote:

Thanks, Eric, for your heads up on this issue. Can you create a Jira issue?
A patch would also be very helpful.

Off the top of my head. I suggest that we initialize the
PortletDD.expirationCache field to some non-valid value (< -1), rather than
its current initial value of zero. It's probably best to make this value a
public constant. (called EXPIRATION_CACHE_UNSET), and put it in the
org.apache.pluto.Constants class in the pluto-container module. Do you --
or anyone else -- have any other ideas?

BTW, -- for those who don't know -- Pluto does not implement expiration
caching as it is an optional service.

TIA
/Craig







I'm working on updating the uPortal trunk to use Pluto 1.1 and have a
question about PortletDD.getExpirationCache()

At PLT.18.1 line 23 the spec says that if a portlet does not set an
expiration cache value in portlet.xml the corresponding request property
should be ignored. Since PortletDD.getExpirationCache() retuns an int
how can I tell if it was set or not?

Thanks,
-Eric

Eric Dalquist <[EMAIL PROTECTED] it.wisc.edu> To pluto-user@portals.apache.org 11/18/2007 06:44 cc PM Subject PortletDD & getExpirationCache Please respond to [EMAIL PROTECTED] s.apache.org

smime.p7s
Description: S/MIME Cryptographic Signature