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 2006/02/04 15:28:57 UTC

[Vote] Let the environment interfaces extend the javax.servlet.http ones

As discussed in:

http://marc.theaimsgroup.com/?t=113432388200001&r=1&w=2
and less radical in
http://marc.theaimsgroup.com/?t=113822674300001&r=1&w=2

There would be a lot to gain by basing our environment abstraction on 
the javax.servlet.http set of interfaces in trunk. I propose that we make:

o.a.c.environment.Request  extend javax.servlet.http.HttpServletRequest
o.a.c.environment.Response extend javax.servlet.http.HttpServletResponse
o.a.c.environment.Context  extend javax.servlet.ServletContext
o.a.c.environment.Session  extend javax.servlet.http.HttpSession
o.a.c.environment.Cookie   extend javax.servlet.http.HttpCookie

This shouldn't create any compatibility problems, it will make it easier 
to integrate Cocoon with the rest of the world, it will simplify the 
architecture, and it would be a great advantage for the block 
architecture work.

I assume that we should go for servlet 2.3 as trunk use that, but I have 
no strong opinions about it. Please comment if you think 2.4 would be a 
better idea.

Please cast your vote.

/Daniel

Re: [Vote] Let the environment interfaces extend the javax.servlet.http ones

Posted by Jorg Heymans <jh...@domek.be>.
Daniel Fagerstrom wrote:

> 
> This shouldn't create any compatibility problems, it will make it easier
> to integrate Cocoon with the rest of the world, it will simplify the
> architecture, and it would be a great advantage for the block
> architecture work.
>

+1



Jorg



Re: [Vote] Let the environment interfaces extend the javax.servlet.http ones

Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Daniel Fagerstrom skrev:
> As discussed in:
> 
> http://marc.theaimsgroup.com/?t=113432388200001&r=1&w=2
> and less radical in
> http://marc.theaimsgroup.com/?t=113822674300001&r=1&w=2
> 
> There would be a lot to gain by basing our environment abstraction on 
> the javax.servlet.http set of interfaces in trunk. I propose that we make:
> 
> o.a.c.environment.Request  extend javax.servlet.http.HttpServletRequest
> o.a.c.environment.Response extend javax.servlet.http.HttpServletResponse
> o.a.c.environment.Context  extend javax.servlet.ServletContext
> o.a.c.environment.Session  extend javax.servlet.http.HttpSession
> o.a.c.environment.Cookie   extend javax.servlet.http.HttpCookie
> 
> This shouldn't create any compatibility problems, it will make it easier 
> to integrate Cocoon with the rest of the world, it will simplify the 
> architecture, and it would be a great advantage for the block 
> architecture work.
> 
> I assume that we should go for servlet 2.3 as trunk use that, but I have 
> no strong opinions about it. Please comment if you think 2.4 would be a 
> better idea.
> 
> Please cast your vote.

+1

/Daniel

Re: [Vote] Let the environment interfaces extend the javax.servlet.http ones

Posted by Ralph Goers <Ra...@dslextreme.com>.
+0

Daniel Fagerstrom wrote:

> As discussed in:
>
> http://marc.theaimsgroup.com/?t=113432388200001&r=1&w=2
> and less radical in
> http://marc.theaimsgroup.com/?t=113822674300001&r=1&w=2
>
> There would be a lot to gain by basing our environment abstraction on 
> the javax.servlet.http set of interfaces in trunk. I propose that we 
> make:
>
> o.a.c.environment.Request  extend javax.servlet.http.HttpServletRequest
> o.a.c.environment.Response extend javax.servlet.http.HttpServletResponse
> o.a.c.environment.Context  extend javax.servlet.ServletContext
> o.a.c.environment.Session  extend javax.servlet.http.HttpSession
> o.a.c.environment.Cookie   extend javax.servlet.http.HttpCookie
>
> This shouldn't create any compatibility problems, it will make it 
> easier to integrate Cocoon with the rest of the world, it will 
> simplify the architecture, and it would be a great advantage for the 
> block architecture work.
>
> I assume that we should go for servlet 2.3 as trunk use that, but I 
> have no strong opinions about it. Please comment if you think 2.4 
> would be a better idea.
>
> Please cast your vote.
>
> /Daniel


