On 08/03/2011 02:49 PM, ryannelsonaz wrote:
> Jared,
>
> Hmm, we're close but not quite there. Here are the relevant lines from my
> module, as you specified:
>
> @Override
> protected void configureShiroWeb() {
> try {
> bindRealm().toConstructor( IniRealm.class.getConstructor(
> Ini.class ) );
> } catch ( NoSuchMethodException e ) {
> throw new RuntimeException( "Code Problem.", e );
> }
> bind( CredentialsMatcher.class ).to( HashedCredentialsMatcher.class );
add:
bind(HashedCredentialsMatcher.class);
> bindConstant().annotatedWith( Names.named( "shiro.hashAlgorithmName" )
> ).to(Md5Hash.ALGORITHM_NAME );
> }
>
> @Provides
> @Singleton
> Ini loadShiroIni() {
> return Ini.fromResourcePath( "classpath:shiro.ini" );
> }
>
> This results in an AuthenticationException. Tracing the execution, I can
> see the HashedCredentialsMatcher gets set as expected, but the algorithim
> never does. The property HashedCredentialsMatcher.hashAlgorithm is null.
>
> On a related side-note: I'm curious how you implemented the DI without using
> the @Inject annotation.
Well, I'm using a Guice TypeListener. When it encounters an class in
org.apache.shiro package, but NOT in org.apache.shiro.guice, it attempts
to inject it like a standard JavaBean (using setters, and introspecting
types).
It turns out that Guice TypeListeners are only run against types that
are explicitly bound - not just-in-time bindings. So, if you want
anything injected, you have to explicitly bind it.
I'll add that to the docs.
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/Wiring-a-CredentialsMatcher-into-a-Realm-using-Guice-tp6645572p6649980.html
> Sent from the Shiro User mailing list archive at Nabble.com.
