we recently converted our project from JBoss seam to using Spring and JSF. Our controller needs to initialize some properties. Right now were simply using the constructor to call the initialization methods. Seam has #Factory annotation decorated to a method which is called whenever the accessed property/field is null. Does Spring have an equivalent annotation? Thanks a lot.
No, but Spring supports the JSR-250 lifecycle annotations #PostConstruct / #PreDestroy, which you can use for housekeeping when your bean starts up.
In fact there are at least three mechanisms for bean lifecycle management, and their interaction and precedence is explained in the chapter "Combining lifecycle mechanisms"
Related
I am wondering how can I use the Instance in JUnit4 with Spring
#Inject
Instance<IMyInterface> interfaces;
If I use
#Inject
List<IMyInterface> interfaces;
It works in Spring but not with CDI.
Also, we can use Provider with both CDI and Spring but it's not Iterable.
The #Inject annotation comes from JSR-330-Dependency Injection for Java. Spring knows this annotation and briefly said, Spring treats it as an alternative to #Autowired. That's it.
However, the Instance is part of JSR 299 - Contexts & Dependency Injection. You can have a look at the definition in CDI specifications.
Spring DI is absolutely different and does not implement JSR-299 (CDI) or any other standard. It does not even have a separate API and implementations and everything is just glued together. Therefore, injecting an Instace is not possible with Spring.
I am coming at this question from many years of using spring and just starting to look at JEE7 and CDI.
In the Spring world you have to stick #Component on a bean to turn into spring bean that spring will inject with dependencies but in CDI it seems that there is no equivalent of #Component.
To me CDI seems to imply that every class in my web application will be considered a CDI bean which seems undesirable because I have lot of java classes that are not using injection and I would not want some one to just stick #Inject in those classes and have CDI do its magic.
Two questions:
How to restrict what CDI considers to be a managed bean in a jar file?
What is the benefit for CDI to consider every bean to be a managed bean?
Please see the documentation for bean-discovery-mode in beans.xml. This attribute was only made available in JEE7 and is not available in JEE6.
There are two separate annotations to perform dependency injection by name in Spring, javax.annotation.Resource and javax.inject.Named. The documentation at Spring indicates #Resource should be used for injection by name:
If you intend to express annotation-driven injection by name, do not
primarily use #Autowired, even if is technically capable of referring
to a bean name through #Qualifier values. Instead, use the JSR-250
#Resource annotation, which is semantically defined to identify a
specific target component by its unique name, with the declared type
being irrelevant for the matching process.
The above is a bit confusing, as Spring is only advocating #Resource instead of #Autowired combined with #Qualifer. There is no mention of #Named until later in the documentation.
JSR-250 defines #Resource, whereas JSR-330 defines #Inject and #Named. I know they can be mixed-and-matched within Spring fairly easily. Which JSR to use?
It seems like portability with Guice and CDI would be nice, and hence to use the JSR-330 annotations. On the other hand, the documentation also points out at a couple of limitations within Spring when using JSR-330 annotations.
What is the best practice (if there is one) for annotation injection-by-name?
Thank you.
#Resource is older and is supported since Spring 2.5 while #Named support has been added in Spring 3.0 and both of them can be used to achieve the same purpose of injection-by-name.
When using Spring, my concerns for preferring one over the other would be backward compatibility with Spring 2.5 and whether javax.inject can be added/assumed-to-be on the classpath or not.
I have an ApplicationContextProvider class, which can used to access Spring ApplicationContext from beans not managed by Spring. Something like mentioned here
For the spring managed beans however I can make them ApplicationContextAware, so they can get access to ApplicationContext.
My question is, is it a good idea to use the common ApplicationContextProvider to get spring application context from the spring-managed beans as well or should I continue to use ApplicationContextAware?
Using a singleton with static reference to application context is asking for trouble. It is almost never a good idea to use such utility class in any case. When dealing with legacy web application use WebApplicationContextUtils instead.
I once reinvented this solution in a project during migration from EJB 2.1 to Spring - but after migration we get rid of it and could sleep again.
Back to your question - using such utility for Spring managed beans has no sense at all. To be honest, I rarely need ApplicationContextAware interface as well. Spring is suppose to inject dependencies, you shouldn't ask Spring for them all the time!
Can you show us some use case when you need quoted utility class (both for managed- and umanaged beans)? Looks like you are refusing to accept support Spring gives you.
What is a bean in spring framework?
What is the use of the bean?
In the context of Spring, a bean is a managed object. What is a managed object? It's an object that Spring is aware of and that Spring knows how to manipulate, e.g. inject properties, invoke callback methods, etc.
There is then a difference between a regular java class (which Spring doesn't know about) and beans (which Spring knows about).
Generally Spring beans follow the Java bean convention, so that Spring can manipulate them easily. For instance if the bean is declared to have a property xxx, then Spring will expect getXxx and setXxx to be present. However, since Spring 2.X it is possible to dependency-inject private variables (using annotations), and therefore it is is no longer necessary to define a public setter in order to enable dependency injection for a property.
( The term bean is confusing in the sense that it is frequently uses to denote either (1) something that is managed by a container, like an enterprise java bean (EJB) or (2) something that adheres to the Java bean conventions. )
The Java Bean spec does spell out no-arg constructor, getters/setters, and serializable, but Spring does not require that your beans follow the spec. Spring deals with Plain Old Java Objects, whether they conform to the Java Bean spec or not.
What's the use of beans? They express your wishes in code. All Spring is doing is managing their lifecycle and wiring them together to accomplish your goals.
a bean is a POJO with setters and getters that follow the bean convention.
beans are used to pass around data, also jsps has special support for beans
A bean in Spring world is any object that is defined using Spring conventions using bean id or name. Its life time is managed by Spring container. The bean can be a POJO or a factory instance with static methods. It can even be a JNDI resource and not necessary a Java Bean. Bean managed by the Spring container can even be a proxy bean which may hide the bean (esp with TransactionProxyFactory).
In short, any bean whose lifetime is managed by Spring container is a Spring bean.
a bean is a class with a public standard constructor, getters/setters (properties) and it must be serializable. wikipedia has an explenation on this.
this way the spring framework knows how to create an instance of the bean (public standard constructor) and which properties exist (with reflection)