cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [PROPOSAL] Cocoon HttpSession implement javax HttpSession
Date Wed, 04 Feb 2004 09:05:53 GMT
Geoff Howard wrote:

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

I sure am. I remember a *very* hot discussion with a developer friend of 
mine that believes that our wrappers are bullshit. In fact I know that 
the use of the servlet interfacts is a very common practice, wether we 
like it or not.

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

AFAIK this is exactly what happens.

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

Personally, let me tell you that I hate also this thing. Inside me, I 
have the feeling that keeping the "real" session available sucks big 
time, and has created the monster that makes us use incoming streams 
only with servlets. Blah :-P

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

I guess you come in a bit late in the game ;-) as this was discussed *a 
lot* before. We have an abstraction layer, that's it. The question IMHO 
is simply how to provide these with the underlying thing they need in a 
simple way.

> Wait, now I've just hit on the biggest point here: what common 
> abstraction layer should we share with everyone?  None exists

:-?  I don't get it, Cocoon *does* have an abstraction layer...

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

Cocoon is not only about Http, so an HttpSession is not a good 
abstraction. It's superclass might be, but usually it's not the one used.

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

Which means AFAIS that we should provide alternative views of our 

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

Well, to be *really* consistent with ourselves, we should make it 
possible for the users to obtain an HttpSession from our session, 
*whatever* environment they use. That means that in theory they should 
be able to use the CLI with it, and it should still work.

You don't like wrapping a wrapper? Well, that's the only way we can 
obtain true abstraction *and* not have to modify the client code. Wanna 
write a wrapper that implements HttpSession and extends our Session? I 
tend to think that it's the most consistent solution.

   javax.*.Session s = o.a.c.e.Session.getUtilVersion("servlet-http");

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message