Re: 1.1.5 release

Elliot Metsger <[email protected]> Fri, 30 Nov 2007 09:04:55 -0500
Newsgroups gmane.comp.jakarta.pluto.user
Message-ID <[email protected]>
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
>>
>> [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
>>>
>>>
>>>
>>>                                                                            
>>>              Eric 
>>> Dalquist                                                              
>>> <eric.dalquist@do                                             
>>>              
>>> it.wisc.edu>                                               To 
>>>                                        
>>> [email protected]                    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
>>>
>>>