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
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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
|