well, the kind of things you describe I lump together as "services", which I put into the HiveMind category. HiveMind's threaded service model is perfect for what you are doing ... all the fun of ThreadLocal with none of the code (plus proper cleanup).
In the 4.0 code base, I have a threaded service model service, RequestGlobals, that stores the incoming WebRequest (a wrapper around HttpServletRequest or PortletRequest). I use the ServicePropertyFactory to create a WebRequest service thats, in effect, the projection of the RequestGlobals.request property. I can then inject WebRequest into whatever need to know about the current thread's request. Invoking a method upon the injected proxy - Gets the RequestGlobals proxy - Invokes getRequest() on it, and is returned the current thread's request - Delegates the method to the request obtained from RequestGlobals This is fun stuff ... globals that are thread specfic. Seems like a contradiction, but it all just works. There are issues with using ThreadLocals in a web environment. Basically, the values in the thread locals, if not cleared out, can create devestating memory leaks with huge memory consumption and problematic hot re-deployments. HiveMind includes a mechanism that ensures that all the thread locals it manages are properly cleared back to null at the end of each request. On 6/15/05, Joel Trunick <[EMAIL PROTECTED]> wrote: > > I use it for layering my application, kind of like with EJB's, you can > do things like check if the user is logged in, whether they have the > correct role, or return a subset of the data based on who is logged in. > > It's nice to have it accessible be the lower layers, without having to > pass it into a bunch of method calls. It makes the code much cleaner, > IMO. It also makes for a "thinner" visit, I have a map on my visit, and > objects that need the data (the key is typically the Java class using > the data) can get it regardless of the call stack parameters, so the > Visit doesn't get jumbled with everyone's data exposed. > > I've been wiring Tapestry to put Visit in ThreadLocal, the only > shortcoming I've had is that I've been creating the visit up front > whether I need it or not. (I didn't see how to put the Engine in > threadlocal and create the visit on demand.) > > Joel > > PS. Have you considered allowing non-public scope Page properties? > > -----Original Message----- > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 15, 2005 1:56 PM > To: Joel Trunick > Subject: Re: Tapestry 4 ASO question > > No, though the scoping strategy (*"session" vs. "application") is > extensible. Outside of a frames based application, when would this be > an issue? If you have some data that just part of the current request, > then it should be an ordinary transient page property. > > On 6/15/05, Joel Trunick <[EMAIL PROTECTED]> wrote: > > > > Cool, so is there a convenient mechanism to bind ASO's (Visit) to the > > current thread? > > > > Joel > > > > -----Original Message----- > > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, June 15, 2005 6:26 AM > > To: Tapestry users > > Subject: Re: Tapestry 4 ASO question > > > > Application State Object. The generalization of "visit" and "global" > in > > 4.0. > > > > On 6/15/05, Erik Hatcher <[EMAIL PROTECTED]> wrote: > > > What is an "ASO"? > > > > > > > > > > > > -- > Howard M. Lewis Ship > Independent J2EE / Open-Source Java Consultant > Creator, Jakarta Tapestry > Creator, Jakarta HiveMind > > Professional Tapestry training, mentoring, support > and project work. http://howardlewisship.com > > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
