Your logic is fine with regard to the ApplicationStateManager. I wanted to mention the difference with the HibernateSessionManager for the sake of anyone else that happens upon this thread.
All the best, lasitha. On 9/23/07, Chris Lewis <[EMAIL PROTECTED]> wrote: > Let me restate - I do NOT need the HibernateSessionManager, but I DO > need an ASO. ASOs are per client/request/thread, so I will have to > figure this part out as my service is a Singleton (and I'm not convinced > it needs to be per thread). So... couldn't I just inject a reference to > the ApplicationStateManager into my Dispatcher, and then use it to grab > ASOs? As long as the ApplicationStateManager accesses the current > thread, this should work. I haven't yet put much thought into this, but > I'm reading up now. Does my logic appear flawed? > > lasitha wrote: > > AFAIK, @Inject only works on pages and components. Services are > > injected into via their constructors, without need of any annotations. > > > > Services are singletons by default, but you can use the @Scope > > annotation to make them per-thread. > > > > If however you want the dispatcher to be a singleton, you've got a > > little more work to do :) > > > > This recent thread about getting an ASO into a singleton service might > > give you some ideas: "T5 - Inject an Application State Object into a > > Service" (Sep 12) [1] > > > > In your case, you need to create something similar to the > > ApplicationStateManager to get a hold of the Session for the current > > thread. Unfortunately, the HibernateSessionManager [2] service won't > > work because its also per-thread. > > > > Take a look at 'Shadow Services' [3] in the ioc. I think you could > > create a service that shadows the HibernateSessionManager.getSession() > > method and have this injected into your dispatcher. Your dispatcher > > and shadow service remain singletons. > > > > I'm afraid i don't have time to test it out, but it seems to work in my > > head :) > > > > Cheers, > > lasitha. > > > > [1] > > http://mail-archives.apache.org/mod_mbox/tapestry-users/200709.mbox/[EMAIL > > PROTECTED] > > > > [2] > > http://tapestry.apache.org/tapestry5/tapestry-hibernate/apidocs/index.html?org/apache/tapestry/hibernate/HibernateSessionManager.html > > > > [3] http://tapestry.apache.org/tapestry5/tapestry-ioc/shadow.html > > > > > > On 9/22/07, Chris Lewis <[EMAIL PROTECTED]> wrote: > > > >> Hi all, > >> > >> I'm implementing an access control service as a Dispatcher, and > >> contributing it to the MasterDispatcher service. This dispatcher runs > >> just before PageRender... and ComponentAction..., so that it can check > >> if the user is allowed to access the page/resource. This seems to be a > >> very "T5" way of doing things and completely removes the task of access > >> control from the pages (ie i don't have to extend a base page that > >> implements control logic). > >> I want this service to use a database and am already using > >> tapestry-hibernate in this project. I figured I could just @Inject the > >> session into my service just like I would a page or component, but that > >> doesn't work. In a way that makes sense; services are singletons if I'm > >> not mistaken (which makes sense), and Sessions exist (and possibly > >> injected?) per-thread. Being that my service will be started in a > >> different thread than any request, I think @Inject is ignored. > >> > >> So my question is, how should I go about getting access to my database > >> from my service? I'd like to use the blinding simplicity of of IoC just > >> giving it to me, but I;m not sure that's an option. Any ideas? > >> > >> thanks, > >> chris > >> > >> --------------------------------------------------------------------- > >> 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] > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
