Add ability to register callbacks to run when named lifetime scopes are created

[alexmg]

From travis.illig on June 08, 2010 03:21:24

The current way that a lifetime scope is extended with new registrations is
using a callback when the lifetime scope is created, like this:

var builder = new ContainerBuilder();
builder.RegisterType().As();
var container = builder.Build();
var lifetime = container.BeginLifetimeScope(
b => b.RegisterType().As()
);

container.Resolve(); // Fails
lifetime.Resolve(); // Succeeds

This works well for extending a lifetime scope where the time of the scope
creation is known, but if you need to register an extension for a very
specific lifetime scope where you don't necessarily know the creation time,
it's less functional.

There is a notion of named lifetime scopes where you can start a lifetime
scope and give it a tag:

container.BeginLifetimeScope(
tag,
b => b.RegisterType().As()
);

It would be helpful to be able to register callbacks that would run for
specifically named lifetime scopes so they can be registered in modules or
during application startup. The idea would look more like this:

var builder = new ContainerBuilder();
builder.RegisterType().As();
builder.RegisterCallback(
tag,
b => b.RegisterType().As()
);
var container = builder.Build();
var untaggedLifetime = container.BeginLifetimeScope();
var taggedLifetime = container.BeginLifetimeScope(tag);

container.Resolve(); // Fails
untaggedLifetime.Resolve(); // Fails
taggedLifetime.Resolve(); // Succeeds

Any time the specifically-tagged lifetime scope gets created, that lifetime
scope gets the callbacks executed as though they were inline.

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

[alexmg]

From travis.illig on June 07, 2010 10:52:42

Realizing this one needs to be thought through a bit. Easy enough to figure out how
it works in a ContainerBuilder.Build() scenario, but less clear how
ContainerBuilder.Update() would work. Wholesale replacement of the list of named
lifetime callbacks? "Merge" the new callbacks with the existing set?

Probably a good candidate for a contrib library until some of the particulars can get
hashed out.

[alexmg]

From travis.illig on June 07, 2010 15:02:48

Added to the AutofacContrib.Multitenant library in the feature/multitenant branch of the repository. See "NamedLifetimeScopeCallbackContainerBuilder."

The way it works:

• NamedLifetimeScopeCallbackContainerBuilder registers a dictionary of tags/callbacks with the container it's building.
• Extension methods for beginning a lifetime scope using the set of registered callbacks were added in the ContainerExtensions class.

Status: Fixed

[alexmg]

From travis.illig on June 10, 2010 09:42:27

Re-opening and setting status to "New" since the idea, while helpful in a multitenant scenario, is not specific to multitenancy. Named lifetime scopes occur in web hosting as well (for request lifetimes), and this would allow registration, in a module, of callbacks to execute just during the creation of a request lifetime.

Status: New
Owner: ---

[alexmg]

From nicholas...@gmail.com on June 12, 2010 14:54:08

Thanks for reopening - I'd forgotten to do it.

This issue may tie in with #218. I'll have a look at both together and see if there is a common thread.

It seems as though the key here is "in a module", since I managed to get the same scenario as you've implemented in AutofacContrib.Multitenant to work without such an event, but only where the tenant-specific items are known at the time the multi-tenancy provider is created (e.g. in rough shape here: http://code.google.com/p/autofac/source/browse/trunk/src/Example/Remember.Web.MultiTenant/Global.asax.cs )

Back in the multi-tenant mail thread, a configuration mechanism was described whereby a separate config node might for each tenant might be supported. In that case you'd just create tenant-specific modules, which may be a way around this.

Labels: -Type-Defect Type-Enhancement

[alexmg]

From nicholas...@gmail.com on July 27, 2010 06:14:10

Closing again based on the most recent discussions/planning. If we do decide to pursue this there are some significant implications for the way scopes are currently created (those without customisation callbacks don't get their own registry.)

Status: WontFix