Autofac Delegate Factories - How to create a new instance each time? - autofac

Question: How do I use the Autofac Factory delegate to create a new instance while within an existing Autofac Lifetime scope?
According to Autofac documentation,
If you register an object as InstancePerDependency() and call the
delegate factory multiple times, you’ll get a new instance each time.
This is not true when injecting the factory into the constructor of a class within an existing lifetime scope
Some additional background: I'm attempting to use Autofac Delegate Factories in order to create a new instance of a ValueObject class each time.
This ValueObject class's constructor and delegate factory look like this:
public SlaInMinutes(int slaInMinutes, ISlaCalculator slaCalculator, ITicketUnitOfWork ticketUnitOfWork)
public delegate SlaInMinutes Factory(int slaInMinutes);
Autofac registration looks like this:
builder.RegisterType<SlaInMinutes>().InstancePerLifetimeScope();
When I inject the Factory delegate into a class constructor (SlaInMinutes.Factory slaFactory) within an existing LifetimeScope I am able to instantiate a new class using the Factory parameter, and Autofac takes care of the remaining constructor dependencies. It's great.
Except it's the same instance every time after I instantiate it once. I need to have an new instance each time I call this Factory delegate based on the Factory parameter int slaInMinutes.
Switching my registration from InstancePerLifetimeScope to InstancePerDependency:
builder.RegisterType<SlaInMinutes>().InstancePerDependency()
does not have the effect of creating a new instance each time I call the Factory method.
What I need:
slaFactory.Invoke(1) //new instance
slaFactory.Invoke(2) //new instance
slaFactory.Invoke(1) //same instance or new instance, don't care
This is an ASP.NET Core 1.0 web app, and the Lifetime scope is started during the beginning of an API endpoint call, and it lasts until that API call is completed.

Remove InstancePerDependency/InstancePerDependency method call from your registration if you want to create new instance for each call.
You can refer to the link https://autofaccn.readthedocs.io/en/latest/lifetime/instance-scope.html?highlight=InstancePerDependency for more details regarding instance scope.

Related

How do I register a binding with both delayed instantiation and as a singleton

I am new to scaldi. I have a class being used in my cloud environment configuration where I want two things to happen.
bind [EnvironmentInfo] to new EnvironmentInfo initWith(_.init())
First, I want it to be a singleton. It retrieves the runtime information (Google AppEngine in this case) and it should do this once on instantiation. It seems like initWith is a good choice.
Next, I want instantiation to be delayed until first request. Following the execution path it is being instantiated well before the first call.
If I can get delayed instantiation, then initWith should move to the class constructor.
My answer ended up being simple. I abstracted the singleton "state" and accessed it as a 'lazy val ...'.

WCF with IOperationInvoker using Entity and Ninject

