Springsource is alive because they are creative and innovative. If OSGI really can bring us what Mr. Rod Johnson is promising, then it can become another de facto like spring  itself. They are trying to attack jar, war and ear files. Rod Johnson says that Jar is created when Bill Clinton and Monica Lowinsky's affair revealed and It must become history now. Productivity will prove the reality. Terracotta team enhanced JBoss cache with their tool and made it 12 times faster. Do you think JBoss cache will stand still? Of course not.



I am happy that nowadays startups dare to go beyond standards to become a de facto. I am not fenatic about a special kind of technology as they all have great impact upon eachother (like EJB2 and spring and spring and EJB 3). Efforts never become standards unless they bring us productivity.

I think spring  has its place  in some products
but it is overused
here are some problems with design model spring promotes:

1) singleton objects for components
2) stateless business tier objects
3) life cycle model (create component objects on startup)

although users can use factory objects but that is not the main model.
I think because of the first 2 options spring is not an scalable solution on multiple CPU computers
I may be a a good solution for small web based java  programs but not for Java EE (Enterprise) programs.
it is nearly a year that I am using JBoss Seam and I found it much better than Spring because:

1) better component model
2) better state management
3) better scalability
4) easier programing
5) more features  (bijection, ajax, ...)

I don't want to argue, just curious about why the three points  you mentioned are bad.

The architecture that I usually use promotes all three of your points, and it makes me happy.



I want to know what could be wrong with these three points, so that I know what I'm doing wrong.

I think because of the first 2 options spring  is a scalable solution ( in an application server  farm) , synchronization of statefull app has more load and concerns (such as cache management in a farm ) , but there isn't great difference in multi-core or multi-processor systems.

Spring is used for very large applications by hundreds of the biggest corporations in the world. The Spring Framework is well-established in the enterprise  development space where it is meeting the demands of applications for banking, government, and the airline industry.
One example  is Voca, whose services are used for payment of household bills by over 70% of the UK population and for paying over 90% of UK salaries. They¢ve relied on Spring to process over 5 billion transactions in 2005 - with over 72 million on a peak day.
Other acknowledgements of increased productivity and performance for large scale Spring-based applications include an online system for the French Taxation Office built by Accenture and an enterprise application  of the European Patent Office. (SpringOne 2006 Keynote, Antwerp, Belgium)
blog.itspax.com.br/.../...ptions-about-spring.html


I beleive JBoss Seam could bundle some frameworks  well and could help a developer to create his/her project easily and quickly and some concepts like bijection is beautiful, but in my idea :
Seam is more an IoC framework for web environment (like spring web flow) but it can work easily with JBPM , JBoss Rules (great integration)
Bijection is excellent, but i try to have one-way dependency
A lazily-initialized bean in Spring indicates to the IoC container whether or not a bean instance should be created at startup or when it is first requested
If i didn't have to have on-the-fly objects in web sessions i prefer to have stateless web app , but it is not practical for modern web projects ;) however it is poison for enterprise projects.

Actually I think each of J2EE technologies  (EJBs, hibernate, whatever) are overused! I mean look at ADF BC for example. Compared to its simple and integrated approach all j2ee  persistence mechanisms such as ejb3 or hibernate seem very stupid and primitive. True it has limitations but it's ok for most projects, yet everyone seems to have this foot fetish for using this or that cool technology!!

Overall I'd say Spring still has the upper hand when it comes to non-ui stuff. For example  take a look at Mule ESB. See how beautifully it uses Spring. Or in other words, Spring is great for framework makers, but other polished and consistent technologies such as Seam are great for consumers of these ready-made frameworks. The point is, most people actually are just users of these frameworks, and mostly in creating web forms and such, so stuff such as Seam are completely adequate.

Also re linking statelessness to scalability, if your process is actually stateless or can be simplified to a stateless model then doing it statelessly is definitely a more scalable approach. That's how google scales. It's a huge cloud of stateless functional calls with no side effects. Read a few Erlang articles to understand that. They just scale it more and more buy add yet another big bunch of server  for handling even higher numbers  of stateless calls. But if your process is stateful doing it in a stateless manner will cause overhead since every stateless call has to fetch the last state every time from the db. Spring has stateful components too, it's just that SpringSource advocate statelessness.

as in a paper that started software  engineering says: there is no silver bullet
every technology has its own place,
I have described in this blog while I prefer EJB3 component model to Spring Beans:
http://javaeearchitecture.blogspot.com/