Plenty of reasons to have different service implementations per
environment.
A big one for me is authentication. Same app may have different
authentication strategies depending on environment. LDAP here, db-
backed there, simple (or none) for development, etc.
There are a number of ways that I could see approaching this.
One way would be to contribute your own ObjectProvider, which then
resolves the services according to whatever configuration you want.
Another way would utilize the AliasOverrides service.
The easiest way to explain this is probably to step through an
example, so, for the authentication example:
Note that although all of the following examples will use service ids,
you could easily create your own service markers (@Default, @LDAP,
etc.) if you wanted to do this in a "refactor-safe" manner.
Authenticator will refer to the name of an interface defining
appropriate methods for authentication.
AppModule.java:
public static void bind(ServiceBinder binder) {
binder
.bind(Authenticator.class,DefaultAuthenticator.class).withId("default");
}
public static void
contributeAlias(Configuration<AliasContribution> conf,
@InjectService("default") Authenticator auth) {
conf.add(Authenticator.class,auth);
}
Now suppose you have a client that uses ldap authentication. You
create a new library. It can be very small, with two classes: your
ldap authentication implementation, and your ldap module.
LDAPModule.java:
public static void bind(ServiceBinder binder) {
binder.bind(Authenticator.class,LDAPAuthenticator.class).withId("ldap");
}
public static void
contributeAliasOverrides(Configuration<AliasContribution> conf,
@InjectService("ldap") Authenticator auth) {
conf.add(Authentication.class,auth);
}
Now you've got that setup to be packaged into a jar, you put the
tapestry-module line into your manifest (running out of time here or
I'd post a link), so the ioc can auto-load your module.
Finally, you setup your maven profile so that your development build
doesn't depend on the LDAP module, but your build for the client that
uses LDAPAuthentication /does/ depend on the LDAP module.
Now the correct service will be selected based on the presence or
absence of the appropriate modules.
Robert
On Mar 21, 2008, at 3/216:29 PM , Ben Tomasini wrote:
Glenn,
What requires you to have separate implementations for each
environment? Is it configuration data that you could move into a
properties file that lives the in the classpath of your container?
Ben
On Fri, Mar 21, 2008 at 4:02 PM, Glenn Sudduth <[EMAIL PROTECTED]>
wrote:
(This seems like a pretty basic question, but I haven't been able to
ferret out the answer so here goes ...)
What is a good way to have Tapestry 5 IoC determine which
implementation
of a particular service to load at runtime? With Spring I accomplish
this by creating multiple versions of the bean definition/config
file.
Then have the (Maven) build process select the appropriate config
based
on the build profile I specify (dev, test, prod) and copy it in
place so
that Spring reads it when it starts up.
Thanks,
--
Glenn
---------------------------------------------------------------------
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]
