I've two bean definitions in my application-context.xml (BeanClassA, BeanClassB). If BeanClassA has an #Autowired annotation to BeanClassB, Should the BeanClassB be declared BEFORE BeanClassA in the bean definitions in application-context.xml? More generically is there an inherent order in which the beans would be loaded..
No. Unless you have some complex circular dependencies, Spring will be able to publish all injections before making any beans available to you. The order of declarations in XML is not important.
Related
I have a entity class called Customer, I am using this entity object in another class to set the data. When I use this object below like
#Autowired
Customer customer
Spring is complaining that please configure the bean in your classes.
Can we use auto wiring with entity objects?
You can only autowire only those beans whose life-cycle are managed by Spring IoC container.
These beans are defined in xml form with </bean> tag, or with some special annotations like #Bean, #Component, #Service, #Repository etc.
On the other hand,
in simple terms, entities are some java objects that you will need to create, update by yourself according to your business logic and save/update/remove them in/from DB. Their life-cycle cannot be managed by Spring IoC container.
So, you should never feel like you need to autowire an entity if you are doing it right!
In fact, Spring support #Autowire only for Spring Beans. A java class becomes Spring Bean only when it is created by Spring, otherwise it is not.
A workaround might be to annotate your class with #Configurable but you would have to use AspectJ
Please look in the Spring documentations on how to use #Configurable
Also, I wonder why you would autowire an entity class ?
I would warn you not to mix Spring Bean and JPA entities in one class/usecase because:
Spring Beans are instantiated and managed by Spring
Entities are managed by JPA provider
If you mean JPAs #Entity-annotation, Spring is simply telling you, that there isn't a bean in its context.
On startup/runtime classes in the application will be scanned and each class annotated with spring annotations like #Component, #Service etc. will be instantiated as beans and put into a global context (Spring applicationcontext).
This context is then used to lookup and inject those beans into other beans when #Autowired is found during scanning.
Opposed to this, #Entity is used during the creation of the Persistence-Context of JPA (as far as I remember) which isn't aware of Spring and it's context.
Most of the solutions to make both contexts aware of each other a mostly a little bit hacky.
Is there any annotation/trick in Spring that marks a #Configuration #Bean as injectable only on strictly qualified #Autowireds?
I'd like my bean to be qualified in a way that only those that specifically call for its #Qualifer can inject it. It's indeed a mechanism for controlling where is it going to be able to be autowired, with no ambiguity nor arbitrary decisions depending on available beans in the context.
So my bean would never be autowired as a side-effect out-of-my control without me actively marking the injecting as expecting it
You can control bean creation with #Conditional annotation.
Also if you need real control of using bean you can create some annotation like #ConroledByQualifer and use this annotation instead of standard spring component annotation , or extension for one (like service , repository .... ) .
So spring can't process it for autowired as one don't know how to handling it.
You need add custom BeanPostProcessor that will work with #ConroledByQualifer - create it and inject. So your custom bean will be processed only by BeanPostProcessor for #ConroledByQualifer and not custom spring BeanPostProcessors.
I have a custom annotation that is declared as a Spring managed Service:
#Service
public #interface MyServiceAnnotation {
// my service url
String url();
}
The above declaration enables my services to be autowired as Spring Managed beans.
#MyServiceAnnotation(url="/path/serviceLocation")
public class SomeService {
doWork();
}
However, there are certain services that have their bean definitions in an applicationContext.xml. Adding the #MyServiceAnnotation to such beans makes them both Autowiring enabled, as well as inject dependecy through the xml file.
Due to issues related to legacy code, I don't want to remove the xml bean definitions and make them all autowired.
So, is there a way in which I could turn off autowiring in this case, and still use #MyServiceAnnotation? Ideally I would like to have the #Service annotation on MyServiceAnnotation, the existing services would still use the #MyServiceAnnotation but would get their dependencies injected based on the xml. All the new services would be autowired without the xml bean definitions.
One possible approach is to create NonSpringManagedMyServiceAnnotation that is same as MyServiceAnnotation, but without the #Service annotation on it. The downside of this is that I'd have to duplicate rest of the code from MyServiceAnnotation, which I don't want to.
This is one approach, may not be that optimal though. I am assuming you would have specified a component-scan tag in your xml to scan the classes having the Spring stereotype annotations, these tags support a exclude-filter sub-tag to ignore specific patterns. If the files that you specify follow a specific pattern(specific packages, specific names etc) then you may simply be able to specify this sub-tag to ignore classes holding your annotation.
<context:component-scan base-package="mypackage">
<context:exclude-filter type="regex" expression=".*ToBeIgnoredNaming"/>
</context:component-scan>
I think you should try to maintain separation of concern.
Adding #Service on your annotation makes it a de facto Spring service : since this is not the behavior you want, you may simply have a simple #MyAnnotation (with url property) on each services (legacy and new).
Then you add Spring's #Service annotation on each new service to enable bean registration by annotation.
I have two beans, beanA and beanB, in my Spring config. Both of these beans implement the same interface. I have a class with an autowired field of the interface type (i.e. it will be populated with an instance of beanA or beanB).
Initially there was only one bean, so I simply used the #Autowired annotation and the field was populated. However, now there's two potential beans that could be autowired. I want to autowire the bean based on the existence of a property in one of my .properties resources. Is there any elegant way to do this?
The solution I'm using now is to use the #Qualifier annotation on the autowired field to specify beanA and then make a check to see if the property exists in code. If it does, I reassign the field to an instance of beanB. It's a very clunky way of doing it, so I'm looking for a better option.
Apart from the newer feature of bean profiles, you can also take advantage of FactoryBean which instantiate a bean at the time of access. The idea is to inject the FactoryBean with the bean types (e.g. fqcn.BeanA or fqcn.BeanB). Then factory bean will return the bean factory to instantiate the correct type of the bean that you may need. The configuration of FactoryBean then can take advantage of properties coming from a resource bundle.
Bean profiles could be great fit for this - based on the "active" profile let one or the other bean be created.
Somewhat of an older article, but is still a good reference to profiles in Spring 3.1- http://blog.springsource.com/2011/02/11/spring-framework-3-1-m1-released/
Spring Profile can help
Configuration Changes
web.xml
<context-param>
<param-name>spring.profiles.active</param-name>
<param-value>a</param-value>
</context-param>
spring-beans.xml with profiles. Profile value can behave as the
property value for decision making.
<bean id="A" profile="a"/>
<bean id="B" profile="b"/>
I am trying to understand the javax.inject package and I am not clear what the javax.inject.Named annotation is supposed to be used for. The Javadoc does not explain the the idea behind it.
Javadoc is at http://download.oracle.com/javaee/6/api/javax/inject/Named.html
I am using Spring 3.0 to write some sample programs, by putting #Named on a bean it seems to add it to the bean factory but the Javadoc description is so light I can't tell if that is the standard behavior or Spring specific behavior.
My questions are:
What is the difference between #Named and #Qualifier
How are you supposed to tell the Runtime system a class should be injectable in other classes what's the annotation for that? The equivalent of #Component in Spring?
Update 1 there is an excellent explanation of #Named and #Qualifier at Nice article about #Named and #Qualifier https://dzone.com/articles/java-ee6-cdi-named-components thanks #xmedeko for linking to it the comment below.
Use #Named to differentiate between different objects of the same type bound in the same scope.
#Named("maxWaitTime")
public long maxWaitTimeMs;
#Named("minWaitTime")
public long minWaitTimeMs;
Without the #Named qualifier, the injector would not know which long to bind to which variable.
If you want to create annotations that act like #Named, use the #Qualifier annotation when creating them.
If you look at #Named, it is itself annotated with #Qualifier.
#Inject instead of Spring’s #Autowired to inject a bean.
#Named instead of Spring’s #Component to declare a bean.
Those JSR-330 standard annotations are scanned and retrieved the same way as Spring annotation (as long as the following jar is in your classpath)
Regarding #2, according to the JSR-330 spec:
This package provides dependency
injection annotations that enable
portable classes, but it leaves
external dependency configuration up
to the injector implementation.
So it's up to the provider to determine which objects are available for injection. In the case of Spring it is all Spring beans. And any class annotated with JSR-330 annotations are automatically added as Spring beans when using an AnnotationConfigApplicationContext.
The primary role of the #Named annotation is to define a bean for the purpose of resolving EL statements within the application, usually through JSF EL resolvers. Injection can be performed using names but this was not how injection in CDI was meant to work since CDI gives us a much richer way to express injection points and the beans to be injected into them.