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. Now, I know nothing of Cayenne - whether it's good or bad, whether the requirement of access to an http session is good or bad in their case, etc. but does that matter? I understand the need to use and preserve our environment abstraction, but doesn't it seem a little heavy handed in this case?
Geoff
