SpringSource Launches New Application Server without Java EE

| by Floyd Marinescu Follow 38 Followers , Scott Delap Follow 0 Followers on Apr 30, 2008. Estimated reading time: 8 minutes |
One year since receiving 10M in VC funding, SpringSource (the company behind Spring framework) today became an application server vendor, challenging the existing Java EE server establishment with the SpringSource Application Platform (editor's note - SpringSource's Rob Harrop has released further technical details on his blog), an application server built on Spring, OSGi, and Apache Tomcat. The new appserver departs from the Java EE standards, exposing the Spring programming model natively, along with a new deployment and packaging system, built over an OSGi core.  Today marks the beta release under the SpringSource Evaluation license. A GA version will be released with open source (under GPLv3) and subscription versions in one month.

SpringSource Application Platform is not a Java EE application server. While it does support WAR deployment, EAR deployment is not supported nor are some other EE specs such as EJB. The SpringSource Application Platform has been designed from the ground up to instead focus directly on supporting the widely used Spring Portfolio of open source projects. Specifically, the application server builds on the Spring Portfolio programming model leveraging Spring Dynamic Modules for OSGi-based deployment. SpringSource has created a "kernel" of logging, tracing, bootstrap, classloading, management and other features on top of the Eclipse Foundation's Equinox OSGi runtime environment. Tomcat is included as an OSGi bundle to support web functionality. 

InfoQ spoke to Spring framework co-founder and SpringSource CEO Rod Johnson to discuss the new application server.  Explaining the need for thew new platform, Rod pointed to a number of pain points with today's current development/production environments such as the duplication of meta data across configuration files, the fact it is common for projects to in essence deploy a server on top of a server (deploying your application along with many tools and frameworks in the same deployable unit), meanwhile they were mostly using only the web container portion of their appserver. SpringSource as a result wanted to provide a simpler platform based on today's development needs.

On the benefits of the new application server, Johnson emphasized modularity: both for the server itself but also for the packaging and deployment model offered to developers.  By leveraging OSGi and the interworking nature of dependencies among OSGi bundles, a running application server only has active the features needed for the applications running in it, cutting down on the server's footprint and startup time. This dependency support also allows multiple versions of dependent libraries to coexist for different applications. Parts of the application server can easily be updated and restarted without restarting the entire system. From a development standpoint the server's modularity allows for extremely fine grained redeployments to be quickly performed as code changes.

On OSGi and SpringSource's use of Eclipse Equinox OSGi, Johnson praised the foundation that that the OSGi specification and runtimes implementing provide but noted that OSGi can be a bit too low level for every day application development use. Johnson explained that SpringSource wants to enable developers to easily gain value from OSGi in an enterprise context. The new application server abstracts a lot of the complexity of OSGi behind new programming model constructs. He went on to mention that the application server will support a new PAR deployable unit simplifying the use of OSGi for enterprise applications (more on this below)

Asked about legacy support of libraries not natively supporting OSGi, Johnson replied that significant work had been performed so that the application server environment and classloading would behave in a manner compatible with legacy libraries. SpringSource will also be submitting patches back to projects such as Tomcat for any changes they have made to enable a library to be OSGi bundle compatible.

Johnson explained that the majority of application server code would be release under GPLv3 license. Everything that a developer has to commit to in terms of the server, programming model and deployment unit will be available in an open source manner. SpringSource will also provide a commercial version of the application server that includes support, indemnification, management, and monitoring capabilities.

On Java EE and how the announcement of the Spring Application Platform would effect the Spring Portfolio's continued support of Java EE. Johnson responded:

...What we are fundamentally trying to do is NOT push the Spring user community in any direction. We are simply giving them this choice. The Spring philosophy is that the user is always right. They are smart enough to figure out what they want. Regardless of if they take this choice, we think they will be glad to have the option to consider...

Johnson affirmed that SpringSource is committed to ensuring that the Spring Portfolio and other SpringSource products are compatible with other application platforms. Johnson then commented on upcoming Java EE 6 specification:

