Both of these appservers are at least in part OSGI based. One (Glassfish) is obviously J2EE while the other isn't. Now I'm at the stage of choosing a platform for a new project and the natural choice is Glassfish v3 Prelude. This does raise the issue of perhaps we should be using S2AP instead.
The question then is this: does the springsource dm server offer any compelling reason to use it over Glassfish? And vice versa.
I haven't used SpringSource dm server, but I believe it is better to wait a while before trying it in production. The reason has to do with it being rather new technology. Also, the way the licensing scheme works with SpingSource (GPL) doesn't help much, as it practically means that you will be relying only on SpringSource for now and for the future. If you need support for the server, then your only option is to go with SpringSource.
JEE app servers have distributed transaction managers. If that is at all important, then may want to see if SpringSource dm includes such.
It is possible to do XA TX with Spring-Framework, is just that you're left on your own to locate a suitable XA manager and integrate it.
Course XA TX have very much fallen into disrepute. Most folks try to avoid them like the plague. Amazon.com, for instance, does not use them.
We currently use Spring-Framework and Tomcat in combo. We do all our own integration. Lots of folks have made similar middle-tier stack choice. We do get tied to Spring-Framework APIs - just like JEE folks get tied to JEE/EJB. Don't let Spring rhetoric fool you about that one. However, it continues to remain open source accessible to community of users.
Once you go JEE, you get tied to a particular JEE vendor as it's difficult to move between implementations. EJB3 supposedly will ease this, but would bet it will still be a major undertaking to switch JEE app servers.
Frankly Spring-Framework provides more useful APIs than the JEE/EJB standard and it is innovating at a more rapid rate.
I think SpringSource's acquisition of Covalent Technologies puts them in a better position to help anyone using the Spring/Tomcat stack. The Tomcat optimizations that come along with Spring dm Server might be worth as much or more than the OSGi features.
The use of OSGi in Glassfish is misleading. Glassfish is using OSGi internally for the server; OSGi is not available to the applications deployed in Glassfish.
With the Spring dm server, the applications can be written to use OSGi.
Is OSGi an important consideration for you? The only other real OSGi app server is Paremus' Infiniflow. All the other app servers are now talking about OSGi, but it's an internal implementation detail; it's not for the deployed applications.
SpringSource dm Server supports modular applications - you can divide your application into OSGi bundles and share any infrastructure services you care to provide between applications. This gets you away from the monolithic structures such as WARs defined by JEE. Typically this means you get a very rapid edit/save/redeploy cycle during development. OSGi then lets you version modules and the packages they export as well as dynamically update modules without have to restart the whole server.
SpringSource dm Server was built from scratch as OSGi bundles. So you can configure which subsystems of dm Server are loaded if you don't want the standard set.
This is an old thread but I thought it would be useful for people coming across this (as I did) to share the recent GlassFish OSGi enhancements, mainly in the area of OSGi Enterprise RFC's : http://wiki.glassfish.java.net/Wiki.jsp?page=OsgiDashboard
Of course there's also the @Resource-based injection of OSGi Declarative Services that's been there since v3 in December '09.