Spring 3 - Dynamic Autowiring at runtime based on another object attribute

Question

I am working on a Spring 3.1 MVC application and for one of my scenarios, I had to write two implementations of a DAO. I would like to know how to autowire this in a service layer based on another object's attribute.

For example,

    class Vehicle {
        private name;
        private type;
        ..
        ..
        ..
    } 

    @Service
    class VehicleServiceImpl implements VehicleService {

            // There are two implementations to this DAO
            // if Vehicle.type == "CAR", inject CarDAO
            // if Vehicle.type == "TRAIN", inject TrainDAO 
            @Autowired
            private VehicleDAO vehicleDAO ;

    }

    @Repository
    class CarDAO implements VehicleDAO {

    }

    @Repository
    class TrainDAO implements VehicleDAO {

    }

If my Vehicle is a Car, I need to autowire CarDAO and if it's a train, I need to autowire TrainDAO

What is the best way to implement this in spring 3.1.

I was hoping to use either context property place holders or @Qualifier annotation but both these are kind of restricted to lookup based on some property. I am not sure how to do this at runtime based on the property of another object.

I think you need to implement a factory provider, which will give you the correct instance of DAO based on the type of the vehicle — Arun P Johny, Mar 08 '13 at 00:57
Vehicle is available in @Model. I am assuming it can be used to construct the Service — aprajitha, Mar 08 '13 at 01:10
no, if it is a Model, then it is a runtime value and it has to be passed as a method argument, so you won't be able to use it for autowiring the values. — Arun P Johny, Mar 08 '13 at 01:21

Felix Ebert · Accepted Answer · 2013-03-08T04:00:00.230

My solution would be as follows:

a method isResponsibleFor in the VehicleDao interface:

interface VehicleDao {
    public boolean isResponsibleFor(Vehicle vehicle);
}

example implementation:

@Repository
class CarDAO implements VehicleDAO {
    public boolean isResponsibleFor(Vehicle vehicle) {
        return "CAR".equals(vehicle.getType());
    }
}

then autowire a list of all VehicleDao-implementations in the VehicleService:

public class VehicleServiceImpl implements VehicleService {

    @Autowired
    private List<VehicleDao> vehicleDaos;

    private VehicleDao daoForVehicle(Vehicle vehicle) {
         foreach(VehicleDao vehicleDao : vehicleDaos) {
              if(vehicleDao.isResponsibleFor(vehicle) {
                   return vehicleDao;
              }
         }

         throw new UnsupportedOperationException("unsupported vehicleType");
    }

    @Transactional
    public void save(Vehicle vehicle) {
         daoForVehicle(vehicle).save(vehicle);
    }
}

This has the advantage that you don't need to modify the service when you are adding a new vehicleType at a later time - you just need to add a new VehicleDao-implementation.

Clean solution from my point of view. This is the approach we took also. Just in the 'isResponsible' method do not use string but class comparison. You can even have a fallback implementation if you use one autowired field with a concrete implementation instead of throwing an exception. — Martin Frey, Mar 08 '13 at 06:03
Thanks @Felix. I was not aware we could wire a list of beans of a particular type — aprajitha, Mar 08 '13 at 06:23

score 18 · Answer 2 · edited Nov 30 '15 at 11:00

18

There is an cleaner option to accomplish this strategy. We know Spring is smart enough to inject where it sees a bean that it has control over, so when it sees your VehicleDAO with an @Autowire or @Resource annotation, it will correctly inject that concrete implementation.

Keeping that in mind, this will work anywhere you ask Spring to perform dependency injection, using a Map<> or a List<> for instance.

// Injects the map will all VehicleDAO implementations where key = the
// concrete implementation (The default name is the class name, otherwise you 
// can specify the name explicitly).
@Autowired
private Map<String, VehicleDAO> vehicleDAO;

// When you want to use a specific implementaion of VehicleDAO, just call the  
// 'get()' method on the map as in:
...
vehicleDAO.get("carDAO").yourMethod();
...

edited Nov 30 '15 at 11:00

potame

7,597
4
26
33

answered Feb 11 '15 at 14:17

Prancer

3,336
2
32
38

Nice. I never knew that despite years of Autowiring. Also see: http://docs.spring.io/spring/docs/3.2.x/spring-framework-reference/html/beans.html#beans-autowired-annotation – David Victor May 19 '15 at 12:45
Fantastic suggestion. How would we test the Map injection though, using a Junit Test class – phoenixSid Nov 02 '17 at 15:00
This is perfect answer – Jay Yadav Nov 03 '22 at 12:58

Arun P Johny · Answer 3 · 2013-03-08T02:36:10.543

Since Vehicle is a @Model it is a runtime value, you won't be able to use it for autowiring values.

The vehicle has to be passed to the service methods as an argument.

public interface VehicleService { void doSomething(Vehicle vehicle); }

Assuming both CarDao and TrainDAO are implementing the same VehicleDao Service, other wise it won't make much sense.

So in your VehicleServiceImpl I would recommend you to write a method like getVehicleDao(Vehicle v){} to get the correct instance of the dao.

public class VehicleServiceImpl implements VehicleService {

    @Resource(name="carDAO")
    private VehicleDao carDAO ;


    @Resource(name="trainDAO")
    private VehicleDao trainDAO ;

    private VehicleDao getDao(Vehicle v){
        if(v instanceof Train){
            return trainDao;
        } else if(v instanceof Car) {
            return carDao;
        } else {
            throw new RuntimeException("unsupported vehicle type");
        }
    }

    void doSomething(Vehicle vehicle){
        VehicleDao dao = getDao(vehicle);
        dao.doSomethind(vehicle);
    }
}

Thanks. Both carDao and vehicleDao implement the same interface. Is it a good practice to autowire an implementation, rather than an interface. — aprajitha, Mar 08 '13 at 02:00
this would require checking for all different implementations of Vehicle, therefore will be very hard to maintain. — Chaos Monkey, Dec 11 '16 at 16:29

score 0 · Answer 4 · answered May 25 '18 at 08:09

Please one note: previous solution is great and simple, but spring is creating each instance of each bean.

So my solution is to create abstract class VehicleService instead of interface

then in appContext

@Bean
@Primary
VehicleService paymentProviderService()
{
    return ...new (your requested instance by your own)...
}

Spring 3 - Dynamic Autowiring at runtime based on another object attribute

4 Answers4

Linked