Java EE 6 is about modularity and is moving [Java EE] in the right direction. It is highly likely that the SpringSource Application server will become Java EE 6 Compliant in some form. There are three profiles A, B, and C. I can very confidently say that we're not going to implement the Entity Beans 1.1 model or several legacy technologies that constitute option 'C'. It is extremely likely we'll implement profiles A and B. I can't say it with 100% certainty however since the specs are not final.

Finally, InfoQ and Johnson talked about the big picture of the SpringSource Application Platform. In terms of the shift to OSGi he commented:

The traditional application server model is becoming obsolete. BEA and IBM are redoing their application servers incrementally using OSGi. SpringSource is providing OSGi support now. You look at the numbers and most people don't deploy to a full blown platform. They deploy to Tomcat. They write their code to the Spring programming model rather than Java EE. The market has already made its choice, the question is how long will developers have to fight their servers.

Johnson explained that he was confident the SpringSource Application Platform would succeed for three reasons:

  • It is the first product that built on a modern technology basis. Java EE compliance is no longer the be all and end all. We've got a competitive advantage because we have a clean new code base. We have designed and delivered to meet the requirements of today and not those from the last 10 years.
  • POJO programming is where the industry is. In the past POJO programming was grafted onto other products kicking and screaming. In our case, POJO programming is the design assumption around what we've built.
  • The OSGi technology used is a fundamental next generation technology.

In addition to Rod Johnson, InfoQ also followed up with SpringSource's Rob Harrop for some of the technical details of the new application server. In terms of what is in/out of stack compared to the traditional Java EE application server he commented:

...JPA and JMS are both supported, but we don't include any particular implementation. In the case of JPA we support Hibernate, OpenJPA and Toplink. We've added support for load-time weaving into the OSGi environment that honours boundaries between applications and doesn't accidentally pollute shared libraries. JNDI is not included, the OSGi Service Registry is used in preference. Servlets are supported via the embedded Tomcat. Things in JEE but not in the SpringSource Application Platform include things such as Entity Beans.

InfoQ next asked about Spring Dynamic Modules. Spring-DM has been a public project for quite a while. From a modular deployment standpoint, Harrop was asked if anything was added to Spring-DM:

The Platform introduces the notion of applications, formed from one or more bundles. The bundles in these applications are explicitly scoped to prevent applications colliding with each other. This is particularly important when you have applications that start publishing services in the OSGi service registry - you don't want those services conflicting with each other.

The introduction of Import-Library has made it much easier to use third-party libraries in your applications. Rather than having to code a lot of Import-Package statements, some of which might not be entirely intuitive, you can use Import-Library to pull in all the necessary packages for a logical library. Libraries such as Hibernate JPA can also span multiple bundles, so using Import-Library really makes a difference.

In terms of extending Spring DM to support running in the Platform, very little was added to the code base.

Harrop went on to describe the new PAR format:

