TypeResolver, InjectionMember and multi-thread

Oct 15, 2010 at 5:35 PM


I have a custom InjectionMember class that uses TypeResolver.ResolveType when it adds policy. The problem is that I can register the type in a thread, and instanciate it in a different thread. I know that TypeResolver uses a ThreadStatic variable for storing the configuration elements. So an exception is raised when I try to resolve my type (actually a literal from the config file).

Currently, I have applied the following work-arround :
1) I pass a reference of the current configurationSection to the InjectionMember when I register a type.
2) I call "TypeResolver.SetAliases(currentSection)" if UnityConfigurationSection.CurrentSection is null.

I would like to know if a proper solution exists.


Oct 17, 2010 at 5:56 AM

TypeResolver really wasn't designed to be used outside the configuration loading process. The static is there because of the nature of ConfigurationSections.

You could use the TypeResolverImpl class - that's where the logic for mapping types actually lives, and it's just an instance. You'd need to pull the aliases out the the configuration section to initialize it but from then on you don't need to carry the configuration information around.


Oct 18, 2010 at 2:05 PM

Thanks for your response. Particularly the first words : "TypeResolver really wasn't designed to be used outside the configuration loading process."
That makes me aware of a design issue and I finally refactor my whole code.

I now load my types directly in the method GetInjectionMember of my InjectionMemberElement (instead of loading it inside the builder strategy - the lazy way). The constructor of my InjectionMember now takes types instead of literals and a configsection. (actually, it's a more complex problem, but I finally found a solution that looks good to me).

FYI, this config file resumes pretty well my original design issue :
    <!-- some elements with attributes containing type aliases -->
I have naturally opted for a lazy loading. But I realized that performance was not really a requirement at this stage of my application.