XSP session diffs

[Mike Engelhart <me...@earthtrip.com>]

can please someone commit this before the next release:

Index: xml-cocoon/src/org/apache/cocoon/processor/xsp/xsp-java.xsl
===================================================================
RCS file: 
/home/cvspublic/xml-cocoon/src/org/apache/cocoon/processor/xsp/xsp-java.xsl,
v
retrieving revision 1.7
diff -r1.7 xsp-java.xsl
108c108
<         HttpSession session = request.getSession(true);
---
>         HttpSession session = request.getSession(false);


This change works fine with the current implementation of XSP.  The reason
the getSession call is there in the first place was so that XSP authors had
access to the "session" variable name from within <xsp:logic> tags.  They
still do but this way if the session hasn't been created by the author then
the session variable will be null.
Ricardo mistakenly(?) created an implicit session for every XSP page.   When
building real-world sites this is more often NOT the way you want to create
a session. Usually a session is created by calling getSession(true) at a
strategic point in the web application.  This change still allows access to
the "session" variable name though within the xsp page.


thanks,
Mike

Re: XSP session diffs

[Mike Engelhart <me...@earthtrip.com>]

Ted wrote:

> Thanks for the point of view, Mike. We have a slew of groupware
> applications developed using sessions, and all pages are set to (true)
> except for the logout page which is set to (false) then calls
> inactivate(). All of these applications are accessible by HTML, WML, and
> Voice, so we are very conscious of bookmarking (except for VoxML, which
> has a unique set of problems). My technique is to detect the presence of
> an authenticator type object in the session. When present, page is
> served. When absent, you are made to authenticate or do something to
> gain access to the page. We set our sessions to expire in about 10
> hours, so it is unlikely that a 5-step process started 9 days ago will
> still be there 9 days later.
> 
> Thanks again. This is useful perspective in how other developers are
> using sessions.
> 
> Ted
> 
> Dr. Teddy Achacoso
> GroupServe, Inc.
Not a problem. I don't speak for everyone's use but since this is hard coded
and their is no "<xsp:session value="true"> tag or something similar, so I
thought session creation should be at the developer's discretion. On the
other hand your idea of having an authenticator would work as well.  Just
more work.
For my site I am using 15 minute session timeouts because the data being
accessed is in real-time and as a way to ensure that high traffic volume
won't eat up more resources than necessary, I don't create a session until I
absolutely have to so I don't incur the overhead of session objects for
every user that casually accesses the site.  In other words unless the user
is doing something that needs to have session state I don't create a session
but at the same time I need dynamic  content to allow users that have their
accept-language set to Italian or Spanish to receive their pages in their
preferred language.

Mike

Re: XSP session diffs

[Ted <te...@gs2admin1.e-meet.com>]

Mike Engelhart wrote:
> 
> I don't know if you've ever used sessions or not but having them created
> without the hand of the developer doesn't work if someone bookmarks your
> page in the middle of some 5 step process and comes back to your site 9 days
> later and your XSP creates a new session in the middle of the process which
> has nothing in it.  This isn't generally what you want to happen.

Thanks for the point of view, Mike. We have a slew of groupware
applications developed using sessions, and all pages are set to (true)
except for the logout page which is set to (false) then calls
inactivate(). All of these applications are accessible by HTML, WML, and
Voice, so we are very conscious of bookmarking (except for VoxML, which
has a unique set of problems). My technique is to detect the presence of
an authenticator type object in the session. When present, page is
served. When absent, you are made to authenticate or do something to
gain access to the page. We set our sessions to expire in about 10
hours, so it is unlikely that a 5-step process started 9 days ago will
still be there 9 days later.

Thanks again. This is useful perspective in how other developers are
using sessions.

Ted

Dr. Teddy Achacoso
GroupServe, Inc.

Re: XSP session diffs

[Mike Engelhart <me...@earthtrip.com>]

Ted wrote:

> Mike Engelhart wrote:
>> 
>> Ricardo mistakenly(?) created an implicit session for every XSP page.
> 
> I just want to get this. Doesn't request.getSession(false) mean that if
> there is an existing session use it, but if there is no existing
> session, DO NOT CREATE one? And (true) means that if there is an
> existing session use it, but if there is no existing session, DO CREATE
> one?
> 
> So your request is to set the default session to (true)?
> 
> Dr. Teddy Achacoso
> GroupServe, Inc.
Yes that's what it means but as I said in my post:

The current code forces a session to be created for every XSP page whether
you want it or not - which sucks.
The only reason that the Ricardo put it there was so that the XSP author was
able to to access the XSP implicit variable named "session" which points to
an HttpSession object which by definition can be null.  This change I
recommended doesn't change that.  So for example, the XSP author can say:
<xsp:logic>
    session.setAttribute("FOO");
    String myFoo = (String) session.getAttribute("FOO");
</xsp:logic>

without having to make this call.  They need to check if the session is null
and possibly create a new one or send the user to an error page but they
have to do that anyway.

Actually, I think the whole thing should be removed because the developer
needs to be in control of session creation, not the XSP page.
I don't know if you've ever used sessions or not but having them created
without the hand of the developer doesn't work if someone bookmarks your
page in the middle of some 5 step process and comes back to your site 9 days
later and your XSP creates a new session in the middle of the process which
has nothing in it.  This isn't generally what you want to happen.  Of course
you can check if the returned results are null but then you don't know "why"
the session doesn't have what you expect in it.

Mike

Re: XSP session diffs

[Mike Engelhart <me...@earthtrip.com>]

Ted wrote:

> So your request is to set the default session to (true)?
no the diff I sent says to set it to false so that a session is not created
but the variable "session" is created to satisfy the XSP access to the
"session" variable 

Re: XSP session diffs

[Ted <te...@gs2admin1.e-meet.com>]

Mike Engelhart wrote:
> 
> Ricardo mistakenly(?) created an implicit session for every XSP page.

I just want to get this. Doesn't request.getSession(false) mean that if
there is an existing session use it, but if there is no existing
session, DO NOT CREATE one? And (true) means that if there is an
existing session use it, but if there is no existing session, DO CREATE
one?

So your request is to set the default session to (true)?

Dr. Teddy Achacoso
GroupServe, Inc.