cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: [PROPOSAL] Cocoon HttpSession implement javax HttpSession
Date Tue, 03 Feb 2004 21:51:27 GMT
Geoff Howard wrote:

> Vadim Gritsenko wrote:
>> Geoff Howard wrote:
>>> Vadim Gritsenko wrote:
>> ...
>>>>> It already does actually implement it's non-deprecated methods but 
>>>>> does not declare it, so cannot be cast or used polymorphic-ly.  
>>>>> See below trail from users for what seems to be valid use-case.
>>>> Underlying Http* objects are already available [1] for the 
>>>> integration with legacy applications, so there is no reason to hard 
>>>> code dependency on Http* into the Cocon core. Vice versa, we are 
>>>> trying to move away from this dependency, as far and as fast as 
>>>> possible.
>>> Don't see how this would introduce any new core dependency - the 
>>> affected class is in the http impl of env.  I'm aware of the legacy 
>>> helpers below, but Session is not exposed.
>>> Are you saying the best-practice method of getting a javax 
>>> HttpSession is to get the Request using the legacy helper methods 
>>> below and call its getSession()?
>> I'd not use the word "best-practice" in this context. I'd say "If no 
>> other way is possible... and you just have to have javax http 
>> classes... here is javax HttpRequest/Response/etc for you, but don't 
>> tell anybody else that it is available" ;-)
>> Those objects were exactly placed into the object model for purposes 
>> of integration of legacy code relying on the 
>> HttpServletRequest/Response/etc (or 
>> ActionPortletRequest/RenderPortletRequest, if we are talking about 
>> portlets).
> It seems to me though that integration with a third party db 
> persistance layer which happens to require a javax Session (and from 
> their perspective the javax Session is nothing like "legacy") is a 
> perfectly legitimate use, and does not need to be discouraged.

Well, if it's persistence layer, why would it need servlets? How about 
desktop Swing app using persistence? Or command line tool? So, 
developers of those libraries should be encouraged to move away from 
servlet API and to something more appropriate in theirs case.

> Now, I know nothing of Cayenne - whether it's good or bad,

May be its good and those classes (depending on servlets) are only 
samples or Servlet's integration layer? Then you should develop Cocoon 
integration layer.

> whether the requirement of access to an http session is good or bad in 
> their case, etc. but does that matter?  I understand the need to use 
> and preserve our environment abstraction, but doesn't it seem a little 
> heavy handed in this case?

In my opinion, if you to extend/implement Cocoon's HttpSession object 
from Servlet's HttpSerlvetSession object, this would be more 
heavy-handier :-) solution. We already provide Servlet's Session object, 
and it is much more stable contract (Sacred Object Model) than relying 
on implementation of the o.a.c.e.Session which under some conditions 
happens to be o.a.c.e.h.HttpSession which implements j.s.h.HttpSession 
(Little Dirty Details).

So, heavy-handiness is relative concept :-)


View raw message