Is bundling Spring with an app server a good idea

I don't think it is. It's a support nightmare as the customer will always want a different version than the one that was shipped, guaranteed. The rate and pace of application server releases compared to Spring releases, then fixes etc mean that the bundled version is always older than needed. I can't see this being that useful. Then there are the prereqs (commons) stuff that Spring needs and these will all be locked at the level shipped with the server also.

The vendor can, of course, allow the customer to replace Spring with any version they choose but it's very hard to support that.

On the up side, the customer gets support BUT they are also locked in to the exact level bundled with the app server. We run in to this continually with things like Xerces/Xalan/Struts etc, any jars like this that we ship in the product because we use them inevitably causes problems with customers when they want to use a more recent version.

So, Spring is indeed very cool. I don't know that bundling it is so useful though for the reasons above.

Comments

[Thomas Risberg]

I assume you are referring to the BEA WebLogic support for Spring. It's not bundled with the WebLogic server. It's provided as a separate download. This separate package can be upgraded independently so I don't see this as such a big issue.

[Colin Sampaleanu]

Bily,

That's a stock Spring 1.2.5 that's being distributed by BEA (and as Thomas mentioned), it's a separate download from the app server itself. The bundle just includes a number of additions such as a WebLogic console enhancement, and a new version of BEAs MedRec app architected to use Spring.

In the course of this collaboration, Spring _was_ tweaked in some small respects to work better in a WLS environment, but all this work has gone into the mainline version, and will be included in any future versions of Spring. (and to head off any nay-sayers, Spring of course still works great outside of any app server environment, or in other app servers).

[Billy]

Both these comments reinforce what I was saying, integrating this kind of middleware in to the app server is a mistake. Arguably, the ObjectGrid is another example of this. We want it to work with existing WebSphere versions and competitors as we want to be able to upgrade it independantly of the base application server version.
I am wondering though, just what is the value of this bundle then? Sounds like a customer could just download Spring and then get the same support as before on the mailing lists etc?

[Ken Tam]

As Colin points out, BEA is not "bundling" Spring with Weblogic Server. "Certification" is the right term to describe what BEA is doing with Spring. Weblogic Server doesn't have dependencies on Spring, so it's impossible to break the server itself by changing Spring versions. What certification gives the customer is assurance that the vendors have done extensive tests to ensure that the versions in question work well together. There's nothing to stop users from upgrading to a newer version of Spring (or for that matter, running different versions of Spring in different applications on the same server instance) -- however, you lose the benefit of the QA effort that went into the certified versions. While not necessarily significant during R&D, this is particularly important for going into production.

Weblogic has traditionally addressed the problem of "users want to upgrade open source packages that the server depends on" by repackaging the versions used internally. More subtle problems arise when such packages do things like depend on being on the system classpath, or heavily rely on system properties (that can only have one value) for configuration; but those issues are squarely in the domain of the package author to fix.