Congratulations guys with this GA release. Keep up the work…

Congratulations!

3.1's already working in one of the project I'm involved at – it's a governmental site with WebSphere 6 which won't go away soon.

Welcome to the real JavaEE world! Spring is de-facto Java Enterprise!

regards
Grzegorz Grzybek

Hi Juergen Hoeller,

Good to here that 3.1. GA is out. We tested one of our application(war) by migrating to 3.1 it works good with out having any problems. But when we tested my other application(ear) by deploying it on jboss, we are not able work (The version of spring deployer that we are using is having 3.0.6 release compaitable jars). Can you please share your thoughts in this.

@Mike Versteegh

Juergen said exactly what I've experienced. Ask yourslef a question of lifecycle – who decides what constitutes your application and who – the environment the app's goiing to be deployed?
The application is created, then fixed then maintained – each release is (simplifying) a WAR – you can put anything you want in it. But the application appears in a particular moment in destination environment. For me it was one WebSphere 5 (back in 2004).
You said that "if I'm using J2EE 1.4 (eg Websphere 6) and I want to use Java EE 6, I need to upgrade to Java EE 6 (eg Websphere 8)" – there is a difference between "I need to upgrade" and "do the customers want their environment upgraded"!
For example (incompatible lifecycles): our app was up and running fine on WAS 5 (Spring Framework upgraded from 1.0.2 to some other – maybe 1.2.6 release) and suddenly there was POLITICAL decision to migrate to WAS 6 – we had to change everything J2EE described (JSP, MDB, servlets, …) – of course the specifications were better and the changes resulted in code decrease, but it was not our decision. Guess what – WebSphere 6 is still working there – now there's political decision NOT TO migrate to WAS 7 (which is JavaEE 5). So we're stick with J2EE 1.4.
Now the great part – for you it's obvious that if you want JavaEE 6 you have to upgrade to WAS 8. For me it's not that obvius – if I want JavaEE 6 (e.g. JPA 2) I just need Spring 3 on WebSphere 6 – I can choose Spring, I can't change WAS 6 – simple.

My observation is this: JavaSE promised platform independence – that's great for developers, not so great for platform vendors. So JavaEE was born – not with standards, freedom or developers in mind (generally) but as a way to make profit by platform vendors. JavaEE turned platform (OS) independence into another platform (app server) dependence – the TCKs promise indepence at this new level, but there are many quirks which in the long term tie you to the particular implementation. Hibernate looks the same as EclipseLink at API level, but not at implementation level – are you going to risk your enterprise application with implementation switches? I'm not.

So in enterprise environments it's maybe rude, but necessary to treat platform (INCLUDING) app server just as JavaSE promised – not as services provider, but simply as classloader for your WARs. It's my experience. Maybe my WARs are heavier, maybe my app starts (loads classes!) slower (in production I restart it about once a year), but I know and rely on every depencency I have in WEB-INF/lib. I don't care about JAX-WS, JPA (since Thymeleaf even about JSP) which my app server provides – I have the same implementation on Tomcat, WebSphere and Jenkins.

Once again Mike – I can have JavaEE 6 on WAS 6. It's primitive, but real assumption – there is MY application and THEIR app server.

I'm not against "JavaEE", I'm against tying my application's lifecycle to the lifecycle of Application Servers' upgrades. I'm against recommending "Vanila JavaEE" as a fastest way to develop Enterprise Java Applications – it looks good on slides, deploys fast to GlassFish on conferences, but in practise it gives you headache when trying to run the same application on Jetty, Tomcat, WebSphere and Glassfish.

(With "Jetty Nested" you can even run Jetty 8 inside WAS 6 – however without Servlet 3.0 support)

@grzegrorz

You say it was a POLITICAL reason to upgrade to Was6, but why wouldn't it be a POLITICAL reason if you are forced to upgrade from Spring2 to Spring3?

Why would whoever makes those decissions about upgrading only make this decission for Java EE and not for Spring???

The only reason I can think of is if the decission maker never actually checks your work and you betray your company by secretely using something else than you are supposed to. If that's the case, then it's a rather unhealthy place to work (for both sides).

@Eddie

[quote]What's the fundamental difference between the JSF libs that are already installed at the server, vs say the Wicket libs in a war[/quote]

The difference is you can choose any Wicket version you want. You can't easily change JSF implementation AND even version without interferring with other applications deployed on server (the same concerns JAX-WS, JPA, etc.)

[quote]Especially when you are not running multiple applications on a single application server[/quote]

That's not what 50K$ worth WAs is for

[quote]So, it's not technically Java EE's fault, it's just a political problem.[/quote]

The problem with JavaEE is that App Server (e.g. WAS) is often selected before ANY technical decisions…

[quote]The thing it always seems to boil down to in every discussion is that Spring can be used to sneak updates past operations and management by effectively hiding a full application server inside a war, that bypasses most if not all functionality of whatever is installed.[/quote]

You're wrong. Spring's not full application server – Juergen explained it. Spring's part of your application just as commons-collections, hibernate-core or slf4j. I can't imagine sysadmins choosing my collection library…

[quote]Can we perhaps say that if any Java EE vendor ever introduces a full Java EE implementation that can be directly as-is embedded in a war, that Spring is hosed?[/quote]

No. does JavaEE contain such beautiful MVC Framework?. I don't think so. JSF has maybe some uses, but not as many as MVC frameworks.

@Mike

[quote]but why wouldn't it be a POLITICAL reason if you are forced to upgrade from Spring2 to Spring3?[/quote]

First – no one will force me to change Spring version, just as no one will force me to change commons-beanutils version.

[quote]The only reason I can think of is if the decission maker never actually checks your work and you betray your company by secretely using something else than you are supposed to[/quote]

