I have a service interface I with implementaions I1,I2,I3...I10 out of which I want to use I1-I5 to be autowired as a List<I> in controller class C. The I6-I10 should not be be autowired. How can I achieve this. Moreover the I implementations are annotated #Service beans. I do not want to move them to xml declarations.
Based on the comment by mvb13 I have tried to weave a solution for the problem....
So I write a class extending ArrayList and mark it a Component
#Component("mysublist")
public class MyList extends ArrayList implements ApplicationContextAware
{
#Value("comma.sep.eligible.beans.classnames")
private String eligibles;
private ApplicationContext appCtx;
#PostConstruct
public void init()
{
Map allBeans = appCtx.getBeansOfType(I.class);
for(Object bean:allBeans.values())
{
if(eligibles.contains(bean.getClass().getSimpleName()))
{
add(bean);
}
}
}
public void setApplicationContext(ApplicationContext appCtx)
{
this.appCtx = appCtx;
}
}
Now I can autowire the above bean in my required class definition as:
#Service
public class MyService
{
#Resource(name="mysublist")
private List<I> myReqdBeans;
......
}
*Please ignore the generics related implications in the code.
You should use #Qualifier. It defines any subset that you need.
#Autowired
#Qualifier("MySubset")
private List<I> list;
But I think you should move your bean definitions in xml to use <qualifier ... /> property. I think you haven't another option to specify qualifier.
The #Qualifier annotation should give you what you need. You need to apply it in two places:
On the #Service beans that you wish to include in the sub-list
On the #Autowired list injected into your controller
So addressing the #Service beans first:
#Service
#Qualifier("MySubList")
public class MyService implements IMyService
{
}
And then within your Controller:
#Controller
public class MyController
{
#Qualifier("MySubList")
#AutoWired
private List<IMyService> myServices;
}
This instructs Spring to #AutoWire all IMyService implementations #Qualified as "MySubList"
Related
My use case is running custom code before a controller method by annotating methods.
HandlerInterceptor seems the way to go but it seems impossible to inject dependencies into it because it needs to be registered before the context is being created.
All examples I've found so far use empty constructors (see spring boot adding http request interceptors) or autowire properties in the configuration which fails because I declare dependent beans in the same configuration (Requested bean is currently in creation: Is there an unresolvable circular reference?).
Is there a better way that does not involve AOP?
Assume that your interceptor has constructor dependencies like that:
public class CustomInterceptor extends HandlerInterceptor {
private final DependentBean bean;
public CustomInterceptor(DependentBean bean) {
this.bean = bean;
}
}
Then you can register your handler like that:
#Configuration
public WebConfig extends WebMvcConfigurerAdapater {
#Bean
public DependentBean dependentBean() {
return new DependentBean();
}
#Bean
public CustomInterceptor customInterceptor() {
return new CustomInterceptor(dependentBean());
}
#Override
public void addInterceptors(InterceptorRegistry registry) {
registry.addInterceptor(customInterceptor());
}
}
#Configuration will ensure each Bean method call return the same bean instance
Building on the answer above from Mạnh, if using component scan for dependency injection of the dependency, then that can be Autowired in the WebConfig
#Configuration
public WebConfig extends WebMvcConfigurerAdapater {
#Autowired
DependentBean dependentBean;
#Bean
public CustomInterceptor customInterceptor() {
return new CustomInterceptor(dependentBean);
}
#Override
public void addInterceptors(InterceptorRegistry registry) {
registry.addInterceptor(customInterceptor());
}
}
Also building on previous answers, and if you use Lombok, you can further simplify.
Have your interceptor implementation been a #Component
Add a private final DependentBean field to it.
Also add a #RequiredArgsConstructor annotation to it, to have Lombok generating a constructor with a single DependentBean parameter.
In your WebConfig, use the same technic to have a private final CustomInterceptor field been injected by Spring IOC.
This way the CustomInterceptor instance will be available & initialized the right way when addInterceptors will be called
Here are the corresponding code samples :
The CustomInterceptor :
#Component
#RequiredArgsConstructor
public class CustomInterceptor implements HandlerInterceptor {
private final DependentBean dependentBean;
#Override
public boolean preHandle( final HttpServletRequest request,
final HttpServletResponse response,
final Object handler ) throws Exception {
// your Interceptor Implementation goes here ...
}
}
The WebConfig :
#Configuration
#RequiredArgsConstructor
public class WebConfig implements WebMvcConfigurer {
private final CustomInterceptor customInterceptor;
#Override
public void addInterceptors( final InterceptorRegistry registry ) {
registry.addInterceptor( customInterceptor );
}
}
I have problems autowiring beans which are derived from interfaces with annotations.
#Component
#EnableAsync
public interface Calculator {
#Async
public Future<String> calculate();
}
public interface SpecificCalculator extends Calculator {
}
public class ConcreteSpecificCalculator implements SpecificCalculator {
#Override
public Future<String> calculate() {
// do calculation here
return new AsyncResult<String>("hello");
}
}
From what I understood from: Annotations on Interfaces? the #Component Annotation should also apply to all subclasses. Now I have a Mapper class returning all types that are derived from SpecificCalculator.
#Component
public class CalculatorMapper {
#Autowired
private List<SpecificCalculator> specificCalculators;
public List<Calculator> retrieveCalculatorsByModuleId(Integer moduleId) {
if(moduleId==...){
return specificCalculators;
}else{
...
}
}
This is not working. Spring does not find the ConcreteSpecificCalculator and is not injecting it. If I Annotate ConcreteSpecificCalculator with #Component again, it is working. Can anybody explain this to me?
Can Spring MVC bind HTTP headers to Java classes?
I've got three headers, and I'd like to marshall them into a POJO, much like you'd do with a form or a request body.
I can see two ways that you could achieve this with Spring and request or prototype scoped beans.
It is worth first being clear on the different scopes of beans and how Spring creates proxies for different scopes if you are not already.
The first method uses Spring Expression Language to directly reference the current HttpServletRequest instance.
#Component
#Scope(value = WebApplicationContext.SCOPE_REQUEST, proxyMode = ScopedProxyMode.TARGET_CLASS)
public class MyClass
{
#Value({#request.getHeader('headerName')})
private String myHeaderValue;
public String getMyHeaderValue()
{
return myHeaderValue;
}
}
An alternative is to simply inject the current HttpServletRequest as a constructor parameter:
#Component
#Scope(value = WebApplicationContext.SCOPE_REQUEST, proxyMode = ScopedProxyMode.TARGET_CLASS)
public class MyClass
{
private String myHeaderValue;
#Autowired
public MyClass(HttpServletRequest httpServletRequest)
{
this.myHeaderValue = httpServletRequest.getHeader("headerValue");
}
public String getMyHeaderValue()
{
return this.myHeaderValue;
}
}
You can then inject this bean into your Controller or Service beans as needed:
#Controller
public class MyController
{
#Autowired
private MyClass myClass;
}
Either method should let you achieve what you want, you can pick which best suits your requirements and preferences.
I have a stateful session bean where a list is maintained:
#Stateful
public class CartDAO{
private List<ShoppingCart> tempCart;
public void add(ShoppingCart shoppingCart){
tempCart.add(shoppingCart);
}
public List<ShoppingCart> getCart(){
return tempCart;
}
#PostConstruct
public void init(){
tempCart = new ArrayList<>();
}
}
Controller1 to add to the cart:
#Named
#SessionScoped
public class Controller1 implements Serializable {
#EJB
CartDAO cartDao;
public String addToShoppingCart() {
cartDao.add(shoppingCart);
}
}
Now, i want to ask you could i get the added items to the list from another cart?
#Named
#SessionScoped
public class Controller2 implements Serializable {
#EJB
CartDAO cartDao;
public String getShoppingCart() {
System.out.println(cartDao.getCart());//returns null
}
}
Obviously the above code returns null.
How do I retrieve the list from another controller. Any help will be much appreciated.
I don't see any obvious mistake here (are you sure that you don't call Controller2#getShoppingCart() before adding any items do your CartDAO?) but here are couple of my notions
you should have your CartDAO implement some interface or make it #LocalBean
all stateful beans should have method annotated with #Remove so you can clean the resources used in the bean (close datasources and son) and bean will be removed from the memory after this call
now it's recommended to use #Inject everywhere instead of #EJB, it's the same (you have to use #EJB only when you inject remote beans)
And also one point, if the System.out.println(cartDao.getCart()); returns null than it means the #PostConstruct haven't been called which is strange. Can you provide some more info about container and your environment?Also show us imports, this is big source of mistakes.
So far, I almost always worked with no-interface EJBs and have a slight understanding about the need of #Local annotation. Consider this example:
public interface MyBeanIntf { void doStuff(); }
#Stateless
public class MyBean implements MyBeanIntf { public void doStuff(){ } }
Should the MyBeanIntf be marked as #Local? I don't see any benefit from that, because even when I don't annotate it as #Local, I still can use DI to properly inject it into UI Controller:
#Named
#SessionScoped
public class TestController implements Serializable {
// injection works perfectly, even when MyBeanIntf is not marked as #Local
#Inject
private MyBeanIntf myBean;
// or even like this:
// #EJB
// private MyBeanIntf myBean;
}
Let's make it more complex:
public interface MyBeanIntf { void doStuff(); }
public class MySuperBean implements MyBeanIntf { public void doStuff() { } }
#Stateless
public class MyBean extends MySuperBean { }
Is MyBean now considered a valid Local EJB bean? I have some doubts because it implements the interface indirectly.
If your EJB implements some interface but you don't specify (neither on the EJB nor the interface itself) which interface it is (#Remote, #Local) than it's assumed that it's a #Local one.
Therefore your code:
public interface MyBeanIntf { void doStuff(); }
#Stateless
public class MyBean implements MyBeanIntf { public void doStuff(){ } }
is semantically identical to the following:
#Local
public interface MyBeanIntf { void doStuff(); }
#Stateless
public class MyBean implements MyBeanIntf { public void doStuff(){ } }
When it comes to the second part of your question, I think that section 4.9.2.1 Session Bean Superclasses from EJB 3.1 FR spec would be interesting for you. From my understanding (so it might not be correct), it seems that your bean should not be considered as exposing a valid Local interface because of the following excerpt:
#Stateless
public class A implements Foo { ... }
#Stateless
public class B extends A implements Bar { ... }
Assuming Foo and Bar are local business interfaces and there is no
associated deployment descriptor, session bean A exposes local
business interface Foo and session bean B exposes local business
interface Bar, but not Foo.
Session bean B would need to explicitly include Foo in its set of
exposed views for that interface to apply.
Update:
As an addition one more excerpt from the spec:
A session bean class is permitted to have superclasses that are
themselves session bean classes. However, there are no special rules
that apply to the processing of annotations or the deployment
descriptor for this case. For the purposes of processing a particular
session bean class, all superclass processing is identical regardless
of whether the superclasses are themselves session bean classes.