You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Daniel Fagerstrom <da...@nada.kth.se> on 2007/08/10 17:58:27 UTC
[vote result] Let our environment abtractions extend the http servlet
ones
Daniel Fagerstrom skrev:
> I would like o.a.c.environment.[Request|Response|Session] to extend
> javax.servlet.http.Http[ServletRequest|ServletResponse|Session]
> respectively.
...
> I don't want this to collide with releasing 2.2, so I'll wait with
> introducing the changes if there is any risk for that.
Results:
* +1 votes from Reinhard, Grzegorz, Jorg and me
* +1 votes for doing it in C2.2 with a detailed proposal about how to
handle deprecation
(http://marc.info/?l=xml-cocoon-dev&m=118651217532624&w=2) from Alfred
and Vadim
* +1 votes for doing it in C2.3 from Felix and Joerg
It is not completely obvious what to do from this. But given that we
handle deprecation according to Alfred's proposal, 6 persons voted for
my original proposal of doing the changes in 2.2 (given that it is not
interfering with the release) and no one voted against it. As no one has
volunteered to do the release until mid September, it will not interfere
with the release.
So I will implement my proposal with Alfred's deprecation scheme in the
beginning of next week.
/Daniel
Re: [vote result] Let our environment abtractions extend the http
servlet ones
Posted by Grzegorz Kossakowski <gk...@apache.org>.
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);
>
> WDYT?
+1
<snip/>
> 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 in
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 to
avoid confusion. Of course, it it makes sense we would have to migrate data from these files, first.
> 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
http://cocoon.zones.apache.org/daisy/cdocs-forms/g1/1351.html
Thanks for your work!
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** 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. ***
Re: [vote result] Let our environment abtractions extend the http
servlet ones
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> 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?
There is a changes.xml file for each module. For such general changes I suggest
using trunk/core/cocoon-core/src/changes.xml. Unfortunatly I haven't found a
simple way to use the status.xml files easily with Maven 2.
> Do we have some special area in the 2.2 documentation for upgrade how to?
now we have :-)
see http://cocoon.zones.apache.org/daisy/cdocs-site-22/g2/1402.html
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [vote result] Let our environment abtractions extend the http
servlet ones
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Daniel Fagerstrom skrev:
> Daniel Fagerstrom skrev:
>> I would like o.a.c.environment.[Request|Response|Session] to extend
>> javax.servlet.http.Http[ServletRequest|ServletResponse|Session]
>> respectively.
...
> So I will implement my proposal with Alfred's deprecation scheme in the
> beginning of next week.
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.
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);
WDYT?
For all the javax.servlet.http methods that wasn't part of our
environment instructions I added methods that throws
UnsupportedOperationException to the AbstractRequest, AbstractRespose
and the AbstractSession classes. We can implement these methods later if
people need them.
For the back incompatibilities in the rest of the code I switched most
uses of Session to HttpSession and most uses of
org.apache.cocoon.environment.Cookie to javax.servlet.http.Cookie. In
the few cases where it would have affected the api of the classes I
downcasted getSession() to Session respectively used getCocoonCookie
instead.
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.
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?
Do we have some special area in the 2.2 documentation for upgrade how to?
/Daniel
Re: [vote result] Let our environment abtractions extend the http
servlet ones
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Daniel Fagerstrom skrev:
>> I would like o.a.c.environment.[Request|Response|Session] to extend
>> javax.servlet.http.Http[ServletRequest|ServletResponse|Session]
>> respectively.
> ...
>> I don't want this to collide with releasing 2.2, so I'll wait with
>> introducing the changes if there is any risk for that.
>
> Results:
> * +1 votes from Reinhard, Grzegorz, Jorg and me
>
> * +1 votes for doing it in C2.2 with a detailed proposal about how to
> handle deprecation
> (http://marc.info/?l=xml-cocoon-dev&m=118651217532624&w=2) from Alfred
> and Vadim
>
> * +1 votes for doing it in C2.3 from Felix and Joerg
>
> It is not completely obvious what to do from this. But given that we
> handle deprecation according to Alfred's proposal, 6 persons voted for
> my original proposal of doing the changes in 2.2 (given that it is not
> interfering with the release) and no one voted against it. As no one has
> volunteered to do the release until mid September, it will not interfere
> with the release.
>
> So I will implement my proposal with Alfred's deprecation scheme in the
> beginning of next week.
I interpret the results the same way like you.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------