I came across this link which explains how a bean can be inherited. Assuming that HelloWorld class in this example is exposed as a bean using #Component annotation , how can create another bean which inherits this bean? Can I use extends to inherit HelloWorld bean and add #Component to the new class in order to extend the existing bean expose it as a new bean with additional features?
First you make your abstract configuration, which is achieved by not marking it as #Configuration, like this:
// notice there is no annotation here
public class ParentConfig {
#Bean
public ParentBean parentBean() {
return new ParentBean();
}
}
An then you extend it, like this:
#Configuration
public class ChildConfig extends ParentConfig {
#Bean
public ChildBean childBean() {
return new ChildBean();
}
}
The result will be exactly the same as if you did this:
#Configuration
public class FullConfig {
#Bean
public ParentBean parentBean() {
return new ParentBean();
}
#Bean
public ChildBean childBean() {
return new ChildBean();
}
}
Edit: answer to the follow-up question in the comment.
If Spring picks up both classes, parent and child, there will be problems with duplicated beans, so you cannot extend it directly. Even if you override methods, the beans from the super-class will also be instantiated by the ParentConfig.
Since your parent class is already compiled, you have 2 options:
Talk to the author of the parent class and kindly ask him to change it.
Change the #ComponentScan packages.
To clarify on solution 2:
If the parent class is in the package com.parent.ParentConfig and the child class is the package com.child.ChildConfig, you can configure the component scanning so that only classes under com.child get picked up.
You can specify the component scanning packages using the #ComponentScan("com.child") annotation on your main configuration file (think application class).
Related
I am trying to use a specialized subclass in a Spring web application for testing.
The application context xml files reference a class in a few bean's properties by the fully qualified class name, like this:
<bean id="blahblah" class="x.y.z.Blah">
<property name="myFooAttribute" ref="x.y.z.Foo"/>
</bean>
and I would like to instantiate and use x.y.z.Bar instead of x.y.z.Foo, everywhere it is used.
In my test I am using a Java based config and importing the XML configuration (legacy stuff that I don't really want to mess too much around) since it feels more natural when I'm going to be patching things and using mocks declared inline.
#Configuration
#ImportResource({
"classpath:applicationContext-common.xml",
"classpath:app-servlet.xml"
})
static class TestConfig {
static class Bar extends Foo {
//some stuff overridden here
}
}
How can I make all the places that reference to x.y.z.Foo use my Bar class instead? Preferably without changing the xml files...
Creating a bean named as the class that you are trying to override works. It can be achieved in the Java style configuration using the Bean annotation.
#Configuration
#ImportResource({
"classpath:applicationContext-common.xml",
"classpath:app-servlet.xml"
})
static class TestConfig {
static class Bar extends Foo {
//some stuff overridden here
}
private Bar myTestBar = new Bar();
#Bean(name="x.y.z.Foo")
public Foo getFoo() {
return myTestBar;
}
}
I am trying to inject specific Generic bean to Generic subtype, but Spring is unable to resolve dependency. By removing type from the bean, everything works as expected. Here is an example:
public class AbstractFrom{
// ...
}
public class EmployyForm extends AbstractFrom{
// ...
}
public class CompanyForm extends AbstractFrom{
// ...
}
abstract class AbstractBean<T extends AbstractFrom>{
public abstract void calculate(T form);
}
#Component
public CompanyBean extends AbstractBean<CompanyForm>{
public void calculate(CompanyForm form){
// specific impl
}
}
#Component
public EmployeeBean extends AbstractBean<EmployyForm>{
public void calculate(EmployyForm form){
// specific impl
}
}
Here is a target class:
#Service
public BaseService{
#Autowire
public AbstractBean<AbstractFrom> baseBean; // <- NoSuchBeanDefinitionException
// #Autowire
// public AbstractBean baseBean; <- Injection works as is expected
}
Depends of active profile is initialized only CompanyBean or EmployeeBean, never both. I've also tried set the same name given beans and us #Qualifier annotation.
Does exist any way how inject this bean using diamond syntax? Does Spring is able to resolve given dependency? Using Spring 4.2.x.
Edit:
With Spring 4.3 is should be possible. See Juergen Hoeller's talk
I know you are probably not going to like this, but why not separate out the EmployeeForm and the CompanyForm to 2 separate base forms, and then in the BaseService make TWO entires, for the Autowire.
This is not a Spring answer per se, but that is what I would do, as a quick work around to see if it would work.
Separating them is not a terrible design compromise.
I'm just learning spring, and something struck me as very odd about the annotation configurations using the name attribute as a string.
#Bean(name = "com.my.injected.Service")
public InjectedService injectedService() {
return injectedService;
}
Is this name similar to the Spring Bean XML configuration id and class attributes?
<bean id="..." class="...">
<!-- collaborators and configuration for this bean go here -->
</bean>
Why isn't this simply
#Bean(clazz = com.my.injected.Service.class)
public InjectedService injectedService() {
return injectedService;
}
instead?
You're fully qualifying the path in both cases and actually using the class makes it way easier for your IDE to tell you when you've screwed it up. I understand that the XML configuration came first, and naturally it was always looking up things by string, so is this just a holdover? Is there some advantage to using strings or major disadvantage to using .class?
Question was originally based on a false premise. I edited it to spell out what this premise was and make it less confusing for new people who come along. Hopefully I did this such that the given answers are still exactly applicable; apologies if not.
#Bean annotation is meant to provide a spring bean. The type of the bean to provide will be the same type of the class/interface you define in the return method. So, instead of declaring to return a concrete class in the method, return the top (abstract) class/interface instead.
Imagine this case:
public interface MyEntityDao {
MyEntity get(String id);
}
#Repository
public class MyEntityDaoDatabaseImpl implements MyEntityDao {
#Override
public MyEntity get(String id) {
/* implementation that goes to database every time */
}
}
#Repository
public class MyEntityDaoCacheImpl implements MyEntityDao {
#Override
public MyEntity get(String id) {
/* implementation that looks the data
up in cache, never in database */
}
}
#Configuration
public class MyAppConfiguration {
#Bean
public MyEntityDaoDatabaseImpl method1() {
return new MyEntityDaoDatabaseImpl();
}
#Bean
public MyEntityDaoCacheImpl method2() {
return new MyEntityDaoCacheImpl();
}
}
#Service
public class MyEntityService {
#Autowired //what to inject here?
MyEntityDao dao;
}
In case above, there are two implementations of the proposed interface. How the framework may be able to understand which implementation to use except for the name?
#Service
public class MyEntityService {
#Autowired
#Qualifier("properBeanNameToInject")
MyEntityDao dao;
}
Bean name is not necessarily related to its class or even any of interfaces it implements. It is a name and nothing more. When you use the annotation configuration, Spring figures out what the exact class or interface the #Bean provides like the rest of java code would: either through the fully qualified name in the code or through the imports specified in the file. In your case, you presumably have an import com.my.injected.Service; statement at the top of the java file.
Your example is using the fully qualified class name as the bean name. It is your choice. You could use any other identifier. Using the fully qualified name could be useful if your code is providing an object that is named exactly like another 3rd party #Bean object that your code must include or consume. However, you could just as easily use name = "myService".
The bean name helps Spring (and application programmer) to distinguish between multiple instances of of the same bean class because you can deploy the same class as bean several times. If only one instance of bean type appear you event do not have to give it name manually: spring does this by default.
If you have several beans that have the same type or implement the same interface and you want to refer specific bean use #Qualifier annotation.
Suppose you have one interface
public interface A {
public void doSomething();
}
and two implementation classes
#Component(value="aImpl1")
public class AImpl1 implements A {
}
#Component(value="aImpl2")
public class AImpl2 implements A{
}
And finally a class that will use an "A" implementation:
#Component
public class MyClass {
#Autowire
A a;
}
Now if I want to inject AImpl1 I add the #Qualifier("aImpl1") while if I want to inject AImpl2 I add #Qualifier("aImpl2")
The question is: Is it possible to instruct spring somehow to look up all implementations of "A" in this case AImpl1 and AImpl2 and use some application specific conventions to choose the most appropriate implementation? for example in this case my convention could be use the implementation with the greatest suffix (i.e. AImpl2)?
EDIT: the class MyClass should not be aware at all about the implementation lookup logic, it should just find its property "a" set with an object of AImpl2.
You can inject all implentations as List:
#Autowired
List<A> as;
or as Map with bean name as key:
#Autowired
Map<String, A> as;
and then choose proper implementation manually (perhaps, in a setter method):
#Autowired
public void setAs(Map<String, A> as) {
this.a = ...;
}
Assuming you already have hundreds of interfaces and implementations (as you said in a comment), and you do not want to refactor all the code... then is a tricky problem... and this is a tricky solution:
You could create a custom BeanDefinitionRegistryPostProcessor and implement either the method postProcessBeanDefinitionRegistry or postProcessBeanFactory.
This way you have access to all bean definitions before they are instantiated and injected. Do your logic to find which is the preferred implementation for each one of your interfaces, and then, set that one as primary.
#Component
public class CustomBeanDefinitionRegistryPostProcessor implements BeanDefinitionRegistryPostProcessor {
#Override
public void postProcessBeanDefinitionRegistry(
BeanDefinitionRegistry registry) throws BeansException {
// this method can be used to set a primary bean, although
// beans defined in a #Configuration class will not be avalable here.
}
#Override
public void postProcessBeanFactory(
ConfigurableListableBeanFactory beanFactory) throws BeansException {
// here, all beans are available including those defined by #configuration, #component, xml, etc.
// do some magic to somehow find which is the preferred bean name for each interface
// you have access to all bean-definition names with: beanFactory.getBeanDefinitionNames()
String beanName = "aImpl2"; // let's say is this one
// get the definition for that bean and set it as primary
beanFactory.getBeanDefinition(beanName).setPrimary(true)
}
}
The hard part is to find the bean name, it depends of the specifics of your application. I guess that having a consistent naming convention will help.
Update:
It seems that both methods in the interface BeanDefinitionRegistryPostProcessor can be used for this purpose. Having in mind that in the postProcessBeanDefinitionRegistry phase, beans configured through #configuration classes are not yet available, as noted in the comments below.
On the other hand they are indeed available in postProcessBeanFactory.
If you have a Configuration class you could use a method in that to make the decision of which implementation of A to return. Then the autowired will inject the appropriate instance for that class.
#Configuration
public class ApplicationConfiguration {
#Bean
A getA() {
// instantiate the implementation of A that you would like to have injected
// or you could use reflection to find the correct class from the classpath.
// return the instance
}
}
This assumes you always want to use the same instance everywhere you are injecting A. If not, then you could have different #Bean annotated methods with names to get different versions.
You can try to use Spring Profiles.
I've a problem with spring. I'm replacing the xml file based configuration of spring with annotation based configuration. Because of that I runned into the following problem. Theres is a class, where one field is configured by class based autowiring. Since yet, there has been only one candidate. But now there is more then one candidate, because I've added the #Named tag to mutliple classes of the same interface.
Here is a code example:
The class with the autowiring field:
public class AutowiringClass<X, Y> {
// This is the field which is autowired
private Autowired<X, Y> bean;
.....
}
Then there is a second class, which extends AutoWiringClass with specific generic arguments:
public class TestClass extends AutoWiringClass<ObjectX, ObjectY> {
.....
}
The Problem is, that spring doesn't know which class it should use, since there are more than once class of the type Autowiring but with different generic types (ObjectX, ObjectY). I thought, that the different generic types will do the thing.. but they doesn't :(
It would be awesome if anybody has an solution for that.
Qualifiers are what you are looking for. When you register a class as a Spring bean (using #Component or the like) you can pass a name as an argument. Then when you are autowiring a property, add a #Qualifier annotation with that bean's name. So:
#Component("Test1")
public class Test { }
#Component("Test2")
public class BetterTest extends Test {}
public class TestUser {
#Autowired
#Qualifier("Test1")
private Test test;
}
Generics won't help you due to type erasure, Spring can't do nothing about it. But you can either use #Primary annotation to denote the default implementation that should be always used or switch to autowiring by name rather than by type. Then Spring will use field name when in doubt.