I think with the rise of Java 5+/JEE 5 there is less and less a need for spring. I like the simplicity of Guice, and while DI is just another way of doing something developers have always done, it does have its drawbacks which i think you have accurately captured.

Here is a comment i left on Kevin’s (Guice co-creator) blog which talks along the same lines, and why i don’t mind the Guice way!

http://smallwig.blogspot.com/2007/06/coupling.html#c347596939873173442

The main advantage, is it’s integration with different technologies and frameworks out there, and it’s AOP oriented configuration which makes it very powerful.

K

By the way, there is a third option for the SessionFactory problem. ServiceLocators don’t need to be accessed statically. So if you have two objects that require different Factories, you can pass different instances of the ServiceLocator to each object, each of which has a different instance for a given interface. Yes, that’s DI, so what? I just need to pass one object. I’ve never said that DI is bad, just that sometimes SL may be simpler. And the mix of both can be pretty good, too;D

Everything looks ugly in the corner cases. That’s why they’re corner cases, isn’t it?

Bean + one dependency on some DAO somewhere in the app context. Write a simple test class that spins up the Spring app context like you want and you can verify before you do anything else that the bad label problem doesn’t appear.

Actually, our ServiceLocator implementation has two HashMaps, one for services (i.e. identified by their class) and another one for general Objects (i.e. identified by a String).

Well, if the Maps contain the same configuration (different keys) you’re beating DRY to death. If they don’t then a dev is going to have to know which one to go get or know to pass in a String this time and a class name the next to locate dependencies or use both in one class if one is by class the other by name.

In the case you mention I’d think of two different approaches. The first one would be to store as a service a generic Factory that allows you to obtain the specific Factory you want.

Agreed that is a solution but you would now be introducing artificial object just get to around the configuration. That factory would have no reason to be except as a workaround.

The second option is to store it just as named objects.

Now you’re back to your bad typing of labels problem….

I think you left out all the bits where you tell Spring whether your sellerService is a Singleton or not, the scope, and so on.

Wow. In my version of Spring I usually need an id and a class attribute only for the bean definition itself. Now I can use those other things if I want – but I don’t have to:

I only ended with a comment about the 4 lines containing “XML”. The majority of my comment is aimed at pointing out that when you approach the edge cases of usage the ServiceLocator will get “ugly” too.

In the case you mention I’d think of two different approaches. The first one would be to store as a service a generic Factory that allows you to obtain the specific Factory you want. The second option is to store it just as named objects. The point is that the ServiceLocator implementation is that easy that you can adapt it to whichever your needs are quite easily.

Just as a sidenote, yes, I agree that XML hell of Spring has already throughfully discussed, but since I was talking about the complexity of Spring I couldn’t avoid to mention the most classic one ;D. But, indeed, I use the word “XML” just four times in a 90-ish line post. I devoted much more time to describe why it was harder to design components for use in DI than to nag about how much configuration I had to write. The whole point of the article is to compare the Service Locator pattern with the Dependency Injection patttern, and the popularity it has got due to Spring. But sadly, most of the comments (both here and at dzone) seems to be aimed at those four appearances of “XML”.

Ok, how much could it be? 40 lines? 200 lines? 1000 lines? It may be not that much, but it just isn’t really needed, and doesn’t follow the KISS principle. Use it at your own risk.

Regarding the line about getting the service instance, the difference is that it is in the class that uses the service, not in the initialization. That means if that class is in another component, wherever I reuse it I don’t have to explicitly provide that reference, whereas in DI I have to. And by the way, if I’m not mistaken, the Spring equivalent is:

public void setLogger(Logger logger){
this.logger = logger;
}

(property name=”sellerService”)(ref bean=”sellerService” /)(/property)