Spring DM powered bundles are normal OSGi bundles that include META-INF/spring/*.xml files that are automatically made into an ApplicationContext for that bundle when it starts. Spring DM provides a mechanism for different bundles to import and export services using a Spring NamespaceHandler.

A PAR (Platform ARchive) is essentially a collection of OSGi bundles, some of which will typically be Spring DM powered. Together these bundles form a logical application. The programming is simply raw OSGi, Spring and Spring DM - the PAR does not change this.

On how the team addressed legacy/non-OSGi libraries in comparison to techniques that have typically been used in the past such as Buddy Classloaders, Rob replied:

It is easier to say what we avoided doing. Buddy class loading, dynamic import and require-bundle are all explicitly avoided due to the difficulties in maintaining consistent class spaces. We also avoided providing any proprietary alternative mechanisms.

Instead, we added some low-level hooks into Equinox to make resource loading work in the typical cases, we extended class loading to support load-time weaving and throw away loading semantics and we manage the context classloader to allow third-parties to see classes as expected. The PAR is a central part of this since it defines the scope of visibility for context class loading and load-time weaving.

In the worst cases, we created patched versions of libraries to make them work in OSGi, and we are making these available via the SpringSource Enterprise Bundle Repository as well as submitting all patches back to the relevant projects.

Finally Harrop highlighted the benefits of the application server's modularity revealing that it allows the application server to maintain a minimal footprint. The platform provisions dependencies on the fly so a running instance only has installed exactly what it needs. 

The last couple of years have seen many discussions about whether the Java EE standard is dead, today we have seen the launch of what may potentially be the next major appserver, without Java EE support. How do you see this changing our space going forward?

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Wow by Vic C

Let me pick up my jaw of the floor.

Ahh. Congrats to the Spring Team!

Very interesting, but I did not see anything on the site or anything I can download.


Re: Wow by 胡 键

great! but why GPLv3?

Re: Wow by Adrian Colyer

Creating an application platform that makes the benefits of OSGi available to end users was a huge investment for us. There's a *lot* of technical innovation under the hood which won't be immediately apparent but which enables us to make a generational leap. If we're giving that technology away in open source, we wanted others who build on it to also give away the results in open source.

Re: Wow by Stefan Tilkov

Why GPLv3?

To ensure nobody except SpringSource makes money selling this? :-)

vendor-independence? by Kristian Rink

I generally like the introduction of OSGi to this kind of development, but there's one thing I really dislike about it: Even though it is "open source", it somehow breaks with one interesting reason why to choose Java EE - the freedom to choose products offered by different vendors basically built upon the same foundations (EJB, ...). As a perspective, I hope the different worlds (Spring, OSGi, Java EE) to merge to a homogenous platform also independent of a given container/server (tomcat). So far, even though the idea is challenging, it seems a step backward compared to .war applications easily deployable to virtually any servlet container one could stumble across...

best regards,

Re: Wow by richard nicholson

Those of you interested in a next generation distributed OSGi runtime that supports SpringDM (on Equinox, Felix & Knopflerfish) should check out the following article article, and the Newton project at

Before anyone asks, Newton is also GPLv3 (actually AGPL). Why? Because Paremus do not believe in "donation-ware". We're a commercial company with developers wages to pay and investors to answer to.



Re: vendor-independence? by Neil Bartlett


I share your concern, but in theory it should be addressed by the use of OSGi. In other words, if you write bundles that comply with the OSGi standard then they will deploy to SpringSource's Platform and also any other platform that exposes OSGi to end users.

Such platforms are frankly available already, since not everybody shares SpringSource's apparent belief in the need for a thick layer of abstraction over the OSGi specification. I still need to see the details of this new platform (i.e. when they actually release it) but my feeling at the moment is that many requirements can be satisfied just fine without it.

That's not to say I don't see any value in their proposition -- the Spring-DM layer in particular has been available for a little while now and is already proving useful in production systems. One very attractive thing about the Spring Framework has always been its modularity, meaning you can pick and choose the parts that interest you, and OSGi makes that even easier to do.


Re: Wow by Christopher Brind

Similarly, Arum have released "Solstice" which is an OSGi platform but geared to developing Flex based rich internet applications. At it's core though, it is just an OSGi container (specifically Equinox). The main difference is our container is in the app server rather than having an app server in the container - the road map for the product does include flipping this on it's head though, just like SpringSource's new application platform. You can download it here:

Re: vendor-independence? by Rob Harrop


The programming model for applications on the SpringSource Application Platform is fundamentally Spring, Spring Dynamic Modules and OSGi. We have a few extensions to the OSGi manifest syntax that make common tasks easier, but you are free to write an application using standard OSGi constructs and still get all the benefits of the Platform. I'll be posting a blog later today that has more detail on this.

Our web support runs on Tomcat and thus supports the Servlet spec. We support JPA for persistence - including extensions to make load-time weaving work nicely in an OSGi environment.

The Platform not only supports many existing standards, we are also taking a wider view of standards than the JCP-centric view that is typical in Java EE today.

Rob Harrop

how loosely coupled is the PAR? by Christopher Brind


If I was to deploy an application as a PAR (from what I understand a collection of OSGi bundles that logically make up an application), can I still manage those bundles individually? That is, perhaps my application consists of a branding bundle which is deployed by default to my customers, but after the deployment I want to replace that bundle with something more specific to my customer. Can I uninstall the bundle original deployed as part of the PAR and deploy my other one?



Re: vendor-independence? by Rob Harrop


If you are building OSGi bundles from scratch then I have no doubt they will run on a plain OSGi service platform. If you want to build enterprise apps that use existing libraries, and run many of these apps on the same platform then OSGi on its own doesn't really cut it.

Also, to be clear, we *don't* have a thick layer of abstraction on top of OSGi - applications are written using standard OSGi constructs in conjunction with Spring and Spring DM. Underneath all this we just do a *lot* of work to make these semantics work in an enterprise setting.

Two examples of this that spring to mind are load-time weaving and application isolation. Supporting load-time weaving in a JPA context is not something that is easily done on a standard OSGi platform. With application isolation we allow for many applications to be deployed without worries over type and service clashing.

The 'abstraction' we have is essentially two more manifest headers: Import-Library and Import-Bundle, which are effectively macro forms of Import-Package - no semantic changes at all. Of course, you are free to use Import-Package if you choose.

I'll be posting my blog entry on this topic later today once I've but the finishing touches to the release package :)




Re: vendor-independence? by A D

This *IS* a step backwards. Spring was fine as a framework (wrapper) but I am not sure if the a custom vendor specific "App Server" is a good idea (this isn't 199%). You can get almost everything using Glassfish/OSGI bundle and stay vendor independent

Re: vendor-independence? by Christopher Brind

I'm inclined to agree with both of you. One the one hand, I competely agree that J2EE is a dying breed, so I am happy to see another OSGi container available, though Equinox is good enough for me in most cases and if not I would probably look at using ProSyst's enterprise version of Equinox. Don't forget you also have Felix and Knoplerfish. In theory any OSGi compliant bundle should run on any of these platforms, just like a WAR should deploy to any J2EE compliant application server.

So what have SpringSource done here? Like you say Kristian, SpringSource apparently believe in the need for a thick layer of abstraction over the OSGi specification, but for me the OSGi specification is more than adequate for all my needs. Occasionally I create a "BaseActivator" which is an abstract implementation of BundleActivator for use across a common application shared by an application specific bundle, but other than that I see no need for an abstraction layer on top of OSGi.

Think back 8 years or so and this is similar to what what happened with J2EE. There was a sudden belief that the J2EE specification required an abstraction layer and frameworks such as Struts were born. While they promised reuse all they really did was increase the learning curve and add bloat to your application.

Now with SpringSource releasing an OSGi container which leverages Spring technology I don't think you will get the bloat factor that those J2EE frameworks gave you, but you will certainly get the learning curve. While OSGi is fine for me and I feel like I can produce OSGi bundles and applications effectively I can't be bothered learning "Spring" so I'll just continue as I am.



Re: Third party bundles by Rob Harrop


It's great to hear that you have OSGi-ready bundles already. So few libraries are there at the moment - it was a huge amount of work to get our repository up and running. I'd be happy to run DataNucleus up in the Platform JPA test suite to see how it fairs.




Re: how loosely coupled is the PAR? by Glyn Normington

No, you can't do that because the platform scopes the bundles of a PAR to the application. To do what you describe in a simple way, break the branding bundle out of the PAR file and deploy it separately.

Alternatively, a slightly more complex solution, if you need to keep the packaging as a single PAR, is to package the bundle inside a library and include the library inside the PAR file.

Glyn Normington


modules and aspects? by andrew mcveigh


(I'm a spring neophyte, so if the answers are available elsewhere, just point me to the link ;-)

How do aspects and modules interact in Spring? i.e. I presume that things like aspectj can still be used within a module? What about for situations which cross module boundaries -- where the class being communicated with comes from a different module?

Also, how does this affect the definition of things like pointcuts? Do these have to be explicitly annotated with a module version as well as a class now?


Re: vendor-independence? by Rob Harrop


The Platform is *not* an abstraction layer on top of OSGi. You are free to take any of the bundles you create for the Platform and run them on any OSGi platform. The benefit of the Platform is it makes the development of enterprise applications work under standard OSGi semantics.

Over the last 18 months we have been watching people build enterprise applications running on OSGi and Spring DB so we *know* that its not as easy as it should be. We made a promise to make OSGi enterprise application a reality - and to do that we had to build a Platform that smoothed out all the underlying issues with existing technologies so that the OSGi model would work as expected for users.




Re: vendor-independence? by Rob Harrop

A Dawle,

I wasn't aware that Glassfish is exposing OSGi as a user-level model, I thought they were just using OSGi internally for modularity ala WebSphere. Googling around certainly didn't point to anything suggesting that you can *use* OSGi in Glassfish so apologies if I am missing something.

Using OSGi to build a server platform great, but it doesn't really allow users to experience the full power of OSGi. The SpringSource Application Platform is built on OSGi *and* exposes OSGi as its programming model along with Spring and Spring DM.




Re: vendor-independence? by Rob Harrop

I, of course, meant Spring DM and not Spring DB :)



Re: modules and aspects? by Rob Harrop


For AspectJ static weaving, you are in full control over exactly which classes get woven with which aspects.

When using load-time weaving, and this applies when using JPA instrumentation, it's a different matter. The SpringSource Application Platform allows for load-time weaving, driven by JPA or by Spring's load-timing support. The Platform handles the creation of throwaway ClassLoaders and ensures that within an application, weaving can propagate across the modules of that application. Further, the Platform will prevent weaving in one application from interfering with another application or with a shared library.




Wait... Tomcat?? by Thom Nichols

What does Tomcat have over Jetty? As Spring has always attempted to provide an agile platform, I would have thought Jetty would be the obvious choice. Given that its embed-ability, hot-reload and Comet support make it much more developer friendly.

Re: Wait... Tomcat?? by Rob Harrop


We chose Tomcat because it's what the majority of the Spring community is using. Most operations teams at our customer sites are comfortable with Tomcat so we wanted to make this a minimal step for people who are already familiar with Tomcat.




Re: vendor-independence? by Sébastien Arbogast

For me, the main showstopper was definitely support for runtime weaving: it is a well-known issue that Hibernate and bare OSGi don't get along very well because of the fact Hibernate relies on runtime weaving. So just that is an enormous benefit I see in SSAP.
Another important aspect is the concept of an application server distribution. One of the main challenges I've had with OSGi was to gather all the minimal bundles needed to set up a working application server. Your Solstice distribution definitely helped a lot on that, but mainstream support from Spring is very appreciable and should greatly improve time-to-market of our applications.
Last but not least, when your application already uses Spring application context configuration, it's really a pain to have to write OSGi service descriptors, so Spring Dynamic Modules helps a lot for that.

Anyways, I knew SpringSource was working on something like that from the day they announced their acquisition of Covalent, and I'm very excited to see how it continues to challenge old school standards and ease our developer life.

Re: Wait... Tomcat?? by Neil Bartlett

It's worth pointing out that if you do have a preference for Jetty, it should be very easy to use since it ships with OSGi metadata out of the box. Jetty has been favoured by the OSGi community for a while now thanks to its ease of embedding. Of course it should be no surprise that SpringSource favours Tomcat, given their recent acquisition ;-)


Abstraction and history by Rod Johnson

Think back 8 years or so and this is similar to what what happened with J2EE. There was a sudden belief that the J2EE specification required an abstraction layer and frameworks such as Struts were born. While they promised reuse all they really did was increase the learning curve and add bloat to your application.

I would argue that it was frameworks--beginning with Struts--that made J2EE successful, after a very poor first few years. Prior to Struts, the majority of web applications were "Model 1" JSP hell or home-grown Front Controller Web MVC frameworks, mostly pretty poorly designed. Furthermore, every project was significantly different, so the learning curve when developers moved projects was unnecessarily large (no books, trainings etc).

The need for such frameworks was (and is) very real.


Re: Wait... Tomcat?? by Glyn Normington

The only problem with Jetty is that, unfortunately, its bundle manifests are not strictly OSGi compliant.

For instance, the export-package statement in the jetty-util bundle contains the package name "org.mortbay.jetty.jetty-build-resources" which, of course, isn't a valid package name. Some OSGi containers let this slip through, but the Platform's Antlr-generated manifest parser spots the anomaly.



Re: Wait... Tomcat?? by Neil Bartlett

Interesting. This appears to be a problem with the experimental 7.0 release, and should probably be raised as a bug in the appropriate place! Also against the OSGi frameworks that let it through, which include Equinox.

Wow, crazy... by Jason Carreira

What a crazy ride it's been over the last several years... From challenging the establishment to becoming it ;)

Congrats guys... Maybe this will be the thing that finally gets me to look at OSGi...

Re: vendor-independence? by Shaun Smith

Hi Rob,

Congratulations on your announcement!

Regarding your comment on load time weaving being challenging "on a standard OSGi platform" I have to agree but your app server is built on Equinox which does have class loading hooks that can be used to perform weaving. I know because I've just got load time weaving working in Equinox for EclipseLink JPA and the Equinox Aspects project is also doing it. :-). My point being that load time weaving is possible with the Equinox platform you're building on and is a feature you can use without the SpringSource Application Server.

Sorry to nit pick,


Re: vendor-independence? by Rob Harrop


We use the class loading hooks in Equinox to support LTW on the Platform. The big challenge is making sure that weaving works across bundles, that you can do proper throwaway class loading, and that you can scope the weaving so that two applications running in the same OSGi container won't interfere with each other.

The big benefit is that none of this affects the user - they just see standard Spring and JPA configuration and the load-time weaving just works. And it works for AspectJ and OpenJPA as well - in fact anything that is supported by Spring's LoadTimeWeaver runs in the Platform.



Downloads and Blog Entry Available by Rob Harrop


I have posted a blog entry that gives an overview of the SpringSource Application Platform here.

Downloads are now available from here.


Re: vendor-independence? by Jerome Dochez


Although you are right when saying GlassFish is using OSGi internally for modularity we also have developed extensibility points (container, commands, configuration and finally administration console) so that any type of application container can be added to GlassFish V3 (this is how we currently support Rails, Grails and other non Java EE container natively, without complicated war repackaging).

So nothing prevents SpringSource from developing the few required OSGi services that would allow GlassFish V3 to recognize the Spring+OSGi application types and deploy such applications to your container. We are certainly not hiding the OSGi APIs from the user. Becoming a V3 container would therefore give users the ability to use your technology alongside Java EE technologies and any other V3 container for that matter.

So it completely possible for you to become a GlassFish V3 container, offering the full OSGi APIs to your applications, yet giving users the choice of using or mixing other types of applications alongside yours. I believe this is what Dawle was suggesting.

Also remember that GlassFish V3 will only start the container you actually use so even if you have configured V3 with Spring, EJB, Web, Rails, Grails containers, and you only end up using one of them, the other containers won't be started removing the bloating effect that traditional application servers have.

Hope this clarifies

Jerome Dochez
Sun Microsystems, Inc.

Re: vendor-independence? by Rod Johnson


We would love to cooperate with Sun in future. Both GlassFish and the SpringSource Application Platform are going to be around for the long term, so they will need to coexist. Once a solid GlassFish release is out and there are more details available about how it works with OSGi, it will be easier to see how this could work out. If Glassfish can accept standard OSGi bundles, that should provide a very good basis for integration.

We are in strong agreement regarding the "bloating effect that traditional application servers have". I think Sun's recognition of this is helping driving some of the positive changes in Java EE 6.



Re: vendor-independence? by Rob Harrop


Thanks for clarifying that for me - my understanding was't quite right :). I'd like to understand more how GlassFish works for users who want to deploy raw OSGi bundles on to it. Perhaps we can continue a discussion offline - ping me at rob.harrop ( at )



Congrats by Stephan Janssen

First of all congratulations towards to complete SpringSource team for the perpetual innovation!

I'm really looking forward towards the potential convergence of the "lightweight" Spring framework and Java EE 6 (Web) Profiles. I truly hope that both the EJB 3.1 and JPA 2.0 will also have a place in this new OSGi enabled (web) server. This potential (web profile) EE strategy would also allow a nice migration path for the existing Java EE 5 projects (yes people are doing projects today with JSF, (Seam), EJB3 and JPA).

The Java EE 5 RI app server, Glassfish V3 does work with OSGi so some interesting synergies are definitely possible!

The Next Gen. JBoss Company is born... I just hope Oracle can wait a few extra years ;)


Re: Wait... Tomcat?? by Greg Wilkins

as Neil says, the illegal package name only appears in our 7.0 experimental version.

We have long worked with interface21 and now with springsoft to make Jetty a viable choice to work with spring and your OSGi framework. We often have received feature requests from your organization and reacted quickly to get them into the next build cycle.

So some at least within your organization do value integration with Jetty.

Re: Wait... Tomcat?? by Glyn Normington

Hi Greg. Glad to hear the invalid packages are a temporary glitch. Compliance with the OSGi spec. is the best way to ensure portability across containers.


possible trend to start? by serge ----

If spring source is successful, which I am sure it will be, I wonder if other vendors will start to deviate from providing java ee support. I wonder if this is the turning point for Java EE.

Re: vendor-independence? by Graeme Rocher

so that any type of application container can be added to GlassFish V3 (this is how we currently support Rails, Grails and other non Java EE container natively, without complicated war repackaging).

Jerome, although as you know we at G2One Inc. support your efforts in making Grails run on Glassfish I must point out that Grails is a standard Java EE framework and requires nothing really special to make it run natively on a container.

We support all the major containers ( and Grails runs successfully on the Spring Platform (

I just want to clear that up as readers who read your post may think Grails is some alien platform requiring its own container.

Tool support by Mik Kersten

In case anyone is interested in the IDE support, I posted a couple of teaser screenshots. Watch the SpringSource blog for more info on tool support.


Mik Kersten
President & CTO,
Project Lead,

Re: vendor-independence? by Rod Johnson


That's great. Quick work! The fact that Grails runs successfully on the SpringSource Application Platform demonstrates its ability to honor the WAR deployment format.

It would also be interesting to explore how Grails may benefit from the OSGi world, as a poster suggested on your blog post.



Re: possible trend to start? by Floyd Marinescu

If spring source is successful, which I am sure it will be, I wonder if other vendors will start to deviate from providing java ee support. I wonder if this is the turning point for Java EE.
I think it is.

You can't keep a good idea down by Mark Turansky

I was excited to read about Spring's new app platform if only because a lot of their features sound exactly like some of the features I sold to my company for an internal project.

Network deployed, hot swappable, multiple apps with multiple versions, Service enabled, etc.... We wrote these very same features for our project, and having Spring and OSGi validate what we did is a warm fuzzy for me.

You can't keep a good idea down.

I only wish we were able to open source our project. We'd beat SpringSource to the punch, plus we have a whole bunch of messaging functionality (queuing, routing, competing consumers, etc.) baked into our's.

Re: vendor-independence? by Graeme Rocher

It would also be interesting to explore how Grails may benefit from the OSGi world, as a poster suggested on your blog post.



Hi Rod,

Indeed, one idea we're having at the moment is to make Spring DM power our plug-in system ( which supports functional and technical plugins that add all sorts of capabilities to Grails. For example you could have a blog plugin or a forum plugin and use OSGi to start/stop/upgrade these services



Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

45 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you