Now I don't understand exactly what that means.
In my case I have two modules. Module one ships with an interface and a
default implementation that is preconfigured. As a user of module one,
in my module two, I contributeAlias(..) to override the preconfigured
default implementation. The application as whole will now use the
service configured and 'implemented' in module two.
What would be the usecase of @Local? When I have only one module and
want to override via an AliasContribution ..? Why would I d that?
Howard Lewis Ship schrieb:
Looks good to me too.
I'm working on adding @Local which will make it easier to contribute
Alias contributions that are services from within the same module.
But often you can get by, as you did, with just an instance.
On Mon, Aug 11, 2008 at 4:06 AM, Filip S. Adamsen <[EMAIL PROTECTED]> wrote:
Hi,
I wouldn't use Configuration<AliasContribution<PasswordEncoder>>, but rather
Configuration<AliasContribution>. Otherwise you won't be able to configure
multiple alias overrides at once.
Apart from that, everything looks fine.
-Filip
Michael Gerzabek skrev:
Usecase:
tapestry-spring-security offers integration between Tapestry 5 an Spring
Security [1]. It's implemented as a Tapestry IoC/Core module.
This module uses a PasswordEncoder shipped by Spring Security (they ship
also a couple of standard implementations of PasswordEncoder).
For the module to function correctly an implementation class of
PasswordEncoder (the service in charge) is needed. Now, there are two ways
to configure the module:
1.) gracefully: The module declares a standard service for PasswordEncoder
and assumes the main module will define an AliasContribution to override
with whatever specific instance is needed.
2.) tough: The module doesn't declare a standard service for
PasswordEncoder. It rather assumes that the user of the module will do so.
If the user of the module doesn't provide an implementation a
RuntimeException is thrown and the container won't start up.
Obviously there are arguments for both directions. In
tapestry-spring-security we wanted to follow line 1.) This leads us to the
FAQ.
[FAQ] How to configure a service that likely will be overriden by an
AliasContribution?
i. Supplier: The only thing the supplier of a module has to do is to bind
the interface (PasswordEncoder) to the default class
(PlaintextPasswordEncoder) - or provide a build method if he needs to set it
up.
public static void bind(final ServiceBinder binder) {
binder.bind( PasswordEncoder.class,
PlaintextPasswordEncoder.class ).withMarker(
SpringSecurityServices.class);
}
ii. User: Now if you want to use a supplied module and you want to
override a service defined there the only thing you have to do is to
contribute to the Alias service.
public static void contributeAlias(
Configuration<AliasContribution<PasswordEncoder>> configuration ) {
configuration.add( AliasContribution.create(
PasswordEncoder.class,
new ShaPasswordEncoder() ) );
}
--
Crowd,
Is this correct? Do I miss something?
Regards,
Michael
[1] http://www.localhost.nu/java/tapestry5-acegi/
---------------------------------------------------------------------
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]
