Property Injection in Web API ActionFilterAttribute does not use Http request scope

[alexmg]

From rob.lyn...@gmail.com on August 01, 2013 23:58:40

What steps will reproduce the problem? 1. Register NHibernate using the standard pattern:

builder.Register(c => cfg.BuildSessionFactory()).As().SingleInstance();
builder.Register(c => c.Resolve().OpenSession()).InstancePerWebApiRequest();

1. Create a TransactionAttribute class that derives from the Web API ActionFilterAttribute. Add a public get/set property called Session, of type ISession.
2. Register the filter provider in the setup method:

builder.RegisterWebApiFilterProvider(GlobalConfiguration.Configuration);

1. Add a TransactionAttribute to any web api controller action. It will fail to be picked up because the filter provider has tried to use the configuration.DependencyResolver to resolve the Session property, rather than the HttpRequest scope. What is the expected output? What do you see instead? What version of Autofac are you using? On what version of .NET/Silverlight? Please provide any additional information below.

Original issue: http://code.google.com/p/autofac/issues/detail?id=452

[alexmg]

From travis.illig on August 08, 2013 13:59:25

Labels: Module-Integration-WebApi

[tillig]

As it turns out, this is by design.

When attribute filters are located by the base Web API framework, the actual attribute instances are cached in the action descriptor (or controller descriptor) inside the application HttpConfiguration object - effectively making the attribute filters singletons.

You can see this if you look at the source for ActionDescriptorFilterProvider and start following the chain of execution - ReflectedHttpActionDescriptor (the primary implementation of HttpActionDescriptor) caches the generated list of filters; HttpControllerDescriptor also caches the set of custom attributes/filters.

As such, if the properties get resolved out of the request context, once the current request is over, the set of cached filters effectively becomes invalid, working against disposed/stale dependencies. There's nothing we can really do about that.

Even if you register Autofac action filters, the "request lifetime scope" from which the filters get resolved is not actually the same request lifetime scope being used to resolve the controller servicing the request. We don't get access to the current request lifetime scope from inside the IFilterProvider interface, so, again, we don't have much choice.

Given we can't change things from our end, I'm going to close this one as wontfix. If the Web API framework updates to enable better handling of this, we'll certainly take a look at updating.

[tillig]

As noted in #525, a potential fix would be to dynamically proxy all filters such that the filter instance cached is the proxy and the actual thing executing would be resolved each request. However, that may be challenging to maintain and may interfere with other things in unexpected ways.