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
{
Added.
On Fri, 2010-10-01 at 13:14 +0200, Sebastian wrote:
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 =
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,
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
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);
}
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.
On Wed, Sep 29, 2010 at 2:39 PM, Sebastian nospam...@gmx.net 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
