Thanks again. Putting the registry in the ServletContext looks right, but I'm not sure it's enough for my use case. I need access to the Hibernate session from deep in the bowels of my legacy ORM framework, and the ServletContext is not easily accessible from there. I may just be stuck with a static.
Howard Lewis Ship wrote: > > I went looking for the best way to do this, and didn't find anything I > like. Certainly, avoiding static fields is a step in the right > direction. > > I'm going to quickly implement > https://issues.apache.org/jira/browse/TAPESTRY-2540 > > Once you have the Registry, you have the keys to the castle! > > On Fri, Jul 25, 2008 at 10:21 AM, Franz Amador <[EMAIL PROTECTED]> wrote: >> >> Thanks, Howard. Splitting my per-thread service into interface and >> implementation did the trick. >> >> My intent, by the way, is to have all threads share the singleton >> eager-load >> service but for some of that service's behavior to be per-thread, >> provided >> by the per-thread service. This is an odd arrangement, I admit. Here's >> the >> problem I'm trying to solve: >> >> I have a legacy app that uses JSPs and a home-brew ORM framework. I'm >> trying to migrate it to use T5 and Hibernate. Until it's completely >> converted, both the old and the new parts must coexist. For this to >> work, >> the legacy ORM must use the same transactions as Hibernate. I'm doing >> this >> by having the legacy ORM get its connections from Hibernate. >> >> I'm configuring Hibernate using Tapestry IoC, so how does my legacy ORM >> get >> access to it? The answer is my eager-load service, whose real name is >> T5IocAccess. T5IocAccess has a static "instance" variable that its >> constructor sets to point to itself; this allows the legacy part of the >> app >> to obtain the T5IocAccess instance (via a static "get()" method). >> T5IocAccess must be eager-load to ensure that this static variable gets >> populated immediately. >> >> The per-thread service is a Hibernate session manager, which the legacy >> ORM >> obtains via T5IocAccess. >> >> This works, but it raises a broader question. What is the best way for >> legacy code to gain access to services managed by Tapestry IoC? I >> created >> my T5IocAccess service, with its static instance variable, because I saw >> no >> other way. >> >> >> Howard Lewis Ship wrote: >>> >>> This looks like an issue ... I think EagerLoad is not compatible with >>> non-singleton scopes. >>> >>> What does it mean to eager load a service that is, in fact, used in >>> multiple threads? >>> >>> Ah, here's the issue; when you bind a class, not an interface, as a >>> service, it automatically uses singleton scope. Only proxiable >>> services can have non-singleton scope, and that means an interface and >>> an implementation. Tapestry should detect this and throw an >>> exception. >>> >>> On Thu, Jul 24, 2008 at 11:01 AM, Franz Amador <[EMAIL PROTECTED]> >>> wrote: >>>> >>>> I have an EagerLoad service that uses a PerThread service. I expected >>>> the >>>> EagerLoad service to hold a reference to a proxy to the PerThread >>>> service >>>> so >>>> that the actual instance of the PerThread service that is used depends >>>> upon >>>> the thread calling the EagerLoad service. Instead, the EagerLoad >>>> service >>>> is >>>> getting a reference to an actual instance of the PerThread service, not >>>> to a >>>> proxy, so the same instance of the PerThread service is getting used by >>>> all >>>> threads that call the EagerLoad service. This surely can't be right. >>>> Here's a very simplified example: >>>> >>>> public class AppModule { >>>> public static void bind(ServiceBinder binder) { >>>> binder.bind(EagerLoadService.class); >>>> binder.bind(PerThreadService.class); >>>> } >>>> } >>>> >>>> @EagerLoad >>>> public class EagerLoadService { >>>> public EagerLoadService(PerThreadService perThreadService) { >>>> // prints "class PerThreadService", not a proxy class! >>>> System.out.println(perThreadService.getClass()); >>>> } >>>> } >>>> >>>> @Scope(PERTHREAD_SCOPE) >>>> public class PerThreadService { >>>> } >>>> >>>> Is this a bug? Am I confused about how this should work? All help >>>> appreciated. >>>> >>>> -- >>>> View this message in context: >>>> http://www.nabble.com/EagerLoad-service-doesn%27t-use-PerThread-service-correctly-tp18637337p18637337.html >>>> Sent from the Tapestry - User mailing list archive at Nabble.com. >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>> >>> >>> >>> -- >>> Howard M. Lewis Ship >>> >>> Creator Apache Tapestry and Apache HiveMind >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/EagerLoad-service-doesn%27t-use-PerThread-service-correctly-tp18637337p18656018.html >> Sent from the Tapestry - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > > -- > Howard M. Lewis Ship > > Creator Apache Tapestry and Apache HiveMind > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/EagerLoad-service-doesn%27t-use-PerThread-service-correctly-tp18637337p18721842.html Sent from the Tapestry - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
