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
