One obvious solution to the problem is to always explicitly get the bean reference from the Spring context and then call the method on it, instead of calling the method on 'this'. For example, instead of this.anotherServiceMethod(), do:

It's an easy solution, but one that doesn't come without a few nuisances. For instance, it adds to your service bean some compile-time dependencies on Spring classes that wouldn't have been necessary otherwise.

One less intrusive solution I've come up with is a AdviceSkippingInjector.java that injects the reference to any proxied Spring bean into a property on the "raw" bean, i.e., the object prior to being wrapped in the proxy.

To use it, add a proxiedSelf property to the service bean (it doesn't have to be on any public interface), add this to your context file:

In the map beanProperties, each key is a bean name defined in the context, and the corresponding value a property name on the bean. At run-time, if the AdviceSkippingInjector sees a bean name in its map, it will drill into the proxies, find the reference to the original bean, and inject the reference to the proxy into the original bean's proxiedSelf property.

This solution is unintrusive because the service bean remains unaware of any of the plumbing work. All the wiring is done in the application context. In fact, the service bean isn't even necessarily aware that proxiedSelf, despite the name, points to its "proxied self".

The sample code above creates two bean definitions, the second one referencing the first.

Unlike a singleton controller, a prototype scope controller must have its bean name added to the 'mappings' property of the SimpleUrlHandlerMapping bean, instead of the 'urlMap' property, which requires an actual bean reference. The small price here is that, since the bean name is textually added to the mapping, there won't be any XML validation against it. (In fact, I don't think Spring IDE would catch an invalid bean name here either.)

First let's examine how a bean is made a singleton in Spring:

What the 'singleton' attribute really makes Spring do is to cache and always return the same bean instance for all the requests on this bean. As far as the comparison to a classical Java singleton is concerned, there are two distinctions that need to be noted here:

1. The caching of a bean instance happens only within a single Spring ApplicationContext instance - referred to as the "Spring IoC container" in Spring documentation. So obviously if I have another bean defined with the same id and the same class in a separate ApplicationContext instance, that one would be a completely different one. (Note that here we are talking about ApplicationContext instances, not context definition XML files, because more than one file can be loaded into one context instance. As far as the singleton scope is concerned, it is the instance not the files that counts.) In contrast, if we look at a Java singleton, its scope of singularity applies to the "universe" managed by the classloader that loaded this class.

2. When a bean reference is requested from an application context, the id or the name is used to identify the bean wanted. On the other hand, when we call Bar.getInstance(), we are really using the class Bar to identify what we instend to receive. If that didn't sound like something significant, consider a scenario where two beans of the same class are defined in the same ApplicationContext:

There will be two bean instances created in this context, both of type Foo, but one under id 'foo1', another under id 'foo2'. Clearly that's behavior we'd never see in Java singletons.

Having noted the two distinctions above, it becomes clear that a Spring singleton has some semantics rather orthogonal to those of a Java singleton - "orthogonal" in the sense that neither is the singularity of a Spring singleton meaningful in any scope definition based on classloaders, nor is a Spring singleton instance associated to any specific class. On the other hand, as we all would recognize, those are the two fundamental characteristics of a Java singleton.

Hopefully, this confusion will be clarified to some extent in Spring 2.0, with the newly introduced 'scope' attribute and the session, request, and global session scopes. Also Section 3.4 Bean Scope in the Spring 2.0 Reference explicitly puts out a warning note on the difference between the Spring singleton scope and the classical Singleton Pattern. Although I still think that it could have had the issue completely addressed, had the scope value "singleton" been renamed to something like "container" altogether - but then, I can also see some new confusion arising from that, like "how is this supposed to map to the singleton thing from before?"

First let's have a sample tag implementation:

Now, in the Spring application context file:

That's all there is to it. The tag declaration in the TLD isn't really relevant, because it's no different from what you would do with any other tags, but for the sake of completeness...-

<tag>
    <name>injectedTag</name>
    <tag-class>com.foo.InjectedTag</tag-class>
    <body-content>empty</body-content>
</tag>


