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
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
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