Re: [Vote] Let the environment interfaces extend the javax.servlet.http ones

Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Sylvain Wallez skrev:
> Carsten Ziegeler wrote:
>> Sylvain Wallez wrote:
>>  
>>> One of the possible solutions is to make generally and officially 
>>> available the ServletRequest and ServletResponse entries of the 
>>> object model that are populated by the HttpEnvironment. This creates 
>>> a migration path towards the standard servlet interfaces.
>>>
>>>     
>> They are already officially available in an http environment, so we could
>> end up with the question what to do in other environments. Generating
>> them?
>>   
> 
> Yep. Just as our HttpRequest is a wrapper around the ServletRequest, 
> we'll have to write wrappers around oace.Request that implement 
> jsh.HttpServletRequest ;-)

IIUC. the only place where we need to support our environment interfaces
from a compatibility POV is in the object model. It would be enough to
introduce a thin wrapper in the object model and do all processing in
the rest of Cocoon based on the j.s.h interfaces.

For processing within the sitemap processor and pipelines we would need
a wrapper around jsh.HttpServletRequest that extends the input one with
the Cocoon specific getSitemap* methods (and possibly some more
methods). All functionality from oaceh.HttpRequest etc would be moved to
the new wrapper that implements jsh.HttpServletRequest, and
oaceh.HttpRequest would become a "pure" wrapper.

> 
> Hmm... now should this wrapper implement _Http_ServletRequest, or just 
> SerlvetRequest? The servlet API was designed to be extend in areas other 
> than http, but this never happened (e.g. portlets). Don't know...

I think it should implement HttpServletRequest, the ServletRequest 
doesn't know anything about the request URL, I wonder if that would make 
sense in Cocoon.

/Daniel


Re: [Vote] Let the environment interfaces extend the javax.servlet.http ones

Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>   
>> One of the possible solutions is to make generally and officially 
>> available the ServletRequest and ServletResponse entries of the object 
>> model that are populated by the HttpEnvironment. This creates a 
>> migration path towards the standard servlet interfaces.
>>
>>     
> They are already officially available in an http environment, so we could
> end up with the question what to do in other environments. Generating
> them?
>   

Yep. Just as our HttpRequest is a wrapper around the ServletRequest, 
we'll have to write wrappers around oace.Request that implement 
jsh.HttpServletRequest ;-)

Hmm... now should this wrapper implement _Http_ServletRequest, or just 
SerlvetRequest? The servlet API was designed to be extend in areas other 
than http, but this never happened (e.g. portlets). Don't know...

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://bluxte.net                     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Re: [Vote] Let the environment interfaces extend the javax.servlet.http ones

Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> Daniel Fagerstrom wrote:
>> Carsten Ziegeler skrev:
>>> Hmm, I think it will, e.g. j.s.h.HttpServletRequest#getSession returns
>>> a j.s.h.HttpSession while o.a.c.e.Request#getSession returns a
>>> o.a.c.e.Session and overriding just the return type is not possible 
>>> in java.
>> Didn't think about that.
>>
>> If we let o.a.c.e.Request#getSession have j.s.h.HttpSession as return 
>> type and then let it return something that implements o.a.c.e.Session 
>> You can always cast the return type of to a o.a.c.e.Session.
>>
>> Wouldn't the need to add a few casts be a rather minor inconvenience 
>> that is worthwhile for simplifying the framework and make it easier to 
>> connect to the rest of the world?
> 
> This isn't a minor inconvenience, as it will break every code out there 
> that gets the session from a oace.Request, and there is *a lot*.
Exactly.

