I’ve been using the Spring framework for about a year now (or maybe more — it’s amazing how fast time goes by these days). I’ve also been teaching courses in it using Capstone Courseware materials.
As is normal with Capstone materials, they tend to skip quickly through the “Hello, World!” version of whatever technology they’re discussing, preferring to go on to applications that much more closely represent the real world. That way they can discuss subtleties and best practices while still communicating the basics.
A simple example is the way Spring can enforce the Singleton design pattern or not, regardless of the way the underlying Java bean is written. Say we have a Java bean that looks like:
public class MyBean { private static final MyBean INSTANCE = new MyBean();
private MyBean() {}
public static MyBean getInstance() {
return INSTANCE;
}
}
MyBean is a classic example of a Singleton. It has a private constructor, a static attribute to hold the shared instance, and a public static getter method to return it. As far as Java code is concerned, there will never be more than one instance of this class.
Spring gets along with singletons quite well. In fact, by default all Spring-managed beans are singletons. The fun part, though, is when we tell Spring that this bean is to use scope=”prototype”, implying that it should return a separate instance each time a bean is requested.
<beans xmlns=…>
<bean id=”MyBean” class=”cc.beans.MyBean”
factory-method=”getInstance” scope=”prototype” />
/>
The question is, what happens in the code when factory.getBean(“MyBean”) is called twice? Does Spring return two references to the same object (rejecting the “prototype” designation) or does it return two separate instances (rejecting the private constructor)? Who wins?
Spring does, which probably doesn’t come as much of a surprise to anyone who has played with reflection before. All you need to do is to get the Class reference for the bean, retrieve the private constructor, and call setAccessible(true) on it and it’s yours. Spring does what it’s told to do, working around any supposed limitations in the Java code.
That’s either troubling, or pretty cool, depending on your point of view. What I can say is that it comes as quite a surprise for most students in class.
Of course, my real point is that the Capstone materials discuss this case in detail, which is not necessarily the sort of issue you’d expect to see in a training course.
The materials talk about a wide range of Spring issues, including major sections on the web (MVC) framework, the DAO layer (with templates), and a bit about integrating with ORM tools. The bottom line is that after having taught that class probably a dozen times in the past eight or nine months, I felt I had a pretty good handle on the framework.
Well, yes and no.
(Or, as I tell my students, “that turns out not to be the case.” The phrase “that turns out not to be the case” is the most diplomatic way to tell your boss he’s completely wrong. You can even preface it with “I can see why you might think that, but” if you like. Try not to roll your eyes while doing so.)
The other day, I attended a meeting of our local Connecticut Java Users Group. The meeting featured a presentation by Mark Fisher, a consultant with Interface21, the creators of the framework itself. I knew I wanted to see that, because even if he spent all his time talking about areas I’ve already used, I knew he’d say lots of things I didn’t know.
I’ll say more about that soon. This post is getting rather long.
Leave a Reply