Re: PortletDD & getExpirationCache

[Eric Dalquist]

I was thinking the same thing. The most obvious way would be to change the field to an Integer instead of an int and then a null check could be made. That would change the public API of the Pluto object model though and likely wouldn't be desirable.

-Eric

[EMAIL PROTECTED] wrote:

I would thinking declaring the constant EXPIRATION_CACHE_UNSET = Integer.MIN_VALUE in the PortletDD object and initializing the expirationCache to that would be good. I'll find some time today or tomorrow to create a Jira issue and attach a patch for 1.1.4

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