You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-user@portals.apache.org by Eric Dalquist <er...@doit.wisc.edu> on 2007/11/19 00:44:19 UTC
PortletDD & getExpirationCache
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
Re: PortletDD & getExpirationCache
Posted by Eric Dalquist <er...@doit.wisc.edu>.
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.
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
-Eric
CDoremus@hannaford.com 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
>
>
>
>
> Eric Dalquist
> <eric.dalquist@do
> it.wisc.edu> To
> pluto-user@portals.apache.org
> 11/18/2007 06:44 cc
> PM
> Subject
> PortletDD & getExpirationCache
> Please respond to
> pluto-user@portal
> 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
>
>
Re: 1.1.5 release
Posted by Elliot Metsger <em...@jhu.edu>.
Oh wow more stuff popped up :-) 11 issues now!
Great stuff - if there are maintenance type issues that don't have a
1.1.5 "Fix-for" that you'd like to see in 1.1.5 please do update your
Jira issues (as some already have)
Thanks a lot,
Elliot
Elliot Metsger wrote:
> There are four unresolved issues for a 1.1.5 release, so I can commit
> cycles to get a 1.1.5 out the door.
>
> In order to minimize the impact on the 286 work, I won't apply any fixes
> to trunk - but I will create a duplicate issue so we don't have a
> regression when the next release (be it a 1.2 or 286) happens.
>
> Sorry I've just been mega-busy lately.
>
> E
>
> Eric Dalquist wrote:
>> 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
>>
>> CDoremus@hannaford.com 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
>>>
>>>
>>>
>>>
>>> Eric
>>> Dalquist
>>> <eric.dalquist@do
>>>
>>> it.wisc.edu> To
>>>
>>> pluto-user@portals.apache.org 11/18/2007
>>> 06:44 cc
>>> PM
>>>
>>> Subject PortletDD &
>>> getExpirationCache Please respond
>>> to
>>> pluto-user@portal
>>>
>>> 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
>>>
>>>
1.1.5 release
Posted by Elliot Metsger <em...@jhu.edu>.
There are four unresolved issues for a 1.1.5 release, so I can commit
cycles to get a 1.1.5 out the door.
In order to minimize the impact on the 286 work, I won't apply any fixes
to trunk - but I will create a duplicate issue so we don't have a
regression when the next release (be it a 1.2 or 286) happens.
Sorry I've just been mega-busy lately.
E
Eric Dalquist wrote:
> 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
>
> CDoremus@hannaford.com 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
>>
>>
>>
>>
>> Eric
>> Dalquist
>> <eric.dalquist@do
>>
>> it.wisc.edu> To
>>
>> pluto-user@portals.apache.org 11/18/2007
>> 06:44 cc
>> PM
>>
>> Subject PortletDD &
>> getExpirationCache Please respond
>> to
>> pluto-user@portal
>>
>> 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
>>
>>
Re: PortletDD & getExpirationCache
Posted by Eric Dalquist <er...@doit.wisc.edu>.
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
CDoremus@hannaford.com 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
>
>
>
>
> Eric Dalquist
> <eric.dalquist@do
> it.wisc.edu> To
> pluto-user@portals.apache.org
> 11/18/2007 06:44 cc
> PM
> Subject
> PortletDD & getExpirationCache
> Please respond to
> pluto-user@portal
> 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
>
>
Re: PortletDD & getExpirationCache
Posted by CD...@hannaford.com.
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
<eric.dalquist@do
it.wisc.edu> To
pluto-user@portals.apache.org
11/18/2007 06:44 cc
PM
Subject
PortletDD & getExpirationCache
Please respond to
pluto-user@portal
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