I just realized that the current session is also bound to the thread
context. Would it make sense to attach the Session to the background
thread using the same way we do it for the Application?
E.g.
Session oldSession = Session.exists() ? Session.get() : null;
Session.set(_session);
try
{
... invoke...
}
finally
{
if (oldSession == null) Session.unset();
else Session.set(oldSession);
}
Without doing this, the exception IllegalSateException: "You can only
locate or create sessions in the context of a request cycle" may be thrown.
Seb
On 01.10.2010 00:42, Rodolfo Hansen wrote:
On Thu, 2010-09-30 at 23:48 +0200, Sebastian wrote:
There was an issue in your patch where the application could be left
in the ThreadContext, which was fixed,
Hi Rodolfo,
I think you are referring to
try {
Application.set(_application);
methods[m].invoke(o, parameters);
} finally {
Application.set(originalApplication);
if (originalApplication != null) Application.set(originalApplication);
}
The problem is if this code is executed in a separate thread the
originalApplication will be null. If you just omit the null check in the
finally clause the setter will throw an IllegalArgumentException. So to
remove the app from the ThreadContext we would have to call
Application.unset() instead:
if (originalApplication == null) Application.unset();
else Application.set(originalApplication);
you are right, although i checked the source for set and didn't see the
throw...
amended in the 1.4 branches
Regards,
Seb
On 30.09.2010 23:08, Rodolfo Hansen wrote:
Hi Sebastian, your patch is in:
trunk (1.5)
1.4 branch (future 1.4.13 release)
and 1.4.12
There was an issue in your patch where the application could be left in
the ThreadContext, which was fixed,
as well as a simplification in the trigger function.
On Wed, 2010-09-29 at 21:39 +0200, Sebastian wrote:
Hi,
there is a problem in the Push TimerChannelService implementation:
Callbacks do not work reliable when they are invoked from non-Web
threads. The "There is no application attached to current thread"
WicketRuntimeException will occur in such a case. The attached patch
fixes this issue.
Regards,
Seb
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
