I haven't tried it yet but how about using the following?
// Note: req is the HttpServletRequest param from doGet()
if ( (data.getACL() == null) && (req.getSession(false) != null) )
{
data.getSession().removeValue(AccessControlList.SESSION_KEY);
}
Servlet 2.0 API:
public abstract HttpSession getSession(boolean create)
Description:
Returns the current session associated with the user making the request. If
the user has no current valid session, this method creates one if 'create'
is true or returns null if 'create' is false.
It gets rid of the try/catch block if that's what you prefer.
Although, I was just wondering if there could be a multi-thread issue. What
if the session is invalidated inbetween calls to the req.getSession(false)
and the removeValue() statements?
A try/catch block would definately work appropriately. But without a
try/catch block removeValue() might throw the IllegalStateException in some
rare instance.
So perhaps, the try/catch block is a cleaner solution.(?)
-David
-----Original Message-----
From: Daniel Rall [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 23, 2002 9:11 AM
To: Turbine Developers List
Cc: David Vandegrift; Turbine Users List
Subject: Re: Added try/catch to Turbine.java. Problem?
Daniel Rall <[EMAIL PROTECTED]> writes:
> Note that I didn't use the try/catch block you suggested, as checking
> for a valid session is a more correct implementation.
Turned out that the HttpSession::isValid() method was
Catalina-internal, hidden behind its HttpSessionFacade class and not
part of the servlet spec. I've switched to the try/catch suggested by
David (ugh, bad servlet api, bad).
> Question for turbine-dev: does this fix still apply? If so, where?
I've found a few spots in jakarta-turbine-3 where this check is
appropriate and patched them.
*********************************************************************
This e-mail and any attachment is confidential. It may only be read, copied and used
by the intended recipient(s). If you are not the intended recipient(s), you may not
copy, use, distribute, forward, store or disclose this e-mail or any attachment. If
you are not the intended recipient(s) or have otherwise received this e-mail in error,
you should destroy it and any attachment and notify the sender by reply e-mail or send
a message to [EMAIL PROTECTED]
*********************************************************************
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
