cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darren Shepherd <>
Subject Re: ComponentContext.inject() usage in storage framework
Date Wed, 28 Aug 2013 23:04:17 GMT
On 08/28/2013 01:41 PM, Edison Su wrote:
> There are cases, the object is not singleton, such as VolumeObject, but it needs to access
DAO, then either we need to pass the DAOs in the VolumeObject's constructor, or through ComponentContext.inject(),
or using AspectJ's @Configurable(
> BTW, why  ComponentContext.inject() breaks IoC and DI patterns? Per my understanding,
ComponentContext.inject() just tells IoC container to take care of the object creation, as
the object created by "new" operator won't be injected by IoC container by default.

By calling inject() your basically inverting the inversion of control. 
So, in short, what your doing is using Spring as a gloried factory or 
service locator.  If that is the case, then just use that pattern as its 
more explicit.

With VolumeObject it appears that you have create a framework managed 
object.  So you really should just have a factory or actually a 
repository (being that your looking it up).  So have a 
StorageObjectRepository or something like that, that has a 
StorageObjectRepository.getVolume().  The repository object can have the 
DAO's injected to it and then in the getVolume() call you need to 
contstruct the impl object and set the DAOs (in the constructor 
probably) on the impl object.

Now inject() specifically causes a larger problem for what I want to do. 
  I'm working on the idea of putting in a true module system into 
cloudstack (ugly pictures and some words at

and inject() will break it.

The problem with inject() is that is assumes there is a single global 
application context.  In a hierarchy, like I'm going to propose 
eventually, no single global application context can exist if you have a 
tree with siblings.


View raw message