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/04 15:03:21 UTC
[vote] Let our environment abtractions extend the http servlet ones
I would like o.a.c.environment.[Request|Response|Session] to extend
javax.servlet.http.Http[ServletRequest|ServletResponse|Session]
respectively.
The gain of doing so is that it will be easier to reuse Cocoon
components outside Cocoon and that it will be simpler to use Cocoon
together with other frameworks (see
http://thread.gmane.org/gmane.text.xml.cocoon.devel/59035/focus=59143
for a discussion about this).
A drawback is that some slight back incompatibility is introduced. The
most important one Request.getSession will have HttpSession as return
type instead of Session, and that user code needs to switch from Session
to HttpSession or downcast the return value to Session. Uses of
o.a.c.environment.Cookie needs to be switched to
javax.servlet.http.Cookie, (which has exactly the same API), see
http://article.gmane.org/gmane.text.xml.cocoon.devel/74322 and
http://thread.gmane.org/gmane.text.xml.cocoon.devel/74276.
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.
Please cast your vote!
/Daniel
Re: [vote] Let our environment abtractions extend the http servlet
ones
Posted by Joerg Heinicke <jo...@gmx.de>.
On 07.08.2007 3:46 Uhr, Daniel Fagerstrom wrote:
>> Anyway, +1 for me to do it in 2.3. We can deprecate them now in 2.2.
>
> Unfortunately it is more complicated than that.
You are right. I had deprecating our environment abstractions completely
in mind. But when reading this I remembered some extensions for sitemap
stuff you mentioned recently.
Joerg
Re: [vote] Let our environment abtractions extend the http servlet
ones
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Alfred Nathaniel wrote:
> 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.
>
> 3.) In 2.3 remove getCocoonXXX and o.a.c.e.XXX.
>
> 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?).
>
> 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.
+1
Vadim
Re: [vote] Let our environment abtractions extend the http servlet
ones
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
Re: [vote] Let our environment abtractions extend the http servlet
ones
Posted by Alfred Nathaniel <an...@apache.org>.
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.
3.) In 2.3 remove getCocoonXXX and o.a.c.e.XXX.
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?).
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.
Cheers, Alfred.
Re: [vote] Let our environment abtractions extend the http servlet
ones
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Joerg Heinicke skrev:
> On 04.08.2007 9:03 Uhr, Daniel Fagerstrom wrote:
>
>> 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.
>
> Can you please clarify what exactly this vote is now about?
It is about "letting our environment abtractions extend the http servlet
ones" in Cocoon 2.2. But with the extra condition that if we start the
process of releasing RC2 soon, we wait with the environment
modifications until 2.3.
Now Reinhard will not be able to take care about the release until mid
September as earliest. And no ones else has volunteered. So currently it
seem like that I would have plenty of time to introduce and test the
environment changes before a new release (given that we agree about
doing it).
> To do it at all thought we had already decided that some time ago)?
As it requires a non-compatible API change a vote is needed (although a
lazy vote maybe would have been enough). I don't remember that we have
voted about it.
> To do it with upcoming 2.2 or in 2.3? What made me wonder was
> Reinhard's mentioning of not having announced 2.2 RC 1 yet (what I
> found a rather lame excuse ;) ).
As long as we clearly document the change in the release note, I don't
see that it would be such a problem.
> Anyway, +1 for me to do it in 2.3. We can deprecate them now in 2.2.
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.
So as this change cannot be done in steps, users will need to update
their code directly, be it in 2.2 or 2.3. So are not simplifying
anything by waiting. And by introducing the changes we will greatly
simplify integration between Cocoon and other servlet frameworks. So
lets do this ASAP!
/Daniel
Re: [vote] Let our environment abtractions extend the http servlet
ones
Posted by Joerg Heinicke <jo...@gmx.de>.
On 04.08.2007 9:03 Uhr, Daniel Fagerstrom wrote:
> 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.
Can you please clarify what exactly this vote is now about? To do it at
all thought we had already decided that some time ago)? To do it with
upcoming 2.2 or in 2.3? What made me wonder was Reinhard's mentioning of
not having announced 2.2 RC 1 yet (what I found a rather lame excuse ;) ).
Anyway, +1 for me to do it in 2.3. We can deprecate them now in 2.2.
Joerg
Re: [vote] Let our environment abtractions extend the http servlet
ones
Posted by Felix Knecht <fe...@otego.com>.
> Please cast your vote!
+1 for C2.3
Felix
Re: [vote] Let our environment abtractions extend the http servlet
ones
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Daniel Fagerstrom skrev:
> I would like o.a.c.environment.[Request|Response|Session] to extend
> javax.servlet.http.Http[ServletRequest|ServletResponse|Session]
> respectively.
+1
/Daniel
Re: [vote] Let our environment abtractions extend the http servlet
ones
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz pisze:
>>
>> If we follow our release policies, we wouldn't be allowed to introduce
>> this change for any 2.2.x release and 2.3 is far away I'd guess. But
>> since we have released the first series of RC1 without having
>> announced them so far, my vote is +1.
>
> Reinhard, have you read this e-mail[1]? Last paragraph is especially
> important:
>
> I also think that we could release cocoon-core:2.3 just after I
> finish changes to Object Model and
> Expression handling so people can benefit from it right away.
>
> If we agreed on this plan we could release Cocoon 2.3 quickly along with
> Daniel's proposed changes. WDYT?
Sorry, I've overlooked it but fine for me. Important ist that we enter into a
more frequent release cycle and then pick a version number that fits with our
release policy. This probably means that 2.3 isn't that far away then I had
expected before :-)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [vote] Let our environment abtractions extend the http servlet
ones
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz pisze:
>
> If we follow our release policies, we wouldn't be allowed to introduce
> this change for any 2.2.x release and 2.3 is far away I'd guess. But
> since we have released the first series of RC1 without having announced
> them so far, my vote is +1.
Reinhard, have you read this e-mail[1]? Last paragraph is especially important:
I also think that we could release cocoon-core:2.3 just after I finish changes to Object Model and
Expression handling so people can benefit from it right away.
If we agreed on this plan we could release Cocoon 2.3 quickly along with Daniel's proposed changes. WDYT?
[1] http://article.gmane.org/gmane.text.xml.cocoon.devel/74296
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: [vote] Let our environment abtractions extend the http servlet
ones
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> I would like o.a.c.environment.[Request|Response|Session] to extend
> javax.servlet.http.Http[ServletRequest|ServletResponse|Session]
> respectively.
>
> The gain of doing so is that it will be easier to reuse Cocoon
> components outside Cocoon and that it will be simpler to use Cocoon
> together with other frameworks (see
> http://thread.gmane.org/gmane.text.xml.cocoon.devel/59035/focus=59143
> for a discussion about this).
>
> A drawback is that some slight back incompatibility is introduced. The
> most important one Request.getSession will have HttpSession as return
> type instead of Session, and that user code needs to switch from Session
> to HttpSession or downcast the return value to Session. Uses of
> o.a.c.environment.Cookie needs to be switched to
> javax.servlet.http.Cookie, (which has exactly the same API), see
> http://article.gmane.org/gmane.text.xml.cocoon.devel/74322 and
> http://thread.gmane.org/gmane.text.xml.cocoon.devel/74276.
>
> 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.
If we follow our release policies, we wouldn't be allowed to introduce this
change for any 2.2.x release and 2.3 is far away I'd guess. But since we have
released the first series of RC1 without having announced them so far, my vote
is +1.
--
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 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
--------------------------------------------------------------------
[vote result] Let our environment abtractions extend the http servlet
ones
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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] Let our environment abtractions extend the http servlet
ones
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom pisze:
>
> 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.
>
> Please cast your vote!
You could guessed it: +1! :-)
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/