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 abstraction.
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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------