RE: Dynamic service binding based on symbol source
I managed to implement exactly what I wanted with a single additional bind method overload on ServiceBinderImpl. As usual with Tapestry a fair bit of head scratching but very little resulting work! Have submitted with patch as an enhancement request. If anyone is interested in the detail (or wants to vote for it), you can find it here... https://issues.apache.org/jira/browse/TAP5-780 Regards, Alfie. -Original Message- From: Kristian Marinkovic [mailto:kristian.marinko...@porsche.co.at] Sent: 15 July 2009 14:20 To: Tapestry users Subject: Re: Dynamic service binding based on symbol source hi Alfie, i think i understand your problem in such situations i define a service with a dummy implementation. now another module can override the service with a correct implementation. its also useful to break up cyclic dependencies. lets say if have a security module that provides a SubjectService. because the user data is managed by another module that itself depends on the security module i cannot have a SubjectService implementation within the security module that loads the user data (using the user module services). Instead i have a dummy implementation that throws an exception. only if the user module is deployed it will override this dummy implementation with a proper one. (see ServiceOverride for more details) in other circumstances i have a chain with a defined interface any other module can contribute to. now when i build the services (builder method) i delegate it to the chain and it will return the appropriate implementation. so a chain element can decide to return a specific implementation if it needs to and stop the chain. i hope this helps g, kris - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Dynamic service binding based on symbol source
hi Alfie, i think i understand your problem in such situations i define a service with a dummy implementation. now another module can override the service with a correct implementation. its also useful to break up cyclic dependencies. lets say if have a security module that provides a SubjectService. because the user data is managed by another module that itself depends on the security module i cannot have a SubjectService implementation within the security module that loads the user data (using the user module services). Instead i have a dummy implementation that throws an exception. only if the user module is deployed it will override this dummy implementation with a proper one. (see ServiceOverride for more details) in other circumstances i have a chain with a defined interface any other module can contribute to. now when i build the services (builder method) i delegate it to the chain and it will return the appropriate implementation. so a chain element can decide to return a specific implementation if it needs to and stop the chain. i hope this helps g, kris "Thiago H. de Paula Figueiredo" 15.07.2009 14:18 Bitte antworten an "Tapestry users" An "Tapestry users" Kopie Thema Re: Dynamic service binding based on symbol source Why wouldn't a buildXXX() method injecting the symbol as a parameter and some ifs or switch statements work in your scenario? -- Thiago H. de Paula Figueiredo Independent Java consultant, developer, and instructor http://www.arsmachina.com.br/thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Dynamic service binding based on symbol source
Why wouldn't a buildXXX() method injecting the symbol as a parameter and some ifs or switch statements work in your scenario? -- Thiago H. de Paula Figueiredo Independent Java consultant, developer, and instructor http://www.arsmachina.com.br/thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
RE: Dynamic service binding based on symbol source
Hi Kris, thanks for the reply. This would work but it's a bit messy and does give me the proper separation of concern I'm after. One of the things I might want is to have a stub implementation in test classes, or pulled in from another module which only gets included under a certain maven profile, which doesn't get packaged into my final app. Or taking it further, the implementation class might even be outside the app in which case I don't want my module to know anything about the implementation class at all. The following code works perfectly for me, I just want to have it under the control of SymbolSource rather than system properties!! String myServiceBuilderClass = System.getProperty( "my.servicebuilder", "com.ioko.t5demo.ws.MyServiceStubBuilder"); Class clazz = (Class) Class .forName(myServiceBuilderClass); binder.bind(MyServiceBuilder.class, clazz); Regards, Alfie. -Original Message- From: Kristian Marinkovic [mailto:kristian.marinko...@porsche.co.at] Sent: 15 July 2009 11:31 To: Tapestry users Subject: RE: Dynamic service binding based on symbol source hi alfie, i don't know if i'm missing something but you could solve it this way: public Service buildService(@Inject @Sysmbol("whatever") Long numeric, @InjectService("VariantA") Service serviceA, @InjectService("VariantB") Service serviceB) { switch(numeric) { case 2: return serviceA; case 42: return serviceB; default: throw new Exception(); } } if you want to use the Service without qualifier you could define another inteface for the variants g, kris "Alfie Kirkpatrick" 15.07.2009 10:42 Bitte antworten an "Tapestry users" An "Massimo Lusetti" , "Tapestry users" Kopie Thema RE: Dynamic service binding based on symbol source Further to my last mail I think it could be possible to have a module method convention like: public static com.acme.service.MyService bindByConfiguration() { } This would look for a symbol "com.acme.service.MyService" based on the return type and use a variant on the ConstructorServiceCreator to instantiate the service. Or perhaps a ServiceBinder.bind(MyService.class, "the.symbol.name.for.impl.class") method would work. It seems a bit tidier. Either should be possible since ServiceBuilderMethodInvoker is able to resolve symbols as parameters via InternalUtils.calculateParametersForMethod. It's just that the current code/encapsulation level isn't really geared for what I want to do -- I need a bit of both ConstructorServiceCreator and ServiceBuilderMethodInvoker. But I'll keep digging. Regards, Alfie. -----Original Message- From: Massimo Lusetti [mailto:mluse...@gmail.com] Sent: 14 July 2009 13:47 To: Tapestry users Subject: Re: Dynamic service binding based on symbol source On Tue, Jul 14, 2009 at 2:43 PM, Alfie Kirkpatrick wrote: > I would like to instantiate a different service implementation depending > on property file configuration, eg. a stub for testing and a real > service for deployments. I'd like to put the FQN in my property file > which is then wrapped in a SymbolProvider. I highly suggest you to build a chain of command or a strategy pattern depending on service type and let the IoC do the work for you. -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
RE: Dynamic service binding based on symbol source
hi alfie, i don't know if i'm missing something but you could solve it this way: public Service buildService(@Inject @Sysmbol("whatever") Long numeric, @InjectService("VariantA") Service serviceA, @InjectService("VariantB") Service serviceB) { switch(numeric) { case 2: return serviceA; case 42: return serviceB; default: throw new Exception(); } } if you want to use the Service without qualifier you could define another inteface for the variants g, kris "Alfie Kirkpatrick" 15.07.2009 10:42 Bitte antworten an "Tapestry users" An "Massimo Lusetti" , "Tapestry users" Kopie Thema RE: Dynamic service binding based on symbol source Further to my last mail I think it could be possible to have a module method convention like: public static com.acme.service.MyService bindByConfiguration() { } This would look for a symbol "com.acme.service.MyService" based on the return type and use a variant on the ConstructorServiceCreator to instantiate the service. Or perhaps a ServiceBinder.bind(MyService.class, "the.symbol.name.for.impl.class") method would work. It seems a bit tidier. Either should be possible since ServiceBuilderMethodInvoker is able to resolve symbols as parameters via InternalUtils.calculateParametersForMethod. It's just that the current code/encapsulation level isn't really geared for what I want to do -- I need a bit of both ConstructorServiceCreator and ServiceBuilderMethodInvoker. But I'll keep digging. Regards, Alfie. -Original Message- From: Massimo Lusetti [mailto:mluse...@gmail.com] Sent: 14 July 2009 13:47 To: Tapestry users Subject: Re: Dynamic service binding based on symbol source On Tue, Jul 14, 2009 at 2:43 PM, Alfie Kirkpatrick wrote: > I would like to instantiate a different service implementation depending > on property file configuration, eg. a stub for testing and a real > service for deployments. I'd like to put the FQN in my property file > which is then wrapped in a SymbolProvider. I highly suggest you to build a chain of command or a strategy pattern depending on service type and let the IoC do the work for you. -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
RE: Dynamic service binding based on symbol source
Further to my last mail I think it could be possible to have a module method convention like: public static com.acme.service.MyService bindByConfiguration() { } This would look for a symbol "com.acme.service.MyService" based on the return type and use a variant on the ConstructorServiceCreator to instantiate the service. Or perhaps a ServiceBinder.bind(MyService.class, "the.symbol.name.for.impl.class") method would work. It seems a bit tidier. Either should be possible since ServiceBuilderMethodInvoker is able to resolve symbols as parameters via InternalUtils.calculateParametersForMethod. It's just that the current code/encapsulation level isn't really geared for what I want to do -- I need a bit of both ConstructorServiceCreator and ServiceBuilderMethodInvoker. But I'll keep digging. Regards, Alfie. -Original Message- From: Massimo Lusetti [mailto:mluse...@gmail.com] Sent: 14 July 2009 13:47 To: Tapestry users Subject: Re: Dynamic service binding based on symbol source On Tue, Jul 14, 2009 at 2:43 PM, Alfie Kirkpatrick wrote: > I would like to instantiate a different service implementation depending > on property file configuration, eg. a stub for testing and a real > service for deployments. I'd like to put the FQN in my property file > which is then wrapped in a SymbolProvider. I highly suggest you to build a chain of command or a strategy pattern depending on service type and let the IoC do the work for you. -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
RE: Dynamic service binding based on symbol source
Hi Massimo, thanks for the reply. Unfortunately neither of these patterns works for me because they rely on the chained service(s) being instantiated in the normal way, ie. via bind or build. Looking at DefaultModuleDefImpl there doesn't seem any reason in principle why it's too early in the bind() method of a module to late bind an implementation class based on a symbol. Or alternatively have a special form of buildX which supports this kind of thing, ie. allowing the builder to return a service definition rather than a concrete class via new. Am still looking through the sources to see what might be possible/simple. Unless I'm missing something I don't think what I'm after can be done without a change to Tapestry. Anyone disagree? Do people think this is this a reasonable feature request? Regards, Alfie. -Original Message- From: Massimo Lusetti [mailto:mluse...@gmail.com] Sent: 14 July 2009 13:47 To: Tapestry users Subject: Re: Dynamic service binding based on symbol source On Tue, Jul 14, 2009 at 2:43 PM, Alfie Kirkpatrick wrote: > I would like to instantiate a different service implementation depending > on property file configuration, eg. a stub for testing and a real > service for deployments. I'd like to put the FQN in my property file > which is then wrapped in a SymbolProvider. I highly suggest you to build a chain of command or a strategy pattern depending on service type and let the IoC do the work for you. -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Dynamic service binding based on symbol source
On Tue, Jul 14, 2009 at 2:43 PM, Alfie Kirkpatrick wrote: > I would like to instantiate a different service implementation depending > on property file configuration, eg. a stub for testing and a real > service for deployments. I'd like to put the FQN in my property file > which is then wrapped in a SymbolProvider. I highly suggest you to build a chain of command or a strategy pattern depending on service type and let the IoC do the work for you. -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org