I have a WCF Service from which I need to log the calls to its methods. For this, I used this solution to be able to track the calls and call my internal audit service, which uses Entity 5.1 and injects the services/repositories/DbContext using Ninject.
My Invoke method looks like this:
public object Invoke(object instance, object[] inputs, out object[] outputs)
{
var methodParams = (instance).GetType().GetMethod(_operationName).GetParameters();
var parameters = new Dictionary<string, object>();
for (var index = 0; index < inputs.Length; index++)
parameters.Add(methodParams[index].Name, inputs[index]);
_auditService.TrackFilterParametersValues(_operation.Parent.Type.FullName, _operationName, _operation.Action, parameters);
return _baseInvoker.Invoke(instance, inputs, out outputs);
}
In my Ninject module I have the internal stuff registered like this:
Bind<IAuditService>().To<AuditeService>().InRequestScope();
Bind(typeof(IRepository<>)).To(typeof(Repository<>)).InRequestScope();
Bind<IUnitOfWork>().To<UnitOfWork>().InRequestScope();
Bind<DbContext>().To<MyEntities>().InRequestScope();
Problem comes up when, inside the Repository, I call the dbContext to add the new Audit object like this:
_dbContext.Set<T>().Add(entity);
It errors out claiming that the DbContext has been disposed.
What would be the correct way of registering the DbContext on a WCF Service so it gets registered for an IOperationInvoker??
I have to mention that I have all this declaration the same for the main site I'm feeding up with this backend in MVC4 and it works perfectly (no WCF there). So I'm pretty sure something is needed to be corrected for the WCF lifetime cycle, but not so sure about what.
I found the reason of why this was behaving so nasty: in the chain formed by the IOperationInvoker, IOperationBehavior and IServiceBehavior, I was injecting the AuditService by the constructor of the first 2 of them, but in the latest (IServiceBehavior), since I was decorating the WCF class with it and couldn't overload the constructor, I was using the DependencyResolver to obtain the AuditService with a property like this:
public IAuditService AuditService
{
get { return DependencyResolver.Current.GetService<IAuditService>();
}
Then, when I started to debug, I noticed that the constructors were called when the WCF Test Client was querying the WCF for the WSDL data, but the Invoke method was never called because no web method was being invoked. So the AuditService instance (and DbContext) was all fine during the calls of the constructors, but by the time of invoking a web method and calling the Invoke method of the IOperationInvoker, the DbContext was already disposed long time ago.
My workaround for this was to delete all the references to the AuditService from all constructors and move the property with the DependencyResolver from the ServiceBehavior to the IOperationInvoker implementation. Once I did this, the AuditService is called right when it's needed, never before, and its DbContext is never disposed.
If MyEntities inherits from DbContext, then this should work:
Bind(typeof(DbContext)).To(typeof(MyEntities)).InRequestScope();

How do you get a new service bean implementation instance each time you call an OSGi Blueprint service?

I have a java class, call it "Job", that implements an interface that I export as a service using blueprint. Although the class is defined as a bean with scope="prototype" in the blueprint xml file, and the service referen ces that bean, I can see from a System.out.println(this) statement in an instance method of the Job, that each time I access the service from a caller bundle, it reuses the same instance of the class Job that it created when I start the bundle; my caller bundle looks up the service references, calls context.getService(serviceReferences[0]) to get the reference to the Job service and then calls the method on that service (eg. Job.run()).
I thought making the scope of the service bean def prototype would give me a new instance of Job each time I called getService from the caller bundle, but my experiments are showing me that it's still using the same object instance.
So how do I call the service and have it create a new instance of Job each time, rather than reusing the same object?
I also need another service reference injected as a property into the bean Job since the bean interface doesn't have a set method to do this. So each new instance has to be created as the bean Job so that it can inject the property with a setX() method.
If you use prototype scope for a bean, it means that a new instance will be created every time the bean is injected to another bean / service within the same blueprint container.
In your case a new instance of a bean is created as it is injected into the service component. However, the service component can provide only the same instance every time it is requested by another bundle.
For me it seems to me that you try to use blueprint and prototype scope for a task that should be done programmatically. You want to use a service that creates a new instance every time. That means that you should define a JobFactory interface and its implementation and register it as an OSGi service. On the other side, you should use JobFactory to instantiate as many Job instances as you want.
You could also use PrototypeServiceFactory but you have to register it programmatically as well. In my opinion, when someone wants to use PrototypeServiceFactory, it is time to extend the API with a Factory.

JPA2, JAX-RS: #PersistentContext, How to get EntityManager in a Facade constructor?

I have a JAX-RS web service that was generated by Netbeans. There are non-abstract facade classes for the service's endpoints. The persistence context is being injected into the non-abstract facade. Everything is working well and I see my data being returned to Fiddler.
We are using DTOs and I am implementing an assembler pattern. So, in the non-abstract facade's constructor, I am creating an instance of the assembler, and am passing the facade's entity manager instance into it. Unfortunately, it seems that the injection of the persistence context has not happened before the facade's constructor has been called, so I cannot pass the entity manager instance into the assembler for its to use in mapping operations. Kind of a chicken-before-the-end situation... I cannot figure out how to make this work... Is there some kind of post-constructor method that I can override and perform the initialization of the assembler and pass in the entity manager to it? I'd really appreciate your help and suggestions.
Thank you for your time and ideas,
Mike
Use method marked with #PostConstruct annotation. Like this:
#PostConstruct
private void init() {
// I'm called after all injections have been resolved
// initialize some object variables here
...
}
In that method you can use both, object fields initialized in the constructor and passed by injection.

How to bind Factory into current request scope?

How do I dynamically bind a new Factory into the current request scope? I want the binding to get removed automatically at the end of the current HTTP request.
The provide method of the Factory can be annotated with #RequestScope and then the thing provided by the factory will be in the RequestScope (and hence the factory provide method should get called every time the RequestScope changes).
Is this what you are asking?
It also depends on how you are binding it. Are you using one of the automatic analyzers of the class, or are you using a bind API?
Even the Factory itself (not the provide method) can be in the RequestScope, in which case a new instance of the Factory implementation will get created whenever the RequestScope changes