No. I have to use WAS6 and make the application work. WAS was bought for serious money and it "has to be used". Everyone knows it's old, so something has to be done

regards
Grzegorz Grzybek

@grzegorz

Spring does not equals common bean utils. Spring is much more equivalent to CDI, EJB, JSF, JAX-RS, etc.

Obviously, when "they" decide the version of was to use (or glassfish, jboss, tomee), they decide the version of CDI etc. Since CDI is equal to Spring core, they should also decide the version of Spring then, right?

And JSF 2 is a very good MVC framework really

For running a single app per AS via xen, just use JBoss, Glassfish, Geronimo or any other of the totally free Java EE implementations.

>Why pay next 50k when "all is working"?

Maybe stop thinking in Websphere terms for the moment. The discussion was I think about Java EE in general. Glassfish, JBoss, Geronimo, TomEE and Resin are all free (as in free beer) and open source. I can upgrade Glassfish as often as I want and never pay a penny to anyone.

Upgrading Glassfish is NOT inherently different than upgrading Spring. In both cases it should only be done after careful consideration and with the grace of a lead developer, and after carefully testing that everything still works as expected. This should be done by the engineers (developers).

In both cases neither operations nor management should have much say in that.

> First – CDI is not equal. I know the spec, but prefer the choices Spring gives me (bean profiles, bean factory postprocessors, XSD specialized config, …).

Sorry, but I think you don't get the argument. To me it was clear that CDI and Spring are comparable as they represent a core programming model. Commons-beanutils is not directly comparable with any of those.

>Believe me – if I was the one to make decisions – it would always be Tomcat/Jetty – they're good at converting HTTP traffic into Servlets' invocations.

Tomcat/Jetty still provide the Servlet implementation and you're still stuck with whatever JVM is underneath all of that. So your war still doesn't contain everything your app depends on!

IMHO, what -you- need is a type of archive that contains a JVM application server your application. Hmmm, I think those are called "executables" and they actually exist!

>Generally speaking, operations teams do not care about a version of CDI, or CDI itself to begin with. They may choose a great server product for its operational characteristics, and then this server happens to come with some version of CDI as part of that.

At the core of this is the IMHO misunderstanding that e.g. JBoss AS is "the server" that operations should care about. Still IMHO, it's not.

The kind of server operations should care about is the Linux installation and the hardware it runs on. Which network devices does it have, what remote management interface is there, how is installed, what is the virtualization solution (Xen, VMWare, etc) how are the firewalls configured, how is the Apache *server* in front of the Java app configured.

The term "application server" is perhaps unfortunate, as JBoss AS and co are first and foremost implementations of Java EE. There is barely any "server" element to it to speak of. This is even more true for Tomcat. Operations should see this as a Java application, that needs a connection to the front-end server via AJP.

I've worked for a couple of companies and for projects that ran on farms of servers and projects that were hosted on a single server for intranet usage. The most I've ever seen operations do is execute /etc/init.d/jboss restart. Devops is a different story, but a traditional operations team does only that.

They are NOT going to configure JMS destinations or wire EJB configuration via deployments descriptors that override annotations. That's a wicked pipe dream that has very little to no connection to reality. Just like the Spring or CDI jars are owned by the engineering team, the piece of software called JBoss AS should be owned by that team. Some organizations get this (sometimes via a devops movement), some don't.

Spring's default way of working is to work around this political wrong phenomenon, but as was mentioned before;

1. There's Tc Server Spring Edition which is just like JBoss AS, Glassfish, etc
2. All Java EE libs can be embedded in a war as well. For Spring core's most direct competitor (CDI I think) this is even fairly common. For Spring MVC's most direct competitor (JSF) this is also absolutely common.

>Ask yourself a question – what's easier – change cxf-*.jars in WEB-INF/lib or change them in JBoss 6's UCLs?

Well, at our company we happen to run on JBoss AS 6.10 and we update the JSF mojarra libs every time when necessary. We're currently on Mojarra 2.1.4 and locally testing with the latest builds. Updating JSF libs on JBoss is absolutely trivial. You can either make a new config, add that to the list of configs and make it the default, or even easier, simply replace the jars.

As soon as we have fully tested that our application works correctly, we (the engineering team) prepare a new JBoss archive, which is pushed to our QA servers and once again tested and if this passes it is pushed to production. This is exactly the same process as with updating the JDK. There's nothing particularly hard about it.

On average we update our JBoss archive approximately every 3 months, sometimes a bit more, sometimes a bit less. When JBoss itself releases a minor new version (e.g. AS 6.0 -> AS 6.10) we update to that via the same process. Major new versions (AS 6 -> AS 7) take some more consideration and planning, but that's also true for major new versions of the libs we depend on (e.g. JSF 1.2 -> JSF 2.0).

Our EARs are pushed more frequently into production, on average every 3 weeks (the length of our scrum sprint).

I totally don't get where the idea comes from that a JBoss archive is being put on the server and sits there for years untouched, and that engineers are not even allowed near it. I know there are companies like that, but for us this is completely alien. Application code is developed together with a target JBoss and a specific JDK version, and whenever any of these need to be pushed into production they are prepared by the engineers, tested by QA and actually deployed by the deployment guys.

@Juergen

You are right, there is plenty of cool stuff in 3.1. I especially like the caching annotations. I haven't even congratulated you guys on the release and dived straight into the discussion, so here then:

congratulations on the release

It is a strange thing though, that whenever there's a Java EE/Spring discussion going on, 99% of the time this WEB-INF/lib deployment comes up. It would be more constructive to actually compare features.

Do you know when the "instrumented" version of this release will be out? I do not see anything higher than 3.0.5.RELEASE in the Springsource Artifactory.

Thanks!
Allen