Spring annotations static injection tutorial

Spring’s architecture isn’t very friendly to static classes and methods.  It doesn’t have any way of injecting static properties of classes because it doesn’t have any way to discover them.  Spring’s designers have acknowledged that it’s a shortcoming of the framework and suggest the use of this solution.

  1. Create the static property of the class without any annotations
  2. Mark the class to have static properties injected with @Component so that the properties will be injected on Spring startup
  3. Create a non-static setter method that sets the static property
  4. Mark the setter method with @Autowired(required = true)
@Component
public class UserUtils
{
  private static UserAccessor userAccessor;
 
  /**
   * Sets the user DAO. This method should never be called except by Spring
   * @param userAccessor The user accessor to set
   */
  @Autowired(required = true)
  public void setUserAccessor(userAccessor UserAccessor) {
    UserUtils.userAccessor = userAccessor;
  }
}

Using this technique, you can have all of the advantages of Spring injection without the headaches of Spring injection!  Avoid using this technique whenever possible.  It should only be used to support legacy applications.  With a lot of statically stored values, your application will not scale well.

Posted in Spring by Connor Garvey at February 11th, 2009.
Tags: , , ,

15 Responses to “Spring annotations static injection tutorial”

  1. Hello, Neat post. There is an issue along with your website
    in internet explorer, might test this? IE still is the market chief and a good portion of folks will miss your fantastic
    writing because of this problem.

  2. Appreciating the persistence you put into your website and detailed information
    you present. It’s awesome to come across a blog every once in a while
    that isn’t the same unwanted rehashed information.
    Great read! I’ve saved your site and I’m including your RSS
    feeds to my Google account.

  3. You ought to take part in a contest for one of the finest blogs
    online. I’m going to highly recommend this web site!

  4. Anonymous says:

    It is NOT working in Spring 3.1.3 . Who ever has it got worked are you using different Spring version than Spring 3.1.3 ..?

  5. dogan says:

    Thank you! It works

  6. Gerard says:

    Nice solution to my problem. I am doing some quick and dirty bench mark testing leveraging Junit and SpringJunit4ClassRunner. My problem was that I needed a way to kill Hazelcast before it was automatically starting again by Spring in the next test class.

    Again nice solution…. I tend to forget the little gold nuggets as time goes on (day-to-day).

    @RunWith(SpringJUnit4ClassRunner.class)
    @ContextConfiguration
    @Component
    public class WriteBehindCrudTest extends AbstractThreadedCrudTest {
    private static HazelcastInstance instance;

    @AfterClass
    public static void after(){
    instance.getLifecycleService().kill();
    }

    @Autowired(required = true)
    public void setInstance(HazelcastInstance instance){
    WriteBehindCrudTest.instance = instance;
    }
    }

  7. Arjun Dhar says:

    I agree with MattL, except that the author here is specified that its for situations where you have legacy code and it is true tha a lot of legacy code ‘l time’ used a lot of static variables and stuff.

    However, I’d be inclined to push code into places like a method with @PostConstruct annotation. This would mean the bean is fully initialized with all dependencies and now you can initialize the static member common to all instances (singleton or not).

    Note:: If the static variable value is not common for all instances, then its WRONG to be static by definition anyway.

  8. Amit says:

    Nice Solution. Having static methods is one usage of having static field injection.
    Though I didn’t understand why Spring does not encourage static field inject and how do static values affect the scale factor of an application. It would be helpful if someone could detail out on this a bit.

  9. Thanks, helped me to solve my problem!

  10. Juan Carlos Blanco says:

    Better solution would be:

    @Component
    public class UserUtils
    {
    private static UserAccessor userAccessor;

    @Autowired(required = true)
    public UserUtils(@Qualifier(“userAccessorImpl”) userAccessor UserAccessor) {
    UserUtils.userAccessor = userAccessor;
    }
    }

  11. Tyrone Hed says:

    The problem with this approach is that the setter injection of a non-static variable can happen AFTER the static variable has already been used. So, beans that use the static variable before it has been initialized by the non-static setter will get the default value of the property while beans that use the property later will get the initialized value. So, this is not a perfect solution.

  12. Joksy says:

    @MattL, hi man, personally i use static constants as a key for both sessions and Context in generals, the point is accesibility, a public static variable it is accessible everywhere, whereas singleton object handle by spring appcontext means that you have a reference of that context.

    for sure there are some reason why spring arch. did not develop the support for this point anyway a workaround always exist.

  13. Andras Hatvani says:

    Nice hint, added to bookmarks ;) However, it doesn’t work with JUnit 4 test cases, where I wanted to inject a resource used for initializing another field in @BeforeClass which has to be static.

    @MattL: static definitely isn’t about changes, so I’m not sure, whether your rule makes any sense…

  14. MattL says:

    I always considered Spring’s lack of static injection a feature.
    The semantics of static properties and especially singletons are often not fully understood and can result in very obscure problems and assumptions. This is especially true when serialization, persistence and remoting are involved.

    My rule is: never use static properties unless their value is guaranteed never to change ever for the life of the universe.

    Spring has a better option – define an object to be a singleton within some context e.g. the application context. Then we can tidy up the semantics for persistence and clustering and not use statics.

    Just my 2c.

Leave a Reply