Should the JmsTemplate bean be declared as a prototype bean or as a singleton? I think either option is reasonable and it seems to me it's mainly a question of how Spring implemented that bean but I keep finding conflicting reports about the use over the net.
JMSTemplate like most of the spring templates is thread safe after creation so you should leave it at scope singleton.
If the runnable is implemented as a inner class it can access the instance variables of the class in which you define it. This can be a spring bean with all the required dependencies (jmsTemplate etc) injected into it.
Related
I am looking for a a way to do runtime injection of a bean in Quarkus. I realize this might be a bit on an unorthodox approach for quarkus, and something on an anti-pattern, so no need to point that out, I am fully aware :)
What I am looking for is a way to construct a bean during runtime, and having any annotated properties injected from the Quarkus context.
In Spring Boot I would get the application context by having a bean initialized normally by spring boot, using the ApplicationContextAware interface to inject the application context. I would then use that as a factory by calling ApplicationContext.getAutowireCapableBeanFactory() to get the auto-wire factory and using the autowireBean method on the factory to autowire my beans during runtime. I am wondering if something similar is possible in Quarkus?
This is similar to this question.
How to programmatically inject a Java CDI managed bean into a local variable in a (static) method
javax.enterprise.inject.spi.CDI.current().getBeanManager().select(C.class).get()
To make sure that the bean class is manged use the io.quarkus.arc.Unremovable annotation.
Here's the situation: I have a RestTemplate bean defined in my main application (Spring boot 2). This application uses a library that also defines a RestTemplate bean to handle requests. I want to keep the main application's RestTemplate definition for my code, but I don't want the library to use my bean definition, since it will create a weird behaviour.
Is there a way to do that without using #Qualifier everywhere? Perhaps something like scoping my bean to my code only?
Suppose I have classes, which were instantiated not by Spring. For example, they can be instantiated by deserializer or by JavaFX.
Can I code these classes in the same way I code Spring beans and inject properties into them later?
Actually, I would like a routine, which would scan class with reflection, find all #Autowired annotations in it and inject values from application context?
Will this happen, if I call applicationContext.getBeanFactory().registerSingleton("myName", myBean)? Note, that I would no limit myself with singletons.
If beans are not instantiated by Spring, then you cannot ask Spring to inject dependencies or advise them.
This is a common mistake I see Spring neophytes make. They call new to instantiate a bean with annotations and can't understand why their dependencies aren't injected.
Spring will handle all the beans you instantiate with the bean factory. You are on your own with all others created using new.
I am new to Spring MVC and have a little idea of the usage of java beans in Java.
What is the basic difference between a Java bean and Spring bean?
JavaBeans:
At a basic level, JavaBeans are simply Java classes which adhere to certain coding conventions. Specifically, classes that
have public default (no argument) constructors
allow access to their properties using accessor (getter and setter) methods
implement java.io.Serializable
Spring Beans:
A Spring bean is basically an object managed by Spring. More specifically, it is an object that is instantiated, configured and otherwise managed by a Spring Framework container. Spring beans are defined in Spring configuration files (or, more recently, with annotations), instantiated by Spring containers, and then injected into applications.
Note that Spring beans need not always be JavaBeans. Spring beans might not implement the java.io.Serializable interface, can have arguments in their constructors, etc.
This is the very basic difference between JavaBeans and Spring beans.
For more information, refer to the source of the above text, Shaun Abram's article JavaBeans vs Spring beans vs POJOs.
Java bean is a class that should follow following conventions:
1.Must implement Serializable.
2.It should have a public no-arg constructor.
3.All properties in java bean must be private with public getters and setter methods.
Spring beans are the objects that form the backbone of your application and are managed by the Spring IoC container .
Spring Bean:
A class which is developed as part of a spring application. Its life cycle which is managed by Spring Container is called as Spring Bean.
Java beans and Spring beans are more related than different.
For a Java class to be usable as a Java bean, its setter- and getter-method names need to be as per the JavaBean guidelines (also called design patterns) for properties. If such a Java class is instantiable & manageable by the Spring IoC container, it is a Spring bean. To achieve this, the programmer wires the class as a bean definition of a suitable scope by using XML config files or annotations or a mix of both. The programmer can create new Spring beans out of existing Spring beans by wiring further by passing the latter to constructor-arguments of the former either as string-names as <idref> elements or by dependency injection (it can be recursive).
This answer may be read in conjunction with my this SO answer to get more background information.
I am newbie in CDI and I want to instantiate CDI bean via my XML files, but not via beans.xml. Is it possible and is it normal? Or maybe I misunderstand CDI concepts?
I found the answer.
A producer method is a method that acts as a source of bean instances.
The method declaration itself describes the bean and the container
invokes the method to obtain an instance of the bean when no instance
exists in the specified context. A producer method lets the
application take full control of the bean instantiation process.