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 <[email protected]> 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 > <[email protected]>wrote: > >> Sorry, subject should be wrap() method, not runAs(). >> >> On Tue, May 25, 2010 at 9:33 AM, James Carman >> <[email protected]> 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
