Is it possible to instantiate a type, configured in UnityContainer, within the constructor of another type configured in UnityContainer? With my current solution, I'm getting a
ResolutionFailedException:
Resolution of the dependency failed, type = "Sample.IMyProcessor", name = "(none)".
Exception occurred while: while resolving.
Exception is: VerificationException - Operation could destabilize the runtime.
The Problem is that my second class (FileLoader) has an argument which should be evaluated in the first constructor:
The Constructor of the MyProcessor class:
public class MyProcessor : IMyProcessor
{
private readonly IFileLoader loader;
private readonly IRepository repository;
public MyProcessor(IRepository repository, string environment, Func<SysConfig, IFileLoader> loaderFactory)
{
this.repository = repository;
SysConfig config = repository.GetConfig(environment);
loader = loaderFactory(config);
}
public void DoWork()
{
loader.Process();
}
}
And here the Main function with the UnityContainer config:
public static void Run()
{
var unityContainer = new UnityContainer()
.RegisterType<IRepository, MyRepository>()
.RegisterType<IFileLoader, FileLoader>()
.RegisterType<IMyProcessor, MyProcessor>(new InjectionConstructor(typeof(IRepository), "DEV", typeof(Func<SysConfig, IFileLoader>)));
//Tests
var x = unityContainer.Resolve<IRepository>(); //--> OK
var y = unityContainer.Resolve<IFileLoader>(); //--> OK
var processor = unityContainer.Resolve<IMyProcessor>();
//--> ResolutionFailedException: "Operation could destabilize the runtime."
processor.DoWork();
}
And the FileLoader class:
public class FileLoader : IFileLoader
{
private readonly SysConfig sysConfig;
public FileLoader(SysConfig sysConfig, IRepository repository)
{
this.sysConfig = sysConfig;
}
public void Process()
{
//some sample implementation
if (sysConfig.IsProduction)
Console.WriteLine("Production Environement");
else
Console.WriteLine("Test Environment");
}
}
I assume the Problem is related to the Func which is passed to the MyProcessor class. Is there another way to pass the loaderFactory to the MyProcessor class?
Thanks!
The issue is that Unity automatic factories only support Func<T> and not any other of the Func generics.
You could register the Func you want with Unity and then it will be resolved:
Func<SysConfig, IFileLoader> func = config => container.Resolve<IFileLoader>();
container.RegisterType<Func<SysConfig, IFileLoader>>(new InjectionFactory(c => func));
var processor = container.Resolve<IMyProcessor>();
There are some other solutions out there such as this: Unity's automatic abstract factory
Related
I have come across several posts where a single interface is implemented by multiple classes and the dependency is registered and resolved. One such post is this one.
But how to resolve multiple, multi-level dependencies?
For example:
public enum ShortEnum { Short, Long }
public interface ISomeValidator
{
bool ValidateInputString(string str);
}
public class ConValidator : ISomeValidator
{
public bool ValidateInputString(string str) => true;
}
public class DonValidator : ISomeValidator
{
public bool ValidateInputString(string str) => false;
}
public class ConProvider : ISomeProvider
{
ISomeValidator conValidator; // Expects instance of ConValidator
public ConProvider(ISomeValidator someValidator)
{
conValidator = someValidator;
}
}
public class DonProvider : ISomeProvider
{
ISomeValidator donValidator; // Expects instance of DonValidator
public DonProvider(ISomeValidator someValidator)
{
donValidator = someValidator;
}
}
ShortEnum can be used as key. That means depending upon its value, either ConProvider or DonProvider is returned. Now, the providers have a dependency on ISomeValidator, which, again depending upon the key value of ShortEnum can be resolved as the instance of ConValidator or DonValidator.
In other words, I want to build the following two object graphs:
var provider1 = new ConProvider(new ConValidator());
var provider2 = new DonProvider(new DonValidator());
What is the best way to utilize .NET Core 3.1 in-built dependency injection mechanism?
There are three ways to achieve what you want.
The first option is to fall back to manually wiring the object graphs by registering a delegate that composes the required object graphs completely, for instance:
services.AddTransient<ISomeProvider>(
c => new ConProvider(new ConValidator());
services.AddTransient<ISomeProvider>(
c => new DonProvider(new DonValidator());
This, however, will become quite cumbersome once those classes get other dependencies, because you would very quickly start to circumvent the DI Container completely.
So instead, as a second option, you can configure the container in such way that you only have to new the two providers:
// Note how these validators are -not- registered by their interface!
services.AddTransient<ConValidator>(); // Might have dependencies
services.AddTransient<DonValidator>(); // of its own
services.AddTransient<ISomeProvider>(c =>
new ConProvider(
someValidator: c.GetRequiredService<ConValidator>(),
otherDependency1: c:GetRequiredService<IDependency1>());
services.AddTransient<ISomeProvider>(c =>
new DonProvider(
someValidator: c.GetRequiredService<DonValidator>(),
otherDependency2: c:GetRequiredService<IDependency2>());
This is a more-flexible solution compared to the first. But still, changes to the constructors of ConProvider and DonProvider force you to update their registrations.
To combat this, as a third option, you can use the ActivatorUtilities class. It will help you in achieving Auto-Wiring, where the container figures out which dependencies are required. That might look like this:
services.AddTransient<ConValidator>();
services.AddTransient<DonValidator>();
services.AddTransient<ISomeProvider>(c =>
ActivatorUtilities.CreateInstance<ConProvider>(
c,
c.GetRequiredService<ConValidator>());
services.AddTransient<ISomeProvider>(c =>
ActivatorUtilities.CreateInstance<DonProvider>(
c,
c.GetRequiredService<DonValidator>());
ActivatorUtilities.CreateInstance will create the requested class for you; in this case either ConProvider or DonProvider. It does so by looking at the constructor of the type and resolving all constructor parameters from the supplied c service provider. It resolves all dependencies from the service provider -except- the dependencies you supplied manually to the CreateInstance method. In the example above it will match the ISomeValidator dependency to the supplied DonValidator or ConValidator and inject them instead.
If I understood it correctly, you want ConValidator instance for ConProvider and DonValidator instance for DonProvider and Providers should be resolved on ShortEnum value.
we can modify dependencies like below
public interface ISomeProvider
{
void Method1();
}
public interface ISomeValidator
{
bool ValidateInputString(string str);
}
public class ConValidator : ISomeValidator
{
public bool ValidateInputString(string str) => true;
}
public class DonValidator : ISomeValidator
{
public bool ValidateInputString(string str) => false;
}
public class ConProvider : ISomeProvider
{
ISomeValidator conValidator; // Expects instance of ConValidator
public ConProvider(ValidatorResolver validatorResolver) =>
conValidator = validatorResolver(ShortEnum.Short);
public void Method1() => Console.WriteLine("Method1 COnProvider");
}
public class DonProvider : ISomeProvider
{
ISomeValidator donValidator; // Expects instance of DonValidator
public DonProvider(ValidatorResolver validatorResolver) =>
donValidator = validatorResolver(ShortEnum.Long);
public void Method1() => Console.WriteLine("Method1 DonProvider");
}
public enum ShortEnum { Short, Long }
declare delgates
public delegate ISomeProvider ProviderResolver(ShortEnum shortEnum);
public delegate ISomeValidator ValidatorResolver(ShortEnum shortEnum);
Consumer Service
public class SomeOtherService
{
private readonly ISomeProvider _provider;
public SomeOtherService(ProviderResolver providerResolver)
{
_provider = providerResolver(ShortEnum.Short);
//OR
_provider = providerResolver(ShortEnum.Long);
_provider.Method1();
}
}
In ConfigureServices method of StartUp class
services.AddTransient<ConValidator>();
services.AddTransient<DonValidator>();
services.AddTransient<ConProvider>();
services.AddTransient<DonProvider>();
services.AddTransient<ProviderResolver>(serviceProvider => (shortEnum) =>
{
switch (shortEnum)
{
case ShortEnum.Short:
return serviceProvider.GetService<ConProvider>();
case ShortEnum.Long:
return serviceProvider.GetService<DonProvider>();
default:
throw new KeyNotFoundException();
}
});
services.AddTransient<ValidatorResolver>(serviceProvider => (shortEnum) =>
{
switch(shortEnum)
{
case ShortEnum.Short:
return serviceProvider.GetService<ConValidator>();
case ShortEnum.Long:
return serviceProvider.GetService<DonValidator>();
default:
throw new KeyNotFoundException();
}
});
services.AddTransient<SomeOtherService>();
Little background: I am working on a topology using Apache Storm, I thought why not use dependency injection in it, but I was not sure how it will behave on cluster environment when topology deployed to cluster. I started looking for answers on if DI is good option to use in Storm topologies, I came across some threads about Apache Spark where it was mentioned serialization is going to be problem and saw some responses for apache storm along the same lines. So finally I decided to write a sample topology with google guice to see what happens.
I wrote a sample topology with two bolts, and used google guice to injects dependencies. First bolt emits a tick tuple, then first bolt creates message, bolt prints the message on log and call some classes which does the same. Then this message is emitted to second bolt and same printing logic there as well.
First Bolt
public class FirstBolt extends BaseRichBolt {
private OutputCollector collector;
private static int count = 0;
private FirstInjectClass firstInjectClass;
#Override
public void prepare(Map map, TopologyContext topologyContext, OutputCollector outputCollector) {
collector = outputCollector;
Injector injector = Guice.createInjector(new Module());
firstInjectClass = injector.getInstance(FirstInjectClass.class);
}
#Override
public void execute(Tuple tuple) {
count++;
String message = "Message count "+count;
firstInjectClass.printMessage(message);
log.error(message);
collector.emit("TO_SECOND_BOLT", new Values(message));
collector.ack(tuple);
}
#Override
public void declareOutputFields(OutputFieldsDeclarer outputFieldsDeclarer) {
outputFieldsDeclarer.declareStream("TO_SECOND_BOLT", new Fields("MESSAGE"));
}
#Override
public Map<String, Object> getComponentConfiguration() {
Config conf = new Config();
conf.put(Config.TOPOLOGY_TICK_TUPLE_FREQ_SECS, 10);
return conf;
}
}
Second Bolt
public class SecondBolt extends BaseRichBolt {
private OutputCollector collector;
private SecondInjectClass secondInjectClass;
#Override
public void prepare(Map map, TopologyContext topologyContext, OutputCollector outputCollector) {
collector = outputCollector;
Injector injector = Guice.createInjector(new Module());
secondInjectClass = injector.getInstance(SecondInjectClass.class);
}
#Override
public void execute(Tuple tuple) {
String message = (String) tuple.getValue(0);
secondInjectClass.printMessage(message);
log.error("SecondBolt {}",message);
collector.ack(tuple);
}
#Override
public void declareOutputFields(OutputFieldsDeclarer outputFieldsDeclarer) {
}
}
Class in which dependencies are injected
public class FirstInjectClass {
FirstInterface firstInterface;
private final String prepend = "FirstInjectClass";
#Inject
public FirstInjectClass(FirstInterface firstInterface) {
this.firstInterface = firstInterface;
}
public void printMessage(String message){
log.error("{} {}", prepend, message);
firstInterface.printMethod(message);
}
}
Interface used for binding
public interface FirstInterface {
void printMethod(String message);
}
Implementation of interface
public class FirstInterfaceImpl implements FirstInterface{
private final String prepend = "FirstInterfaceImpl";
public void printMethod(String message){
log.error("{} {}", prepend, message);
}
}
Same way another class that receives dependency via DI
public class SecondInjectClass {
SecondInterface secondInterface;
private final String prepend = "SecondInjectClass";
#Inject
public SecondInjectClass(SecondInterface secondInterface) {
this.secondInterface = secondInterface;
}
public void printMessage(String message){
log.error("{} {}", prepend, message);
secondInterface.printMethod(message);
}
}
another interface for binding
public interface SecondInterface {
void printMethod(String message);
}
implementation of second interface
public class SecondInterfaceImpl implements SecondInterface{
private final String prepend = "SecondInterfaceImpl";
public void printMethod(String message){
log.error("{} {}", prepend, message);
}
}
Module Class
public class Module extends AbstractModule {
#Override
protected void configure() {
bind(FirstInterface.class).to(FirstInterfaceImpl.class);
bind(SecondInterface.class).to(SecondInterfaceImpl.class);
}
}
Nothing fancy here, just two bolts and couple of classes for DI. I deployed it on server and it works just fine. The catch/problem though is that I have to initialize Injector in each bolt which makes me question what is side effect of it going to be?
This implementation is simple, just 2 bolts.. what if I have more bolts? what impact it would create on topology if I have to initialize Injector in all bolts?
If I try to initialize Injector outside prepare method I get error for serialization.
I've run into what I believe must be a common dependency injection-related problem. I'm having trouble finding relevant examples, and I do not like the best solution I've been able to come up with.
public class WasherDryerFolderSystem : ILaundrySystem
{
private IWasher _washer;
private IDryer _dryer;
private IFolder _folder;
public WasherDryerFolderSystem(IWasher washer, IDryer dryer, IFolder folder)
{...}
public void DoLaundry()
{
_washer.Wash();
_dryer.Dry();
_folder.Fold();
}
}
public class HandWasher : IWasher {...}
public class MachineWasher : IWasher {...}
public class HandDryer : IDryer {...}
public class MachineDryer : IDryer {...}
public class HandFolder : IFolder {...}
public class MachineFolder : IFolder {...}
Now in the main app I have something like
var laundrySystem = _kernel.Get<ILaundrySystem>(someUserInput);
What is a good way to configure the bindings required for something like this? Here's what I've been able to come up with thus far (that I don't like):
Bind<ILaundrySystem>().To<WasherDryerFolderSystem>()
.Named(MACHINEWASH_HANDDRY_HANDFOLD)
.WithConstructorArgument("washer", new MachineWasher())
.WithConstructorArgument("dryer", new HandDryer())
.WithConstructorArgument("folder", new HandFolder());
At first I didn't think this looked too bad, but when Washers and Dryers and Folders all have their own dependencies, this quickly gets ugly.
This feels to me like it should be a common problem, but I'm not finding anything that's much help. Do I have something designed incorrectly?
You could use a factory pattern:
public interface ILaundrySystemFactory
{
ILaundrySystem Create(string someUserInput);
}
public class LaundrySystemFactory : ILaundrySystemFactory
{
private readonly IKernel _kernel;
public LaundrySystemFactory(IKernel kernel){
_kernel = kernel;
}
public ILaundrySystem Create(string someUserInput)
{
if(someUserInput){
var washer = _kernel.Get<MachineWasher>();
var dryer = _kernel.Get<HandDryer>();
var folder = _kernel.Get<HandFolder>();
} else {
var washer = _kernel.Get<DifferentWasher>();
var dryer = _kernel.Get<DifferentDryer>();
var folder = _kernel.Get<DifferentFolder>();
}
return new WasherDryerFolderSystem(washer, dryer, folder);
}
}
and then simply
private readonly ILaundrySystemFactory _laundrySystemFactory;
ctor(ILaundrySystemFactory laundrySystemFactory){
_laundrySystemFactory = laundrySystemFactory;
}
public UserInputMethod(string someUserInput)
{
var loundrySystem = laundrySystemFactory.Create(someUserInput);
var loundry = loundrySystem.DoLaundry();
}
bindings:
Bind<ILaundrySystemFactory>().To<LaundrySystemFactory>();
(some DI containers might also need something like:)
Bind<MachineWasher>().To<MachineWasher>();
Make a concrete classes with concrete parameters you need, put them as dependencies of strategy which will use them based on user input. Next instantiate them all with SINGLE call for a resolution root class. OFC Strategy can be the resolution root itself but it also can be a dependency of different resoultion root. Example:
//DoLaundry based on user input
public class WasherDryerFolderSystemStrategy
{
ctor(MachineWashingHandDringHandFoldingSystem first,
MachineWashingHandDringHandFoldingSystem second,
HandWashingHandDringHandFoldingWithBreakfastSystem third) { ... }
public void DoLaundry(int userInput)
{
if(userInput == 1)
first.DoLaundry();
if(userInput == 2)
second.DoLaundry();
if(userInput == 3)
third.DoLaundry();
}
}
// MACHINEWASH_HANDDRY_HANDFOLD
public class MachineWashingHandDringHandFoldingSystem : WasherDryerFolderSystem
{
public MachineWashingHandDringHandFoldingSystem
(MachineWasher machineWasher, HandDryer handDryer, HandFolder handFolder) :
base(machineWasher, handDryer, handFolder)
{
}
}
// HANDWASH_HANDDRY_HANDNOFOLD
public class HandWashingHandDringHandFoldingSystem : WasherDryerFolderSystem
{
public MachineWashingHandDringHandFoldingSystem
(HandWasher machineWasher, HandDryer handDryer, HandFolder handFolder) :
base(machineWasher, handDryer, handFolder)
{
}
}
// HANDWASH_HANDDRY_HANDNOFOLD_WITHBREAKFAST
public class HandWashingHandDringHandFoldingWithBreakfastSystem : WasherDryerFolderSystem
{
private readonly BreakfastMaker breakfastMaker
public MachineWashingHandDringHandFoldingSystem
(HandWasher machineWasher, HandDryer handDryer, HandFolder handFolder, BreakfastMaker brekfastMaker) :
base(machineWasher, handDryer, handFolder)
{
this.breakfastMaker = breakfastMaker
}
public overide void DoLaundry()
{
base.DoLaundry();
brekfastMaker.AndMakeChipBreakAsWell();
}
}
Please note that the implementation above does not require any Ninject configuration. Ninject will autobind everything ToSelf() with the first use (as long as it is not an interface).
In general as long as you do not need some sort of composite/bulk operations with with multiple implementations, than you should avoid interface bindings (and interfaces at all). Composite like operation example:
// original WasherDryerFolderSystem refactored
public class WasherDryerFolderSystem
{
private IEnumerable<IWasher> washers;
private IEnumerable<IDryer> dryers;
private IEnumerable<IFolder> folders;
public WasherDryerFolderSystem(
IWasher[] washers, IDryer[] dryers, IFolder[] folders)
{
this.washers = washers;
this.dryers = dryers;
this.folders = folders;
}
// all inclusive
public virtual void DoLaundry()
{
foreach (var washer in washers)
washer.Wash();
foreach (var dryer in dryers)
dryer.Dry();
foreach (var folder in folders)
folder.Fold();
}
}
I hope that helps.
So basically, I have a situation where I want to inject primitive types into a class (i.e. a String and an Integer). You can think of a URL and port number for an application as example inputs. I have three components:
Now say I have a class, which does take in these params:
public class PrimitiveParamsDIExample {
private String a;
private Integer b;
public PrimitiveParamsDIExample(String a, Integer b) {
this.a = a;
this.b = b;
}
}
So my question here is simple. How do I inject a and b into class PrimitiveParamsDIExample?
In general, this is also asking how to inject parameters that are decided on runtime as well. If I have a and b above, read from STDIN or from an input file, they're obviously going to be different from run to run.
All the more, how do I do the above within the HK2 framework?
EDIT[02/23/15]: #jwells131313, I tried your idea, but I'm getting the following error (this one for the String param; similar one for int):
org.glassfish.hk2.api.UnsatisfiedDependencyException: There was no object available for injection at Injectee(requiredType=String,parent=PrimitiveParamsDIExample,qualifiers
I set up classes exactly as you did in your answer. I also overrode the toString() method to print both variables a and b in PrimitiveParamsDIExample. Then, I added the following in my Hk2Module class:
public class Hk2Module extends AbstractBinder {
private Properties properties;
public Hk2Module(Properties properties){
this.properties = properties;
}
#Override
protected void configure() {
bindFactory(StringAFactory.class).to(String.class).in(RequestScoped.class);
bindFactory(IntegerBFactory.class).to(Integer.class).in(RequestScoped.class);
bind(PrimitiveParamsDIExample.class).to(PrimitiveParamsDIExample.class).in(Singleton.class);
}
}
So now, I created a test class as follows:
#RunWith(JUnit4.class)
public class TestPrimitiveParamsDIExample extends Hk2Setup {
private PrimitiveParamsDIExample example;
#Before
public void setup() throws IOException {
super.setupHk2();
//example = new PrimitiveParamsDIExample();
example = serviceLocator.getService(PrimitiveParamsDIExample.class);
}
#Test
public void testPrimitiveParamsDI() {
System.out.println(example.toString());
}
}
where, Hk2Setup is as follows:
public class Hk2Setup extends TestCase{
// the name of the resource containing the default configuration properties
private static final String DEFAULT_PROPERTIES = "defaults.properties";
protected Properties config = null;
protected ServiceLocator serviceLocator;
public void setupHk2() throws IOException{
config = new Properties();
Reader defaults = Resources.asCharSource(Resources.getResource(DEFAULT_PROPERTIES), Charsets.UTF_8).openBufferedStream();
load(config, defaults);
ApplicationHandler handler = new ApplicationHandler(new MyMainApplication(config));
final ServiceLocator locator = handler.getServiceLocator();
serviceLocator = locator;
}
private static void load(Properties p, Reader r) throws IOException {
try {
p.load(r);
} finally {
Closeables.close(r, false);
}
}
}
So somewhere, the wiring is messed up for me to get an UnsatisfiedDependencyException. What have I not correctly wired up?
Thanks!
There are two ways to do this, but one isn't documented yet (though it is available... I guess I need to work on documentation again...)
I'll go through the first way here.
Basically, you can use the HK2 Factory.
Generally when you start producing Strings and ints and long and scalars like this you qualify them, so lets start with two qualifiers:
#Retention(RUNTIME)
#Target( { TYPE, METHOD, FIELD, PARAMETER })
#javax.inject.Qualifier
public #interface A {}
and
#Retention(RUNTIME)
#Target( { TYPE, METHOD, FIELD, PARAMETER })
#javax.inject.Qualifier
public #interface B {}
then write your factories:
#Singleton // or whatever scope you want
public class StringAFactory implements Factory<String> {
#PerLookup // or whatever scope, maybe this checks the timestamp?
#A // Your qualifier
public String provide() {
// Write your code to get your value...
return whatever;
}
public void dispose(String instance) {
// Probably do nothing...
}
}
and for the Integer:
#Singleton // or whatever scope you want
public class IntegerBFactory implements Factory<Integer> {
#PerLookup // or whatever scope, maybe this checks the timestamp?
#B // Your qualifier
public Integer provide() {
// Write your code to get your value...
return whatever;
}
public void dispose(String instance) {
// Probably do nothing...
}
}
Now lets re-do your original class to accept these values:
public class PrimitiveParamsDIExample {
private String a;
private int b;
#Inject
public PrimitiveParamsDIExample(#A String a, #B int b) {
this.a = a;
this.b = b;
}
}
Note I changed Integer to int, well... just because I can. You can also just use field injection or method injection in the same way. Here is field injection, method injection is an exercise for the reader:
public class PrimitiveParamsDIExample {
#Inject #A
private String a;
#Inject #B
private int b;
public PrimitiveParamsDIExample() {
}
}
There are several ways to bind factories.
In a binder: bindFactory
Using automatic class analysis: addClasses
An EDSL outside a binder: buildFactory
I'm trying to use the mvc-mini-profiler in my mvc application. I created a wrapper for my context and Castle Windsor creates the instance. However, I get the error "The space 'SSpace' has no associated collection". The edmx is in assembly A, DigidosEntities in assembly B and this is in assembly C. Any idea what can be the problem? I got the latest version of the profiler.
public interface IDataStore : IDisposable
{
int SaveChanges(int personId);
IObjectSet<TEntity> CreateObjectSet<TEntity>() where TEntity : class;
}
public class ProfiledDigidosEntities : IDataStore, IDisposable
{
private DigidosEntities _context = null;
public ProfiledDigidosEntities()
{
var connectionString = ConfigurationManager.ConnectionStrings["DigidosEntities"].ConnectionString;
var connection = new EntityConnection(connectionString);
var conn = ProfiledDbConnection.Get(connection);
_context = ObjectContextUtils.CreateObjectContext<DigidosEntities>(conn); /* Error: The space 'SSpace' has no associated collection */
}
public void Dispose()
{
if (_context != null)
_context.Dispose();
}
public int SaveChanges(int personId)
{
return _context.SaveChanges(personId);
}
public IObjectSet<TEntity> CreateObjectSet<TEntity>() where TEntity : class
{
return _context.CreateObjectSet<TEntity>();
}
}
Ok, here was my problem: The profiler wants a workspace to make a new profiled connection, the workspace is created through this method (in ObjectContextUtils.cs):
static MetadataCache()
{
workspace = new System.Data.Metadata.Edm.MetadataWorkspace(
new string[] { "res://*/" },
new Assembly[] { typeof(U).Assembly });
}
As you can see it will search in assembly of the type you want to create. Since in my case the type of the model was not in the same assembly, the creation of the workspace failed. Moving the DigidosEntities to the same assembly as the edmx fixed it.