In our application we use quartz for long running jobs. These threads have access to the application context, which contains the wicket application. In the execute method, we locate the application and use Application.set and Application.unset to set and remove the application. This is, however, not a 'public API' and could easily be replaced by wrapping the main body in a Runnable and calling Application.wrap. I'm in favor of this wrap method. It allows you to set the application on a thread, without having to use non- public API, and without the try/finally hassle.
I do not care how this method is implemented (that's the beauty of a good API, isn't it?). It could store the application in the runnable, or look it up in a map, as long as it works reliably, I'm fine with it :) Emond On Wednesday 26 May 2010 23:47:43 James Carman wrote: > Well, this doesn't start any threads or anything. So, it wouldn't > immediately allow folks to start up threads. All this would do is > create an object that *can* be run in another thread, but have access > to this Application in it. Also, this is just a proposal. I'm just > wanting folks to give feedback about the idea. I think this is the > most flexible way to solve the problem we're seeing folks have. > > On Wed, May 26, 2010 at 4:28 PM, Joe Fawzy <joewic...@gmail.com> wrote: > > Hi > > Please make this configurable(can be disabled) as i am on appengine, they > > does not allow threads > > thanks > > Joe > > > > On Tue, May 25, 2010 at 4:34 PM, James Carman <ja...@carmanconsulting.com>wrote: > >> Sorry, subject should be wrap() method, not runAs(). > >> > >> On Tue, May 25, 2010 at 9:33 AM, James Carman > >> > >> <ja...@carmanconsulting.com> wrote: > >> > I've been thinking about this whole idea of needing to access the > >> > application object in different threads idea. What if the Application > >> > class had a method like this: > >> > > >> > public Runnable wrap(Runnable task) > >> > > >> > Basically, the Application would create a Runnable object that can be > >> > run within the context of itself (by setting/clearing the ThreadLocal > >> > variable). Then, you can use that Runnable anywhere to run a task > >> > with all of the appropriate Wickety goodness set up for you (except > >> > for the request cycle of course because you're not executing within a > >> > request cycle). Now, what the Application stores in the Runnable > >> > doesn't have to be the Application itself. We can set up a static > >> > Map<String,WeakReference<Application>> object on the Application class > >> > and when an Application is constructed, it registers itself (the key > >> > could be a UUID.randomUUID().toString()). Then, we could have a > >> > method like > >> > > >> > public static Application get(String id); > >> > > >> > on the Application class to get back the original Application object. > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
