Property injection in custom membership provider u

So far in reading about possibilities of injection to custom membership providers, I've found two possible ways to do it:

One is the following: http://bugsquash.blogspot.com/2010/11/windsor-managed-membershipproviders.html

Here the author basically suggests to register your custom provider and then have a rather questionable windsor adapter for membership (I don't really like the way in which it instances your provider using a container it gets from HttpApplication, which it ultimately wraps with the windsor adapter).

This is another, similar option: http://code.google.com/p/webdotnet/source/browse/trunk/Steeg.Framework/Web/Security/MemberShipProvider.cs?r=2

Where you just override Initialize() and manually instance the dependencies there. At least in the first one, you don't need to instance dependencies by hand (other than the provider itself).

There are then a few which also suggest using a service locator of some kind (MVC's or otherwise)

Then I've come across ninject injecting dependencies to properties on Membership.Provider rather easily with something like _kernel.Inject(Membership.Provider). This is much closer to what I want, keeping the composition root concept which drew me to using DI in the first place.

How can I achieve a similar result using castle?

Update: apparently this has issues with lifecycle management. Inject repository to custom membership provider with Ninject

Should I go for option #1 then? At least with that I instance the provider myself. So lifecycle management shouldn't be an issue.

I wouldn't go with implicit property injection, since the container will skip over the property if the type is not (correctly) registered, instead of failing fast (more info here). Instead I would use the Service Locator, but write a wrapper membership provider that does not contain any logic, but simply requests a membership provider from the service locator and calls that implementation. Jonas Gauffin wrote such a thing for MVC (using the DependencyResolver service locator), which is quite nice (also available on NuGet), but it is easy to do yourself.

Although the use of the service locator is considered an anti-pattern, please remember that the membership model must be configured through the web.config and this part of the system does not use the DependencyResolver.Current itself. Also writing such a DependencyResolverMembershipProvider is just a bit of mechanics and can be considered part of the composition root, not of the application. Calling the container inside your composition root is not a problem.