This particular problem comes when I try to inject a DAO into a domain object (I know it's some debatable practice, but please just bear me for a moment). So the DO is annotated with @Configurable, its constructor is advised such that, at runtime, after the initialization, the Spring aspect will try to get a reference to the DAO, and sets it into this new DO instance. However, in order to materialize the DAO, which naturally holds a reference to a Hibernate session factory. The session factory needs to be instantiated first - and that, surprisingly, is when I get the "circular bean reference" meltdown.

After one pint of log reading, three shots of source code tracing, and a pinch of hair pulling, this here turns out to be the story: at the session factory initialization time, Hibernate3 needs to know which id value represents an unsaved object. E.g., null, -1, or whatever sensible value depending on the nature of the object and the corresponding table. This value is specified via the 'unsaved-value' attribute in the object mapping., and, as suggested by the reference, can usually be omitted safely, for Hibernate3 is very smart and can actually guess the unsaved-value by instantiating a new instance of the DO, which naturally would be intercepted by Spring and be injected with a DAO reference, which naturally would need a reference to the session factory, which naturally would have to guess what the unsaved-value is....

The solution is easy - just add 'unsaved-value="null"' to the mapping file, to prevent Hibernate from attemping the guess.

Now, I can hear you making some impatient noise - "what's all this inject-DAO-into-DO business?!" Well, I agree it's some debatable practice, but then it's also hardly the point here. I could well have tried to inject a service object into this DO, and the service object could have held a legit reference to some DAO. It would have been the same circular reference, only a larger circle.

Oh, and let me get this out of the way first, too - I mean no offense to Bob (I'm sure he is a good person).

Bob starts with:

... but frankly I haven't been able to get my head around your framework. Even worse, I've noticed what I consider to be a dangerous and blind increase in the rate of Spring adoption. I've yet to read a critical article or book on Spring.

Well, what I don't get is, how can one "get one's head around" anything, if one doesn't even bother to read on it first?

... Maybe Spring adoption is a knee-jerk reaction to J2EE. "J2EE is bad, and the Spring guys say their stuff is better, so Spring must be good." It doesn't work that way.

Maybe, but then maybe not.

Firstly, even though I can't speak for the Spring Team, I don't think Spring is targeted to replace J2EE. If Bob wouldn't mind just taking a peek at the Spring forums, he most certainly would realize most questions asked there are about how to leverage Spring in a J2EE application.

Secondly, last time I checked, the Spring team and most of the Spring users live in a society where information flows freely, and in an industry where competition is hot. Rod Johnson et. al. can't just hypnotize people into thinking Spring is good. So, it's not like "The US is bad, and Kim Jung Il says he is better, so he must be good." No, sir, it doesn't work that way.

The Spring folks openly snub their noses at J2EE, but from what I can tell Spring isn't exactly lightweight and simple either.

Would Bob mind giving a link to the above "nose snubbing?" As far as I know, the furthest Rod Johnson has gone so far is a book by him on "J2EE without EJB". Can we agree that J2EE ≠ EJB?

The Javadocs are unnecessarily overwhelming. Does all of this really belong in a user API? At least J2EE cleanly separates API from implementation.

That's because J2EE is an API, and doesn't have any implementation to begin with. And I personally find Spring's javadoc the best among the OSS projects I've ever worked with, and better than lots of commercial packages, too. Most of the javadoc does talk about the API from the user perspective - what the API does, what the usual usage patterns are, what the best practice would be, etc. Seldomly it gets a bit longwinding, but I for one am willing to live with that, rather than opening up the class description for DefaultDAOImpl and finding myself staring at "The default implementation of the DAO."

Spring advocates tout that Spring doesn't "touch" your code, i.e. you don't have to implement any Spring-specific interfaces (with the exception of life-cycle interfaces, etc.). News flash: the XML configuration is my code, and from what I can see it often ends up constituting a lot of code, all of which is Spring-specific.

Valid point. The XML is indeed Spring-specific. But that doesn't necessarily make the container agnostic on the Java code side meaningless. Following the same logic, the J2EE "standard" would be a phony, too, because when was the last time you deployed a serious enterprise application without having to supply files like weblogic-ejb.xml, or jboss.xml?

Back to dependencies on Spring APIs; don't I have to call the container to create my first object (assuming the rest of the Spring-managed objects in the graph are injected)? I want some way to check that the object I'm requesting is the right type at compile time. I don't want to cast. Ever.

Another valid point, albeit not very constructive - since Bob already admitted earlier that:

... I'm talking about Spring specifically, not dependency injection. I love dependency injection, and I follow the patterns every day. Good riddance to service locators!

Why don't we ask Bob to tell us how to implement configurable DI without any casting? Also, I'd like to remind Bob that the same argument applies to all the reflection usage as well. Does Bob never use reflection, ever?

It bothers me that I have to reference Spring implementation classes in my XML configuration. I don't care about the plumbing. In Spring's defense, I've heard they have so more concise, domain-specific XML coming in 2.0, but I haven't seen it yet. Why didn't this come up sooner?

Nobody has to reference Spring implementation classes in the bean definitions. They are just implementations that are convenient to use. Feel free to write your own and plug them in.

And, yeah, sure, why didn't <plug in your dream feature here> come up sooner?

What's with auto-wiring? Does anyone actually use that, or is just another notch in the feature headboard?

I don't use auto-wiring in production code, because I think it's too automagic, but, from what I can tell on the forums, a lot of users don't mind. And one very popular use of auto-wiring is in writing test cases. It helps easing a lot of pain from having to wiring up the dependencies explicitly.

Fortunately, simply adopting dependency injection design patterns gets you 90% of the way, further if you don't need encouragement to do the right thing.

I wonder how Bob would implement meaningful (i.e. configurable) DI without making it another container that has all "these same problems." Show us how you would go that "90% of the way", would you, Bob?

But not so when the above is done in a <constructor-arg>. Constructor arguments are not looked up by name, but by index or type:

Instead, this would make it a lot clearer:

My only wish is for the Spring team to consider adding a 'description' attribute.

So I went on and did a bit research (OK, OK, I really just googled "define: Scalability"), and got these definitions. Let me just quote the first three here:

The ability to scale to support larger or smaller volumes of data and more or less users. The ability to increase or decrease size or capability in cost-effective increments with minimal impact on the unit cost of business and the procurement of additional services. - dmreview.com

The ability and flexibility of an application to meet growth requirements of an organization. - hostqueue.com

The ability to expand a computing solution to support large numbers of users without impacting performance. - primode.com

So scalability is about performance - the capability to handle large volume of traffic, as far as web applications go. It does not have anything to do with "miminal service interruption when one of the servers goes down" - that's High Availability. It especially does not have anything to do with "no service interruption whatsoever" - that's Continuous Availability (see the last link). We usually don't need the expensive state-replicating schemes to achieve Scalability, or even High Availability. A sticky-session load balancer and a server farm without busily replicating sessions among themselves would scale well, and would provide some pretty high availability. It can't provide Continuous Availability because when a server fails all the users on that server at that point would have lost their sessions. That's the only case where clustering comes in and support immediate fail-over without any interruption to the service.

Now, the real question for all you architects out there that can't wait to hop on the "clustering wagon" the second you hear "scalability" is, is your application really "mission-critical" enough, meaning no user can ever lose her session, to justify the cost to implementing clustering? Remember the cost here includes not only the performance penalty (ironic isn't it), but also the development penalties - you'll have to make sure that whatever you stick in the session implements the Serializable interface, that whatever you stick in there references does the same, and finally that not too much is stuck in there.

On a separate level, I don't necessarily agree with Diego's comment (his main point actually) on Spring being not scalable, either. The fallacy here, IMHO, is the same as what I have seen from a lot of other online discussions. It's that people keep trying to compare Spring with EJB, forgetting they are different things and meant for different things.

What is Spring? Even though we all refer to Spring as a container, we have to remember that it's a completely different kind of container from the kind EJB is. Spring is a bean container, or rather more accurately, as the name of one of its core interfaces shows, it is a bean factory. All Spring does is providing us the ability to transparently wire up our applications, and the convenience to easily integrate with lots of third-part tools, but Spring does not reinvent the wheels by reimplementing those tools on itself. E.g., Spring provides easy integration with well-known ORM tools such as Hibernate and iBatis, rather than providing it own ORM package. On the other hand, EJB is a container in the real sense of "All Your Base Are Belong To Us" . It provides a complete solution with a more restrictive programming paradiam. Spring is not mutually exclusive with EJB, nor is it a competitor of the latter one. You can use Spring to wire up an EJB-based service layer just as easy as you do, say, a Hessian-based one. Comparing Spring to EJB is like comparing apple and orange.

Sadly, in the recent years, I have been observing more and more of this "let's move things around and call it clean" approach being applied in the software development community. What finally triggered me to put down my rant in this blog is the Spring Simplified with XBean proposed by Craig Walls recently.

I was, in face, perfectly OK with the first part of the article: Spring context files tend to be verbose - hear, hear; We could use autowire and XML name space to simplify it a bit - sure, k:HolyGrailQuest is definitely more intuitive than the FQN of the same class, I can buy that, even forgetting the price of enduring some extra API dependence on XBean for a moment.

And then there it came "the drawer", in this case being a property file:

...
In the example above, the XML namespace was a "java://" URI and XBean assumed some simple conventions for the XML tags and attributes. But if the namespace is an "http://" URI, it can be used to lookup a properties file that guides XBean to alias class names and property names into custom XML tags and attributes.
...

After applying the property file (and in any real application I wouldn't be surprised if there ends up being a number of them scattered all over the classpath), the original Spring context file is reduced, not only in terms of size, _but also_ in terms of the information it conveys. Granted, with all the verbosity in the original context file, it would take me a while to get a hold of how the beans are configured, but at least I still could. And the verbosity would become much lesser of an obstacle after the initial learning curve. Now with all the actual class names being externalized (again) into a separate property file, I can stare at the context file for all day and still have no idea as to which concrete class a bean definition will be instantiated with.

Towards the end of the blog, Craig gives a before/after comparison of the two Spring context files that shows the "simplification" cuts the size of the file to half. My argument, however, would be that a true comparison should be between the original file and the simplified one plus the property file.

And even that would be ignoring some hidden cost introduced - it's always harder and hence less productive to reference back and forth between files than to work within a single one. In this particular case, I don't really think the cost is justified. while Spring context files are indeed verbose, and _can_ become a real mess if you are not careful, somehow it has never become a problem for me in any practical sense -- maybe thanks to Spring's own ability to load and merge multiple context files into one definition, its ability to import context files into one master, and the Eclipse plugins I have picked up such as Spring IDE and XML Buddy.

Of course, as I said in the beginning, this rant of mine didn't just come from this one incident. People are trying to clean up the desk by sweeping the mess into drawers on much larger scales. For instance, initially we didn't feel like hardcoding Web application control flows, URL bindings, and all other sort of volatile mass into Java code, so we came up with various formats of XML files to dump those things into. Then annotation came along, so we somehow felt it would be cool to move those things back into Java code, only in the "meta data section" this time. And then some other folks developed tools that "allows you to externalize the annotations into XML or property-based configuration files."

Back to Craig's idea on simplifying Spring, I would like to conclude this article by a one-dollar wager - as soon as there are enough folks going along with this approach, I bet some of us will go ahead and develop "an extension to XBean that supports specifying Spring bean aliases and class names in XML files instead of the rather limited properties format." Now, any of you care to take me up on this one?

A couple folks seem to have some problem getting the Spring Portlet sample portlet content rendered. I just gave it a try and it appears to work fine with my installation. I guess you need to use Liferay's hot deploy script, and follow the steps listed in the Development guide. Copying the portlet directory into tomcat's webapps directory won't work because Liferay won't get a chance to do its own magic - like, make a little "adjustment" to your web.xml.

And here goes the latest version of the deployer script I used, in case you need it:

Here's one note to myself in the future - if you get something like this while running the hot deployer script:

It's because the tomcat lib directory set in the script doesn't exist.

There is some Liferay documentation discussing how to hot deploy portlets. Unfortunately it's mostly geared towards an Enterprise installation, whereas I'm working with the Professional. I end up with a heavily modified version of the deployer ant script provided in the document:

Once that and the Spring Portlet sample war are both ready in the 'my_portlets' directory, next thing you want to do is to copy everything under liferay/WEB-INF/lib into Tomcat's shared/lib. That's for Liferay to be able to load the portlet applications.

Now just run "ant deploy" to do the actual deployment. If Tomcat is running, and this is not the first time the same application is deployed, the deployer will spit out a bunch of warnings about "unable to delete" files. They can actually be safely ignored. The updated version of those files are actually in deployment by now if you go to check the timestamps. And Tomcat will pick up the changes and reload the application in the next scanner run. So, there, hot-redeploy works, too.

Once deployed, the JSR 168 portlets are treated no differently from Liferay's built-in ones. You can add them right away from the dropdown list at the bottom of the page. The Spring portlet sample consists of four simple portlets which all seem to live happily. I just used the generic sample application without any container flavors. The only change I made was to copy the liferay/WEB-INF/tld/liferay-portlet.tld to the sample app's WEB-INF/tags directory, and rename it to 'portlet.tld'. However later on I took a look into the deployed application and found out that the Liferay deployer actually did something similar automatically while it processed the war file, so I suspect even that bit of modification wasn't necessary.

I also noticed another trick the deployer played with the war file - if there is a jar file in the war file that's already in shared/lib (e.g. log4j.jar), the deployer would automatically drop it from the application being deployed. Assuming I didn't misunderstand this behavior, I seriously think it should at least be made optional by the deployer, because it could cause things anywhere from inconsistent to downright bad. For example, Spring distributes in two ways - one way is a monolithic spring.jar, the other a set of spring-*.jar files grouping classes into different functionalities. Liferay has a spring.jar, whereas the Spring sample application chooses to use a subset of spring-*.jar. You get some inconsistencies right there if they are running different versions of Spring. And what appeared to be "downright bad" to me is, since the web app specific log4j.jar is dropped, all the log4j configuration happening within the web app is now applied globally, and whichever portlet application that gets loaded the last takes over the control of the entire server's logging operation... Edit: I have since found out that if you point the property deployer.tomcat.lib.dir to somewhere else (say an empty directory), the jars wouldn't get filtered.

The last item on my wish list for the next Liferay release would be some more elegant way to hot-deploy portlets that doesn't involve any Ant script or command line execution. E.g., a directory scanner? or an Administrative portlet that lets me upload war files?

For the sake of discussion, let's say we have a domain object, DomainObject, and its DAO interface, IDomainObjectDAO. The basic idea is actually very simple - we declare a method in DomainObject:

What we put in the method body does not matter, because the execution of this method will be intercepted with a Spring managed advice that actually gets the DAO instance from a Spring context and returns it on behalf of the method at runtime.

There can be many ways to implement the idea. The one described below uses Aspectwerkz's offline weaving, and relies on the AppContextCollector, and Spring-manage Aspectwerkz Aspects ideas, so it might be beneficial to read those two blog entries first.

First we need a holder bean class as the runtime bridge to the target DAO reference:

The context definition file (with only the relevant parts):

Now in the aop.xml, just add:

Once this is weaved into the DomainObject class, getDomainObjectDAO will be intercepted at runtime and will retrieve the DAO bean instance dynamically. Because it does not cache the bean reference, this implementation is not limited to inject singleton beans, but also prototypes.

On first sight, this approach may cause some concerns in the readability of the codebase. However as long as this is used consistently across the application, and becomes a pattern, it is not hard to realize the getter method is being injected - not harder than any average AOP intercepted code anyway. Another plus of it is it does not rely on any specific ORM tool feature (such as the Hibernate events). Finally, if a different way of providing the DAO is needed in the future, a subclass can always override this method.

The main implementation class is the SpringBeanAspectContainer. (See here for the source code of AppContextCollector)

When being called to create an aspect instance, this class parses the aspect name specified its aop.xml definition into a context key and a bean name (e.g. "mainContext:myDAO" is parsed to a Spring bean named "myDAO" defined in an application context keyed by "mainContext" in AppContextCollector), and then uses those to get a bean from a Spring context previously created anywhere else. If the aspect name has only a bean name (i.e. doesn't have a ':' in the name string), the container searches through all the contexts in AppContextCollector until it finds a bean with that name.

The implementation itself is quite simple and straightforward.

To collect an ApplicationContext and make it available globally through a key, declare a Spring bean in the definition file for that particular ApplicationContext:

Anywhere in your code, you can then use: