Well am really getting pissed off with all this Spring cheap marketing and unwillingness to join the standardisation effort.
For the JEE6 yes we need a sophisticated IoC mechanism and really think Guice is a natural feat here as it’s already annotation based and interfaces based.
Another must would be Aspects, we’ve got a lil dose of them with the interceptor mechanism in JEE5, We got addicted and we need more and more
Oh the component model, I think we have that with Seam/web beans nope?

Cheers
Daoud AbdelMonem Faleh

Bingo – Spring looks very powerful, but as Bill mentioned, standards to follow and (although scary) knowing when you pick a standard there are multiple implementations to choose are absolutely huge for commercial/business decisions on technology.

What I want is an end to the EJB vs. Spring debate. If Spring IoC became a part of EE 6, then all EJB turns into is a set of pre-packaged idioms. Lifecycle (instance per request, session, singleton) and cross cutting concerns (tx, security, etc…). I just feel it will make Java stronger to have everybody on the same page. We now have this with persistence, would be cool to get it with a component model.

So it should be “Standardize IOC in EE6″ and not as the title above. Because integrating Spring in EE does not make sense. That becomes obvious when we see get down to see what Spring really is and what it means to standardize it.
Is it something that adds new functionality? No. Or provide new features that EE does not already provide? No. Spring does nothing by itself. It provides abstractions. Wrappers for other commonly used tools, not implementations. Makes developing an application easy, not differently.
For example, if Spring could generate xml feeds it would make sense to pull it in. But no, all spring can do is create the bean that can generate the feeds, without you bothering about how. So how helpful for anyone if the EE specs says ‘you need to have the ability to generate the bean for generating feeds’?

So what would you take from Spring in to EE that’s not already in EE? AOP? alright. Ok, what else? Force application servers to support HibernateSupport? JUnit? Toplink? any n number of tools that keep coming? And tie users to SpringControllers? If so really, how? Are vendors supposed to update the app server for each and every versions of these tools? Would you release a new EE version everytime one of these tools have a incompatible or major API change?
So it simply means you just can’t standardize it. You can also see then Spring is nothing more than a composite of layers that uses different components. So again, does it means you are willing to support all the tools that will ever be released? And put then into EE? Because Spring would have, in the future. Please, go ahead then. It would be really great. It would also ensure that you can ‘protect’ user community from open source projects that are run by people who may start waiting for their payday events.

And you are comparing Spring with Hibernate. They are entirely different. Hibernate is a tool whereas Spring is not. Spring just does things in a particular way out of many possible ways. You can also do it using struts and pico container. So why not them?

Also what makes you feel Spring is looking desparetely to build their own kernel and build a stack without providing any services? Who would anyone want to do that just to implement an IOC container? Let’s not forget that basically Spring is a framework and does what ever you want by depending on other tools. Not by itself.

All Spring has done is by an excellent way of implementing a pattern. And has got much hype because of it. Can you point someone who likes Spring because it supports ORM tools or JUnit? No. All one gets in mind hearing about Spring is IOC. As with struts, Spring is going through it’s honey moon period.
And that’s where your interest lies. Cashing in on a company that’s enjoying a limelight.

It’s quite natural tomorrow Spring grows old and another better framework comes along. So why would you think if something happened to Spring it would leave the panic striken developers groping in the dark? You as talking as if the Spring team has an exclusive hold on IOC pattern itself. Lets not forget that there are alternatives to Spring too and many upcoming ones. All I see is just another attempt to get more $$ in the name of protecting the user community. As the trend is now, gobble up the fine matured open source work and make it closed source. But I guess that’s another topic.

Personally I believe they participate to make sure it’s done right this time over.

Steven. We all participate to make sure its done right….

Personally I believe they participate to make sure it’s done right this time over.

It is my personal opinion Spring OSGi attempts to make OSGi integration in applications easier. As far as I can tell today – Spring OSGi is still early days – it doesn’t even offer a separate deployment model on top of ‘normal’ Spring.

There are actually compelling reasons for Spring NOT to be standardized. If you look at the growth of Spring since before 1.0 till today you’ll notice it’s a opportunist framework. Spring’s integration with APIs/frameworks/what-not has been added over time when it made sense and this often outside of the official Spring distribution.

Spring is also much wider than it is deep. That means: Spring adds small integration layers on top of many things – transactions, remote access, JNDI, JDBC, JMS, JMX, Servlet API, … – and the amount of these integration far outreaches the extend of any particular integration.

Spring is thus impossible to standardize. You can standardize dependency injection which has already happened to some extend and which Spring now supports. You can standardize other bits and pieces and Spring will always support these new standards. But you cannot standardize a opportunist framework itself.