I have obtained a CDI bean which was obtained programatically using the following code:
MyBean bean = CDI.current().select(MyBean.class, qualifier).get();
Once I am done, do I need to destroy this bean using
CDI.current().destroy (bean);
Or does the bean inherit the scope from my class?
Or does the bean inherit the scope from my class?
Definitely no. It will have whatever scope you gave to MyBean.
do I need to destroy this bean
If your bean is normal scoped you don't need to do that. If, however, it is so called pseudo-scope, you might need to destroy it.
For the record, normal scoped are all basic CDI scopes except for #Dependent.
The reason is that #Dependent lifecycle (so destroy as well) is bound to a bean where you inject it. But you didn't really inject it, instead you did programmatic lookup. Therefore, it isn't bound to any other bean and you should destroy it.
Related
Does Weld have any kind of scope like prototype in Spring? Weld has qualified #New but it is a little bit different.
What I want to do is following:
I have bean with application scope. In this bean I need to have reference to bean with scope similar to prototype. I know I know in Spring it is possible to implement with lookup methods.
Unfortunately I could not found prototype scope and lookup method in Weld. Does Weld have anything similar?
I'm not too familiar with Spring but, from a quick read of the docs, I think what you want are #Dependant beans.
With the #Dependant pseudo-scope, a new bean instance is created every time it's injected.
In your case your application scoped bean would have an instance injected into it when it's created, and that instance won't be injected anywhere else.
If another application scoped bean injected the same class, it would get a different instance.
If a request scoped bean injected the same class, then each instance of the request scoped bean would get it's own instance of your injected bean.
Does that sound like what you're looking for?
Okie is have some third party code running on Spring 3.1.4 and I cannot change that. Also the code uses lookup-method to inject a type dynamically at runtime. This type is of a prototype scope. All is standard Spring usage of lookup-method based service object creation.
Problem is that on 3.1.4 there is a lot of blocking on DefaultSingletonBeanRegistry because of the synchronized block there in getSingleton method. The thread dumps show that the execution path reaches there when a lookup-method based inject is required and get stuck there till they get the time to run through.
I was wondering if I can use a factory-bean to create those prototype beans instead of defining them as a prototype bean itself. Inside the factory-method of the factory bean i would use the new constructor_call() based approach to instantiate the value beans. And also keep the bean id of the factory-bean same as the prototype bean in the third party cpring configuration XML.
would this approach work?
And also keep the bean id of the factory-bean same as the prototype
bean in the third party cpring configuration XML.
I don't think this would work. If you have two beans with the same name (the one you define plus the one presumably defined in the 3rd party's config) you'll get an exception.
However, I think you could use a BeanDefinitionRegistryPostProcessor to remove the prototype scoped bean and replace it with a bean of your own design.
Is a prototype bean created faster by the spring container than a singleton bean? How much if yes?
Maybe some background for the question. Assume that we have the context definition which contains a lot of bean definitions. And the application is a 'short running task' I wonder if I can speed up creation of the context by defining all beans as prototypes - because in this case it doesn't matter if they are singletons or not.
The two approaches are completely different in the amount of beans created.
When the bean has a scope="prototype" this means a new bean instance will be created everytime you ask for a bean with the corresponding id.
When the bean doesn't have a scope attribute set, this means a single instance will be created when the context is loaded for the first time and will be shared.
I believe the time consumed for creation of prototype and singleton beans is (if not the same) very close.
I have a simple question for you experts
Is it possible to have both a Session-Scoped and Request-Scoped for the same bean?
For example, i have a bean myBean, can it be both Session-Scoped and Request-Scoped?
EDIT
After doing some trials, i decided to destroy the first session which is session scoped.
FacesContext.getCurrentInstance().getExternalContext().getSessionMap().remove("SessionBean1");
is there a way i can re-initialise it to a request scoped one?
It is possible to define a bean of the same type in two different scopes by defining it in a faces-config.xml file. This will result in two different instances when referenced through expressions like #{sessionScope.myBean}, #{requestScope.myBean}, etc.
It is possible to place the same bean instance into more than one scope programmatically using the FacesContext.
However, the presence of such beans suggests a design flaw.
You can annotate a managed bean with more than one scope. The code will compile and deploy without errors (tested with Mojarra 2.1.3 / Glassfish 3.1.1).
However, the effect will be that always the most narrow scope will be applied. So if you annotate your bean with #SessionScoped and #RequestScoped, the bean will be in request scope.
I'm wondering how one can do that. Afaik there is BeanFactoryPostProcessor interface that let us use BeanDefinitionRegistry.registerBeanDefinition() method before beans within context are initialized. That method accepts only a class / definition. But usually one needs to register a bean that is already set with properties. Otherwise the bean definition registration itself is kinda useless. I don't want to set it up additionally after I get it from context then.
When using singleton it's ok, but for prototypes I'd have to set the bean up for each getBean() .
It turned out that the most preferable way of doing that was GenericBeanDefinition and GenericBeanDefinition.setPropertyValues(MutablePropertyValues propertyValues) and it's registering into an application context...