> So -1, although I was initially in favor of this change.
Yeah, I wasn't against it either and did not see this problem earlier
on, but as soon as Daniel listed the changes in this vote thread, I
noticed the problem :(

> 
> One of the possible solutions is to make generally and officially 
> available the ServletRequest and ServletResponse entries of the object 
> model that are populated by the HttpEnvironment. This creates a 
> migration path towards the standard servlet interfaces.
> 
They are already officially available in an http environment, so we could
end up with the question what to do in other environments. Generating
them?

Carsten
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: [Vote] Let the environment interfaces extend the javax.servlet.http ones

Posted by Sylvain Wallez <sy...@apache.org>.
Daniel Fagerstrom wrote:
> Carsten Ziegeler skrev:
>> Hmm, I think it will, e.g. j.s.h.HttpServletRequest#getSession returns
>> a j.s.h.HttpSession while o.a.c.e.Request#getSession returns a
>> o.a.c.e.Session and overriding just the return type is not possible 
>> in java.
>
> Didn't think about that.
>
> If we let o.a.c.e.Request#getSession have j.s.h.HttpSession as return 
> type and then let it return something that implements o.a.c.e.Session 
> You can always cast the return type of to a o.a.c.e.Session.
>
> Wouldn't the need to add a few casts be a rather minor inconvenience 
> that is worthwhile for simplifying the framework and make it easier to 
> connect to the rest of the world?

This isn't a minor inconvenience, as it will break every code out there 
that gets the session from a oace.Request, and there is *a lot*.

So -1, although I was initially in favor of this change.

One of the possible solutions is to make generally and officially 
available the ServletRequest and ServletResponse entries of the object 
model that are populated by the HttpEnvironment. This creates a 
migration path towards the standard servlet interfaces.

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://bluxte.net                     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Re: [Vote] Let the environment interfaces extend the javax.servlet.http ones

Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler skrev:
> Daniel Fagerstrom wrote:
>> As discussed in:
>>
>> http://marc.theaimsgroup.com/?t=113432388200001&r=1&w=2
>> and less radical in
>> http://marc.theaimsgroup.com/?t=113822674300001&r=1&w=2
>>
>> There would be a lot to gain by basing our environment abstraction on 
>> the javax.servlet.http set of interfaces in trunk. I propose that we make:
>>
>> o.a.c.environment.Request  extend javax.servlet.http.HttpServletRequest
>> o.a.c.environment.Response extend javax.servlet.http.HttpServletResponse
>> o.a.c.environment.Context  extend javax.servlet.ServletContext
>> o.a.c.environment.Session  extend javax.servlet.http.HttpSession
>> o.a.c.environment.Cookie   extend javax.servlet.http.HttpCookie
>>
>> This shouldn't create any compatibility problems, 
> Hmm, I think it will, e.g. j.s.h.HttpServletRequest#getSession returns
> a j.s.h.HttpSession while o.a.c.e.Request#getSession returns a
> o.a.c.e.Session and overriding just the return type is not possible in java.

Didn't think about that.

If we let o.a.c.e.Request#getSession have j.s.h.HttpSession as return 
type and then let it return something that implements o.a.c.e.Session 
You can always cast the return type of to a o.a.c.e.Session.

Wouldn't the need to add a few casts be a rather minor inconvenience 
that is worthwhile for simplifying the framework and make it easier to 
connect to the rest of the world?

/Daniel


Re: [Vote] Let the environment interfaces extend the javax.servlet.http ones

Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom wrote:
> As discussed in:
> 
> http://marc.theaimsgroup.com/?t=113432388200001&r=1&w=2
> and less radical in
> http://marc.theaimsgroup.com/?t=113822674300001&r=1&w=2
> 
> There would be a lot to gain by basing our environment abstraction on 
> the javax.servlet.http set of interfaces in trunk. I propose that we make:
> 
> o.a.c.environment.Request  extend javax.servlet.http.HttpServletRequest
> o.a.c.environment.Response extend javax.servlet.http.HttpServletResponse
> o.a.c.environment.Context  extend javax.servlet.ServletContext
> o.a.c.environment.Session  extend javax.servlet.http.HttpSession
> o.a.c.environment.Cookie   extend javax.servlet.http.HttpCookie
> 
> This shouldn't create any compatibility problems, 
Hmm, I think it will, e.g. j.s.h.HttpServletRequest#getSession returns
a j.s.h.HttpSession while o.a.c.e.Request#getSession returns a
o.a.c.e.Session and overriding just the return type is not possible in java.

So, I'm -1 on this because it creates compatibility problems.

Carsten


-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: [Vote] Let the environment interfaces extend the javax.servlet.http ones

Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 4 févr. 06, à 15:28, Daniel Fagerstrom a écrit :

> Please cast your vote.

+1

-Bertrand