ExtensibleActionInvoker's filter attribute property injection is broken

[alexmg]

From [email protected] on March 23, 2011 09:22:06

Because the filters passed from the base action invoker also include the controller, property injection happens on the controller itself several times as the filters are processed.

The filter attributes also included in the collection may also be singletons cached by MVC, and so it is quite likely that dependencies may be overwritten with those from a concurrently executing request.

In all this behaviour is probably too risky to reliably support.

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

[alexmg]

From [email protected] on March 22, 2011 16:23:21

Removed property injection routine. (Breaking change.)

Status: Fixed

[alexmg]

From alex.meyergleaves on March 24, 2011 08:10:22

We can't go without property injection on FilterAttribute instances! Hopefully the commit below will sort it out:

Added a FilterAttributeFilterProvider implementation that performs property injection. This is supported by a new registration extension method called RegisterFilterProvider. The AutofacDependencyResolver now has a static property called Current for typed access to the current resolver. http://code.google.com/p/autofac/source/detail?r=ee052bfdad28b9974d296e7e78d19220c6c68b33

[alexmg]

From [email protected] on March 24, 2011 16:24:03

Sounds good. Did you have a look into the attribute caching behaviour of MVC3? From the release notes [1]:

Breaking Changes
In previous versions of ASP.NET MVC, action filters are create per request except in a few cases. This behavior was never a guaranteed behavior but merely an implementation detail and the contract for filters was to consider them stateless. In ASP.NET MVC 3, filters are cached more aggressively. Therefore, any custom action filters which improperly store instance state might be broken.

This would suggest that injecting any per-request instances into a filter attribute would lead to a race condition, but I haven't run the tests to verify it :)

Thoughts?

[1] http://www.asp.net/learn/whitepapers/mvc3-release-notes

[alexmg]

From [email protected] on March 24, 2011 16:25:38

(Note - I guess the alternative for injection into filter attributes would be to fall back to DependencyResolver.Current :( which is not an appealing one.)

[alexmg]

From alex.meyergleaves on March 24, 2011 22:52:36

Thanks Nick. You just reminded me that I forgot to pass false to the base FilterAttributeFilterProvider constructor for the cacheAttributeInstances parameter.

[alexmg]

From alex.meyergleaves on August 02, 2011 05:27:47

I have added documentation to the MVC 3 page on the wiki about the breaking change and how to use the new filter provider instead.

[alexmg]

From [email protected] on August 11, 2011 02:25:34

Great - thanks Alex.