cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <coc...@leverageweb.com>
Subject Re: [PROPOSAL] Cocoon HttpSession implement javax HttpSession
Date Tue, 03 Feb 2004 20:46:35 GMT
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.  Now, I know 
nothing of Cayenne - whether it's good or bad, 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?

Geoff


Mime
View raw message