>i could imagine to provide a decorator for the ASOManager
A decorator would be better than my solution, but the same result: I simply use
a singleton service to sign out users, and attach a dependancy to the
ApplicationStateManager, the following method is the relevant portion of the
code that you could use in your decorator:
/**
* explicitly destroy all tapestry ASO's on
* logout as a safeguard, only leaving {...@link UserSecurityManager}
in tact
*/
@SuppressWarnings("unchecked")
private void destroySession() {
Enumeration sessionAttributes =
getSession().getAttributeNames();
try {
while (sessionAttributes.hasMoreElements()) {
Class<?> c = null;
String element = (String)
sessionAttributes.nextElement();
if (element.startsWith("aso:")) {
element =
StringUtils.stripStart(element, "aso:");
c = Class.forName(element);
if
(!element.equals(UserSecurityManager.class.getName()))
asm_.set(c, null);
}
}
} catch (ClassNotFoundException e) {
Logger.getLogger(getClass()).error(
"An ASO Class was not resolved when
trying to remove it from state: "
+
e.getLocalizedMessage());
}
}
Just two quick notes:
1. Class.forName("The String canonical class name arg") is my preferred way to
get at the class and avoid any potential classloader issues
2. The line: if (!element.equals(UserSecurityManager.class.getName())) is left
alone as I have a requirement not to touch this class, I have simply left it in
in case you have a
similar issue.
regards,
Peter
----- Original Message -----
From: "Kristian Marinkovic" <kristian.marinko...@porsche.co.at>
To: "Tapestry users" <users@tapestry.apache.org>
Sent: Thursday, 4 June, 2009 10:38:58 GMT +02:00 Athens, Beirut, Bucharest,
Istanbul
Subject: Re: Tapestry 5.0.18 -> 5.1.0.5 Upgrade: Session IllegalStateException
hi peter,
can you share your code. i really don't see a quick fix :)
i could imagine to provide a decorator for the ASOManager
or for the SessionApplicationStatePersistenceStrategy
and store all the objects/fields in an custom wrapper object that
in turn is saved in the HTTPSession. which i then could control
and clear whenever i need it.
g,
kris
Peter Stavrinides <p.stavrini...@albourne.com>
04.06.2009 08:40
Bitte antworten an
"Tapestry users" <users@tapestry.apache.org>
An
Tapestry users <users@tapestry.apache.org>
Kopie
Thema
Re: Tapestry 5.0.18 -> 5.1.0.5 Upgrade: Session IllegalStateException
Hi Kristian,
I experienced similar problems between Tapestry versions (5.0.18 and 5.1)
with exactly the same use case, I never took the time to dig more deeply
though as I simply had to find a quick fix, which was to destroy / remove
all ASO's explicitly... not elegant but efficient, and have had no
problems since. I will glad to share the code if you can't find a
workaround.
Cheers,
Peter
----- Original Message -----
From: "Kristian Marinkovic" <kristian.marinko...@porsche.co.at>
To: "Tapestry users" <users@tapestry.apache.org>
Sent: Thursday, 4 June, 2009 08:57:39 GMT +02:00 Athens, Beirut,
Bucharest, Istanbul
Subject: Re: Tapestry 5.0.18 -> 5.1.0.5 Upgrade: Session
IllegalStateException
i already use the Tapestry Request service. But the RequestImpl
wont create a new HttpSession even i tell it ;)
i think it is a bug. maybe someone can take a look at it to verify it.
the code and the problem:
if the session has been set once it will never be cleared, thus
ignoring the create parameter. and with create=true i will always
get the old invalidated session.
RequestImpl:
public Session getSession(boolean create)
{
if (session == null)
{
HttpSession hsession = request.getSession(create);
if (hsession != null)
{
session = new SessionImpl(hsession, analyzer);
}
}
if (!create && session != null && session.isInvalidated()) return null;
return session;
}
g,kris
Joachim Van der Auwera <joac...@progs.be>
03.06.2009 15:34
Bitte antworten an
"Tapestry users" <users@tapestry.apache.org>
An
Tapestry users <users@tapestry.apache.org>
Kopie
Thema
Re: Tapestry 5.0.18 -> 5.1.0.5 Upgrade: Session IllegalStateException
You should invalidate the session from the (injected) Request object
(not the HTTPServletRequest). This does the necessary bookkeeping.
Kind regards,
Joachim
Kristian Marinkovic wrote:
> hi,
>
> using 5.0.18 it was able to invalidate a HttpSession (via the Request)
> and then to create a new one to store a new object (subject).
>
> in 5.1.0.5 this changed because the Request will always cache the old
> Tapestry Session object and not attempt to create a new Http Session
> as long as the reference is not null although it is invalidated.
>
> Are there any workarounds? Why i'm doing this: if you're logged in
> as XXX you can re-login as YYY if you want and have a new https
> session.
>
> g,
> kris
>
> used to work
> public void setSubject(Subject subject)
> {
> Session session = request.getSession(false);
>
> // create a new session
> if (session != null && !session.isInvalidated())
> {
> session.invalidate();
> }
> request.getSession(true);
>
> asoManager.set(Subject.class, subject);
> }
>
--
Joachim Van der Auwera
PROGS bvba, progs.be
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
