You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Geoff Howard <co...@leverageweb.com> on 2004/02/03 15:43:00 UTC
[PROPOSAL] Cocoon HttpSession implement javax HttpSession (Was Re:
javax.servlet.http.HttpSession access from XSP?)
Would anyone be opposed to making
org.apache.cocoon.environment.http.HttpSession implement
javax.servlet.http.HttpSession? 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.
For now, the deprecated methods could just be implemented to throw
UnsupportedOperationException or something.
Geoff
Geoff Howard wrote:
> Joerg Heinicke wrote:
>
>> On 02.02.2004 23:20, Phil Blake wrote:
>>
>>>>> How do I access the javax.servlet.http.HttpSession from within XSP?
>>>>> I know I have xsp-session but it is a
>>>>> org.apache.cocoon.environment.Session
>>>>> And request.getSession() also returns a
>>>>> org.apache.cocoon.environment.Session
>>>>> I've seen that the org.apache.cocoon.environment.http.HttpSession
>>>>> is created from the javax.servlet.http.HttpSession but I can't see
>>>>> how to access it from there.
>>>>
>>>>
>>>> I don't know exactly as I do not have written the code, but I think
>>>> hiding the HttpSession was intended. You only shall access the
>>>> Cocoon specific Session.
>>>>
>>>> What exactly do you want to do?
>>>
>>>
>>> I am using the database framework Cayenne. Like most web based
>>> client/server frameworks, it requires that you pass it an HttpSession
>>> to retrieve a context for that HttpSession.
>>>
>>> As there is no option here, I must supply the HttpSession, the
>>> question is - does cocoon provide access to it?
>>>
>>> I guess I could re-create a standard HttpSession from the cocoon
>>> HttpSession, but usually when I'm backed into such an ugly hack, it's
>>> because I haven't found the "proper" way. I'm assuming that cocoon
>>> would not completely obscure the standard HttpSession - even if it's
>>> wrapped it. Does anyone know the real story?
>>
>>
>> Cocoon's HttpSession is just a wrapper around standard servlet
>> HttpSession, but does not really give access to it. Have a look into
>> the source code:
>> http://cvs.apache.org/viewcvs.cgi/*checkout*/cocoon-2.1/src/java/org/apache/cocoon/environment/http/HttpSession.java?content-type=text%2Fplain&rev=1.2
>>
>> As the wrappedSession field has only default access and the class is
>> even final there remains only the way of adding an additional class in
>> the same package to get the unwrapped HttpSession - that's obviously
>> the "ugly hack".
>> I cc Carsten as he wrote the Cocoon HttpSession, maybe he knows of a
>> more standard way to get the unwrapped HttpSession.
>
>
> By the way, it's important that people know the basic reason Cocoon
> doesn't give you an HTTP session. Cocoon abstracts the environment so
> that it can be run from many different environments, not just
> http/servlet. Currently the command line interface is the only other
> implemented environment but even there dependency on servlet jar and
> HttpSession obviously makes no sense. Examples of other potential
> environments which have been discussed are email (via James) and JMS.
>
> Now, that doesn't mean it should be impossible to get to the HttpSession
> if you are in that environment and that's what we need to see. I think
> the method which is used in the other environment abstractions (Request
> for example) won't work here, but I don't see a reason cocoon's session
> couldn't implement HttpSession. Right now, it seems the only methods
> unimplemented from the javax interface are the deprecated methods.
> Another alternative would be to use JDK 1.3 dynamic proxy which may work
> if the code you pass the proxy to doesn't call the deprecated methods (I
> can't remember for sure if this is true).
>
> Geoff
Re: [PROPOSAL] Cocoon HttpSession implement javax HttpSession
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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)
---------------------------------------------------------------------
Re: [PROPOSAL] Cocoon HttpSession implement javax HttpSession
Posted by Geoff Howard <co...@leverageweb.com>.
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...
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
Re: [PROPOSAL] Cocoon HttpSession implement javax HttpSession
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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,
May be its good and those classes (depending on servlets) are only
samples or Servlet's integration layer? Then you should develop Cocoon
integration layer.
> 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?
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).
So, heavy-handiness is relative concept :-)
Vadim
Re: [PROPOSAL] Cocoon HttpSession implement javax HttpSession
Posted by Geoff Howard <co...@leverageweb.com>.
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. 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
Re: [PROPOSAL] Cocoon HttpSession implement javax HttpSession
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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).
Vadim
Re: [PROPOSAL] Cocoon HttpSession implement javax HttpSession
Posted by Geoff Howard <co...@leverageweb.com>.
Vadim Gritsenko wrote:
> Geoff Howard wrote:
>
>> Would anyone be opposed to making
>> org.apache.cocoon.environment.http.HttpSession implement
>> javax.servlet.http.HttpSession?
>
>
>
> Yes, me. I'm -1 on this.
>
>
>> 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()?
Geoff
> Vadim
>
>
> [1] See:
>
> http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/environment/http/HttpEnvironment.html#HTTP_REQUEST_OBJECT
>
>
> http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/environment/http/HttpEnvironment.java?r1=1.2&r2=1.3
>
>
> http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/php/java/org/apache/cocoon/generation/PhpGenerator.java?annotate=1.1
>
>
>
>
> .
>
Re: [PROPOSAL] Cocoon HttpSession implement javax HttpSession
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Geoff Howard wrote:
> Would anyone be opposed to making
> org.apache.cocoon.environment.http.HttpSession implement
> javax.servlet.http.HttpSession?
Yes, me. I'm -1 on this.
> 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.
Vadim
[1] See:
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/environment/http/HttpEnvironment.html#HTTP_REQUEST_OBJECT
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/environment/http/HttpEnvironment.java?r1=1.2&r2=1.3
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/php/java/org/apache/cocoon/generation/PhpGenerator.java?annotate=1.1