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 Wed, 04 Feb 2004 00:51:41 GMT
Ok, I should drop this but having shared a very tall beer with Vadim 
recently, I feel free to push it a little because I think the 
non-technical implications need to be thought about more.  I'm afraid no 
one else is listening, though...

Vadim Gritsenko wrote:

> 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,

Ok, I now know something:
http://www.objectstyle.org/cayenne/api/cayenne/org/objectstyle/cayenne/conf/BasicServletConfiguration.html

So in this case, it appears they have developed a special functionality 
which is restricted to use in Webapps (some kind of session-local 
config).  Now, we probably all agree that it might be better for re-use 
to abstract that concept so that other environments may take advantage 
of similar functionality.  However, if they deem it very unlikely that 
any such "other" environment will ever exist or be in scope for their 
project, then it also makes sense for them not to introduce abstraction 
for abstraction's sake.  Especially since javax.http... is already 
understood to be somewhat of an abstracted common-use api (if you stick 
in the webapp world).

> 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).

Wait, I'm not sure I'm understanding you.  We don't really "provide" the 
Servlet's Session - we use it but hide it.  You can get the wrapper, but 
can't use it as the real thing - for that you have to go out to the 
objectModel, get the javax Request, and ask it for the Session (or use a 
dynamic proxy).  All I was proposing was to make the wrapper either 
expose the real thing directly (via getRealSession for example) or to 
make it actually _also_ implement javax Session.  This would have no 
affect on the stable contract - which is still "expect a 
o.a.c.e.Session" if you are working within Cocoon.  But if you are in 
such an environment where you know you have an http session and always 
will, and have to provide a j.s.h.HttpSession to another API out of your 
control (as with Cayenne) I think it's going to sound really 
unreasonable to the rest of the outside world that they have to not use 
a well-known javax Interface but introduce an abstraction layer.

Wait, now I've just hit on the biggest point here: what common 
abstraction layer should we share with everyone?  None exists, so now we 
have to write integration code for every project's unique abstraction 
layer to the _Interface_ in javax.s.h package which was meant to be this 
very abstraction (though admittedly stuck in the http webapp world).

So, whether we make it easier to get at the javax classes or not I'm 
really feeling we have to come to the realization that there will be 
legitimate integration use cases which make using the javax interfaces 
not a secret hack, but a legitimate pattern.

> So, heavy-handiness is relative concept :-)

What I meant by that is that we are saying that we believe environment 
contracts should be abstracted - not only within our application, but 
also in all other applications which our users may want to integrate 
with.  Whether heavy-handed or not, it's not very practical because the 
fact is that there are other projects out there which are not going to care.

In the meantime :), I'm recommending that the user in this case either 
use a dynamic proxy to wrap the o.a.c.e.Session in the javax interface 
(and hope they don't use any of the unimplemented deprecated methods) or 
go out to the "real" Request and get the "real" session from there.

:P
Geoff


Mime
View raw message