Retrieving beans by Configuration Object

Hi,

Thanks for providing JavaConfig. I realy like its type-safe way to use Spring.

Retrieving beans through their class is well documentend but I've wondered wheter it is also possible to retrieve beans by first getting the Configuration object from the ApplicationContext and than calling the definition method on the Configuration object to get to the beans.

I find this the most 'javaish' way, because it looks like invoking a singleton-method and the retrieve is both type-save and unambigious, refactorable.

This seems to work in my trival test-code based on the introduction example:

Code:

---

public static void main(String... args) {
  JavaConfigApplicationContext context =
          new JavaConfigApplicationContext(ApplicationConfig.class);
 
  ApplicationConfig applicationConfig = 
          context.getBean(ApplicationConfig.class);

  TransferService transferService =
        applicationConfig.transferService
 
  transferService.transfer .......
 }

---

My question is wheter this realy works like getting the bean directly through the ApplicationContext or are there any other disadvantages, because it is not documented at all.

Thanks,
Christian


.

Hi Christian,

Technically speaking, what you suggest below will work (as you've discovered). However, you lose all the benefit of having your objects managed by the Spring IoC container.

For example, if 'transferService' is a singleton-scoped bean (this is the default), your approach won't respect that. You'll get a brand new bean upon every invocation of applicationConfig.transferService().

The approach below also prevents any proxying from occuring, so AOP / transaction management, etc are out the window.

Glad you like what you're seeing so far!

Thanks,

- Chris

Hi Chris,

Thanks for your fast reply.

Actually the only thing I've originally also tested is that the definition method is only called once and according to my today's test also the same (==) bean is returned by repeated calls for Singletons (for prototypes a new instance is returned as expected) also the AppplicationContext is set and afterPropertiesSet is called correctly on the singleton. I haven't tested anything else yet.

Maybe I do something wrong in my test, but I am quite sure its correct. And I don't want to be annoying, but I'd realy like this feature because in my current codebase I've a lot of calls to traditional Singletons (ServiceHolder in a static field - without spring) and I'd like to replace this with spring. JavaConfig seems like the rescue.

Beside this I think calling the methods on the Configuration object has as said the advantage of unambigiouty and IDE-autocompletition.

Anyway is there a chance that there will be in a future version a way to get a proxied Configuration object, which does the call into the ApplicationContext?

Thanks,
Christian

Christian,

I was a bit hasty in my previous answer. The configuration object you're retrieving does have all the services of the container, because it has already been subclassed via CGLIB. This is why singleton semantics are respected, and indeed any proxying will work.

It's interesting to find that this is a desirable feature. It won't be going away any time soon, so enjoy using it. However, I would seriously reconsider using it as a drop in replacement for your existing static singleton calls. If I understand what you're saying correctly, the better approach would be to refactor where possible toward real dependency injection. Singleton calls are dependency lookups, and thus reduce testability and increase coupling. This remains true even if you use Spring vs. a traditional Singleton within your application code.

Best of luck,

- Chris

Hi Chris,

Thanks a lot for your positive reply. And you are right concerning the DI - but I want to gradually introduce spring.

Thanks,
Christian