I believe you can detect session created without using an exception as the signal. I think there is an event you can trap, but I'm talking blindly on this from memory, which may or may not be correct. I get nervous when people use exceptions for things that are expected and therefore not "Exceptional". I like to let my exceptions be exceptional. For example,
the PageRedirectException gets under my skin for the same reason.

john mcteague wrote:

Would registering a  javax.servlet.http.HttpSessionListener and
throwing an exception in sessionCreated(..) not be the best way of
tracking sessions being created?

On 7/20/05, Norbert Sándor <[EMAIL PROTECTED]> wrote:
Have you tried some tomcat user list?
Maybe they can help you more because this seems to be a lower level, servlet
(or container?) specific question.

Br,
Norbi

----- Original Message -----
From: "Fernando Padilla" <[EMAIL PROTECTED]>
To: "Tapestry users" <[email protected]>
Sent: Wednesday, July 20, 2005 8:23 PM
Subject: Re: forcing No Server Session


Currently I do have a listener to at least warn me when a session is
destroyed and created, but it only tells me after the fact, and I don't
think there is a way I can cancel the session creation, and it doesn't
tell me who/when/why created the session.

That's why altering the HttpServletRequest is the right way to get
closer to the point of action, and I can print out the stack trace at
that point to help me figure out who/why created the session.

but please, let's keep discussing :)




Norbert Sándor wrote:
Maybe throw an exception in HttpSessionListener.sessionCreated() - of
course you should configure your servlet container for this.

Br,
Norbi

----- Original Message ----- From: "Patrick Casey"
<[EMAIL PROTECTED]>
To: "'Tapestry users'" <[email protected]>
Sent: Wednesday, July 20, 2005 6:32 PM
Subject: RE: forcing No Server Session


How about you just set up a visit object that throws an error in its
constructor?

--- Pat

-----Original Message-----
From: Fernando Padilla [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 20, 2005 9:25 AM
To: Tapestry users
Subject: forcing No Server Session

We are developing a high load application.  One of our requirements is
to have no server side sessions.

As the documentation says, Tapestry tries it's best to not start a
HttpSession until it has to.  But I need a tighter guarantee, that it
does not start a HttpSession ever.  For example I would prefer Tapestry
to throw an error if any components declare a property persistent, or
ever tries to create a session, so that we can replace that component.


Any ideas on how I can accomplish this?

Does there happen to be a service whose job is to create sessions, that
I could replace with HiveMind?



I just figured out one way; as I was writing this.

Use a Webapp Filter to replace the HttpServletRequest object with one
that reimplements the getSession methods to throw an exception.


This will force the guarantee of no serverside sessions.  But the
question still remains, how will Tapestry react.  Could Tapestry work
under such a strict environment, etc.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to