Comments on: Spring annotations static injection tutorial http://www.connorgarvey.com/blog/?p=105 Connor Garvey's application development notes Wed, 08 Sep 2010 08:42:30 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Tyrone Hed http://www.connorgarvey.com/blog/?p=105&cpage=1#comment-2323 Tyrone Hed Thu, 22 Jul 2010 15:49:02 +0000 http://www.connorgarvey.com/blog/?p=105#comment-2323 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. 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. ]]> By: Joksy http://www.connorgarvey.com/blog/?p=105&cpage=1#comment-1258 Joksy Tue, 01 Jun 2010 06:48:30 +0000 http://www.connorgarvey.com/blog/?p=105#comment-1258 @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. @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. ]]> By: Andras Hatvani http://www.connorgarvey.com/blog/?p=105&cpage=1#comment-803 Andras Hatvani Sun, 28 Mar 2010 12:15:49 +0000 http://www.connorgarvey.com/blog/?p=105#comment-803 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... 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… ]]> By: MattL http://www.connorgarvey.com/blog/?p=105&cpage=1#comment-18 MattL Fri, 20 Feb 2009 17:12:28 +0000 http://www.connorgarvey.com/blog/?p=105#comment-18 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. 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. ]]>