cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [vote] Let our environment abtractions extend the http servlet ones
Date Wed, 08 Aug 2007 07:25:29 GMT
Alfred Nathaniel skrev:
> On Tue, 2007-08-07 at 09:46 +0200, Daniel Fagerstrom wrote:
>   
>> Unfortunately it is more complicated than that. The non-compatible 
>> change is that Request.getSession switches return value from 
>> o.a.c.environment.Session to javax.servlet.http.HttpSession and that 
>> Request.getCookie switch return value from o.a.c.environment.Cookie to 
>> javax.servlet.http.Cookie. You, of course, cannot have a method with two 
>> different return types. So there is no point in deprecating 
>> Request.getSession and Request.getCookie in 2.2 as we not will have any 
>> replacements until 2.3 in that case. So the deprecation mechanism is 
>> AFAICS not applicable.
>>     
>
> How about this:
>
> 1.) In 2.1.11 add Request.getCocoonSession and Request.getCocoonCookie
> and deprecate the current methods.
>
> 2.) In 2.2 let o.a.c.e.XXX extend the standard interfaces, change return
> types of getXXX methods and deprecate getCocoonXXX methods.
>   
Seem like a good suggestion to me. It will give users that going the 
path of first upgrading to 2.1.11 and then to 2.2 a smooth path and the 
appropriate deprecation warnings when  they build their own code. It is 
important that we document what we are up to well in 2.1.11 so that 
users understand what is going on and where it is leading.
> 3.) In 2.3 remove getCocoonXXX and o.a.c.e.XXX.
>   
Removing o.a.c.e.XXX is a little bit more complicated as the Request 
interface has a few methods for handling sub sitemap paths. But maybe we 
could introduce a minimal interface for just those methods and deprecate 
o.a.c.e.XXX. Anyway, from our current speed in switching minor version, 
we might not be in such a hurry in deciding the exact details of 2.3 ;)
> That allows for a smoother transition path for user components because
> they can be made forwards compatible to work for both 2.1.11+ and 2.2
> (if Session/Cookie is the only incompatibility?).
>   
Yes, AFAICS, I tried the changes locally to be able to see the consequences.
> In any case, I am -1 on creating a 2.3 branch in the near future.  First
> we must get out 2.2 and let it season on trunk to reach production
> quality.  The parallel maintenance and forward and backward porting
> between 2.1 and 2.2 was a terrible resource drain which we should try to
> avoid as far as possible.
>   
Agree, I'll be -1 on branches as well.

/Daniel


Mime
View raw message