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<MyServiceBuilder> clazz =
(Class<MyServiceBuilder>) 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" <alfie.kirkpatr...@ioko.com>
15.07.2009 10:42
Bitte antworten an
"Tapestry users" <users@tapestry.apache.org>
An
"Massimo Lusetti" <mluse...@gmail.com>, "Tapestry users"
<users@tapestry.apache.org>
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<alfie.kirkpatr...@ioko.com> 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
