Hi, am trying to do something similar to that outlined in this thread...
http://markmail.org/thread/55zw3cg6n7zbfehn, but there was no firm
conclusion to it I can see.
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.
My initial attempt looked like this:
public static void bind(
ServiceBinder binder,
@Inject
@Symbol("myservice.fqn") Class<MyService> myserviceClass) {
binder.bind(ExcelFileImporter.class);
binder.bind(AvailableProgrammeProvider.class);
binder.bind(MyService.class,
myserviceClass);
}
(I was kind of hoping that T5 would coerce from property file string to
class but doesn't matter if it won't)
Tapestry rejects this because bind() is not like contribute/build
methods and doesn't allow extra params.
I don't think a builder method is appropriate in my case -- while it
could use Class.forName from a property, I would not get any dependency
injection from the framework, and my stub vs. real service are likely to
have differing dependencies.
Any ideas? Would the pattern above be viable/useful as a feature
request? Am pretty sure I could make it work using system properties
rather than @Inject @Symbol, so feels like a reasonable thing to do.
For info I previously played around with per-build wiring using
additional modules and service overrides. While this works it's not very
elegant at all.
Thanks, Alfie.
