cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: [vote result] Let our environment abtractions extend the http servlet ones
Date Tue, 14 Aug 2007 09:41:05 GMT
Daniel Fagerstrom pisze:
> I have commited the changes to the trunk. Everything compiles (removed 
> the cocoon artifacts in them maven rep first) and all tests runs (except 
> ZipSourceTestCase which is unrelated to this change). I tested a couple 
> of samples as well and they still works. But I modified a lot of code so 
> I would be surprised if I didn't miss anything. Please report if there 
> are any problems.

I briefly tested what I have at local with your changes and everyhing works ok.

> For the actual changes I followed Alfred's proposal. A small thing that 
> I missed concerning possibly incompatible changes is the former method:
>   org.apache.cocoon.environment.Cookie Response.createCookie(String 
> name, String value);
> Which I replaced with:
>   javax.servlet.http.Cookie createCookie(String name, String value);
>   /*
>    * @deprecated use {@link #createCookie(String, String)} instead.
>    */
>   org.apache.cocoon.environment.Cookie createCocoonCookie(String name, 
> String value);
> But thinking about it having a factory method for 
> javax.servlet.http.Cookie seem quite pointless, we should probably just 
> deprecate the factory method and recomend them to use the constructor 
> instead:
>   /*
>    * @deprecated use <code>new {@link javax.servlet.http.Cookie(String, 
> String)}</code> instead.
>    */
>   org.apache.cocoon.environment.Cookie createCocoonCookie(String name, 
> String value);



> I haven't fixed 2.1 yet. As I haven't worked on 2.1 for years I would 
> happy if someone volunteered to do it. Otherwise I'll fix it in a few 
> days when we are certain that the trunk works.

Daniel, I thought that we vote for switch in trunk not in 2.1. I would vote -1 for such changes
2.1.x. We really need to start consider this branch as maintenance branch.

> I saw that trunk/commons/status.xml hasn't been touched for nearly a 
> year. Should I document the change there or do we have some new place 
> for documenting changes in the trunk?

I'm almost sure that we should document changes in src/changes/changes.xml file that each
module is 
supposed to contain. If someone confirm this I think we should remove all old status.xml files
avoid confusion. Of course, it it makes sense we would have to migrate data from these files,

> Do we have some special area in the 2.2 documentation for upgrade how to?

In the past I used to create new document describing how to migrate in detail. See

Thanks for your work!

Grzegorz Kossakowski
*** My Internet Service Provider breaks my internet connection                ***
*** incessantly so I'll not be able to respond to e-mails                     ***
*** regularly and my work will be somehow irregular.                          ***
*** I'm already trying to switch ISP but it will take handful amount of time. ***

View raw message