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.
Related
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.
We are using Autofac 4 for DI and I started experimenting with AI a short while ago. Now I created a IdentityTelemetryInitializer class which needs and IIdentityProvider to be able to get the ID of the current authorized user and set it add it to the context. I cannot find a way in which to inject dependencies into a TelemetryInitializer. If I define a contructor that takes an IIdentityProvider, the custom initializer is skipped altogether.
Any ideas are welcome. I was thinking of having the user ID also set as the Thread Principal so that we can access it this way, but I was hoping I could use DI for this?
You cannot inject dependencies using a constructor as the initializer initialized internally using the default (empty) constructor. When you explicitly defined a new ctor you've actually 'removed' the default one, thus the initializer was skipped altogether, as you've mentioned.
Therefore, the only way is to resolve the dependencies during the 'Initialize' method, after registering them on application startup.
ctx.RegisterType<MyService>().As<IService>().AsSelf(); // on application startup
ctx.Resolve<IService>(); // during initializer 'Initialize' method
You might look at the question I asked here
How to have "Request" events with authenticated user id ?
because I had managed to have the TelemetryInitializer working, passing user id via the HttpContext as suggested by #yonisha.
Off course it's not as lean as what you try to achieve.
The Telemetry Initializer is called each time you instanciate a Telemetry class, so really depending of how you manage them. Btw I am looking for good advice/best pratice on that : for the moment I have one private instance on each Controller that need to track something, but that does not smell good due to lifetime of Controller.
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 ...'.
It appears that Unity IoC defaults to creating a new instance of an object when it resolves a type. But my question is there someway to be explicit and tell my container that whenever I have it resolve an object type to give me a new instance of said type?
IE i want to be explicit and force the container to make sure theInstance is a new instance each time it resolves type:MyNewObject (or all types for that matter)
MyNewObject theInstance = container.Resolve<MyNewObject>();
Yes it is easily configurable by a TransientLifetimeManager
When you register a class should have something like
container.Register<IMyNewObject, MyMewObject>(new TransientLifetimeManager());
//or
container.Register<MyMewObject>(new TransientLifetimeManager())
If you're applying IoC principles properly, your class declares its dependencies and then the container handles the lifecycles of them. For example, you want to grab an HttpRequest object and the container handles providing the current thread-local one, or whatever.
Your code shouldn't really have to care about the life-cycle of its dependencies, as it should never be responsible for clearing up after them or what-have-you (all of that should be encapsulated in the dependency itself, and invoked by the container when it is shut down).
However, if you do need to care in your code about whether you get a singleton instance or a per-injected instance of the same type, I like to be explicit about it by using the type system itself, just as the Guice container for Java does with its Provider pattern. I've created a Guice-style IProvider<T> interface that I use to do this, and I just wire it up with a simple static factory method for them like so:
Provider.Of<Foo>(() => { /* Code to return a Foo goes here */})
I have tried to use struts 1.3 API to make a small application with EJB 3.0. Unfortunatelly i cannot use the #EJB annotation to call my bean object from inside my action class. I have solved this problem using different workarounds ( the first one is to use my global jndi name of my bean and the other is to call another class first and use the #EJB annotation from that class). Still these two workarounds have significant disadvantages. I would like to call my EJB directly from my action class. I have read plenty examples using the "java:comp/env/beanName" JNDI name but still haven't figure out how to do it and get name not found axception.
Let the full name of the local EJB class be the com.ejb.myEjbPackage.MyEJBLocal, how can i call it using the context lookup? (can i do it without modifying any of the web.xml and sun-web.xml descriptors?)
I am using glassfish server and Netbeans IDE.
Thank you in advance
#EJB won't work in a standard pojo it can only be done in a managed object (i.e. another session bean)
So...
Here's your bean
#Stateless(mappedName="beanName")
public class beanName implements beanNameRemote {
Here's your lookup
Context context = new InitialContext(); //default lookup pulls from jndi properties file
context.lookup("beanName");
You can do some further reading on the mappedName to see if you want to use it or not.
I found the answer :
If you cannot use the EJB annotation in the class you want to call the bean then :
If you don't want to mess with XML descriptors to define your bean , you have to do it in the bean class itself.
Hence i used the following annotation in the GameBean class
#Stateless
#EJB(name="ejb/GameBean",beanInterface=GameBeanLocal.class,beanName="GameBean")
public class GameBean implements GameBeanLocal {.....
The beanName is optional. The annotation must be declared in the line ABOVE the declaration of the class.
Then, in order to call the bean from the other class you can do
InitialContext ic = new InitialContext();
ic.lookup("java:comp/env/ejb/GameBean");