Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Reactions to Licensing, OSGi, and Technical Aspects of the SpringSource Application Platform

Reactions to Licensing, OSGi, and Technical Aspects of the SpringSource Application Platform

This item in japanese

As first reported by InfoQ two weeks ago, SpringSource recently announced a beta release of the SpringSource Application Platform. Lively discussion resulted on our own story and on The Server Side's coverage as well. In the weeks that have passed, developer and industry pundit commentary has been centered around one of two areas, Licensing/General Strategy and OSGi/Technical Implementation.

Licensing and General Strategy

As with any announcement of this magnitude, people will find both good and bad items to highlight. Phil Zoio on the Impala project (which is creating a solution similar to Spring-DM licensed under the Apache License 2.0) blog had the following to say: essentially a Spring OSGi integration on steroids. I've voiced concerns on how well OSGi is going to be received by ordinary developers, as against application server vendors. I'm yet to be persuaded that regular Java developers will be particularly enthusiastic about dealing with the idiosyncracies of OSGi...there is the question of the license. For the first time, SpringSource is introducing a major product which is not based on the Apache V2.0 license, instead going for a GPL license. That's a major change that reflects a real difference in the way that the company is positioning itself in the marketplace ... Finally, the question in my mind is where the Spring Framework itself fits into all of this. I've always thought of the Spring Framework as the flagship product coming from the Rod Johnson crew. ... But with the Spring Application Framework, they're betting big...

Per Olesen on the other hand seems enthusiastic about the product and the license:

...I am already utilizing the springframework as my main engine and have long time gone the POJO ORM way. All this way before JEE5 and JPA. And I like it. I have even ditched using JEE5 EJBs on new products, because I find the spring model superior in many ways. And about it being proprietary. The platform is GPLv3 licensed, which I really like. In my eyes, the GPL license model is good for exactly this kind of product. It ensures openness, also when utilized by others, which adds or enhances it...

Billy Newport of IBM provides an appserver vendor angle:

...It looks like what others and I have been planning/hoping to do over the next few years. Most of us are looking for an OGSi based distributed platform with a commercial friendly license (EPL, BSD or Apache) ... So, to summarize, I don’t see the platform as the valuable thing. I see it as a commodity. I see profiles and monitoring profiles as the valuable thing and I’d like to see a commercial friendly licensed OSGi distributed runtime as the new JVM that vendors build middleware/profiles for. Given, Spring DM is Apache licensed, I can see the extra work in the Spring server being clean roomed and made available with EPL or Apache pretty soon and this will limit the value from selling the SpringSource server ... I don't want to trivialize what SpringSource has done, it's very cool and it's needed but given most of its components are Apache 2.0 or EPL then the last gap is a lot simpler than building a Java EE or BPEL flow engine, thats all.

IBM Fellow Jerry Cuomo also comments:

...An article on InfoQ, broke the story and my Inbox lit up like a Christmas tree. Subject lines cited – “SpringSource is declaring war on WebSphere.” Really? I don’t quite see it that way. Let me start by saying this… I’m a fan of Spring, and I think that a foundation of OSGi and technologies like Spring framework are the future of Java-based application serving. The days of one-size fits all servers are evolving towards purpose built servers that specialize in specific types of workloads ... Now, I do feel it’s a shame that SpringSource went off and did this under a GPL license. The industry would benefit from an Apache-licensed “reference” application platform ... Hence, the trend of evolving towards a platform with a right-sized, multiple personality complexion is not a disorder, nor a pending war between SpringSource and WebSphere –it is just the way the industry is evolving– and perhaps the Java community can pull together like it did before and produce a level field of opportunity. Our customers really appreciated this, the last go around...

Finally, no roundup of reactions would be complete without the musings of Marc Fleury (formerly of JBoss):

Truth is, I care a little bit but not a lot. To me this is a VC driven move. Spring is a natural consultancy, being a development framework, but they have been struggling with their sales in the runtime. So voila, we now have a box drawn around an OSGi kernel ... Finally I am fuzzy on how this impacts their relationship with other app-servers. They are not neutral anymore ... Look guys, the application server wars were fought and over by 2005. We are in 2008 with POJO programming everywhere, lite programming models in EE.

OSGi and Technical Aspects

In parallel to the expected strategic commentary, the SpringSource Application Platform announcement also generated responses from a number of developers active in the OSGi community. Neil Bartlett found a number of positives includes its general use of OSGi, the announced bundle repository, and SAP solving the where do I start with OSGi problem. He was concerned with the new bundle headers however:

...Now, here are the things I’m less than thrilled about ... There are two new bundle headers, Import-Bundle and Import-Library. As far as I can see, Import-Bundle has exactly the same problems as Require-Bundle. The new header simply provides indirection, i.e. you supply a logical bundle name rather than the actual Bundle-SymbolicName. This doesn’t fix the issues with binding to the wrapper around a set of packages rather than the packages themselves. Import-Library appears to be even worse, as it performs an Import-Bundle over a whole set of bundles at once!...

Peter Kriens had similar thoughts:

...The bundle repository was in one word: stunning. ... This bundle repository must have been a terrible job to do. Kudos! ... The Spring Source Application Platform was, however, a bit of a shock. Looking through the documentation I found lots of headers that felt like OSGi but that I did not recognize: Import-Library, Import-Bundle, Application, etc. It looked like SpringSource had “improved” OSGi extensively...

The SpringSource team also produced several blog posts detailing various aspects of the application platform:

Running Spring Applications on OSGi with the SpringSource Application Platform

  • Load Time Weaving
  • Classpath scanning
  • Thread context classloader management

SpringSource Application Platform Deployment Options

  • Raw OSGi Bundles
  • Java EE WAR
  • Web Modules
  • Platform Archive (PAR)

SpringSource Application Platform Manifest Headers

  • Import-Bundle
  • Import-Library

Working with SpringSource Application Platform's provisioning repository

  • Runtime provisioning
  • Adding items to the provisioning repository
  • Sharing the provisioning repository between installations

One of the main advantages of the SpringSource Application Platform is its ability to provision dependencies on an as-needed basis. The benefits of this are two-fold: it ensures that the Platform's memory footprint is as small as possible and it allows applications to be deployed without encapsulating all of their dependencies in a monolithic deployment unit, e.g. a WAR file. To take advantage of these capabilities you will require an understanding of the Platform's provisioning repository and this blog intends to provide just that...

Rate this Article


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.

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

Community comments

  • Real life advantages of OSGi?

    by Michael Burke,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Excuse my naievete.

    As someone developing a large enterprisey system with a fair number of (strictly managed) dependencies, what does porting my application (an EAR + WAR) from <conventional app server> to SAP do for me?

    This nifty technology around provisioning dependencies sounds.. nifty, but shouldn't your application be explicit about defining and providing its dependencies?

    Why do I need to delegate 'go get my servlet JAR' to the app server? What benefit does this give to a typical enterprise app with a long lifetime and strictly controlled dependencies?

    What are the other benefits that would convince me to move platforms? I realise that there's support for hotswapping components, but if, again like a typical enterprise app, my upgrades are strictly controlled and scheduled - what am I gaining here?

    What are the real life gains I can expect from going through an effort to 'port' to OSGi? Real benefits please, that you've seen from a real life deployment, not bullet points from a marketing brochure.


  • Re: Mr Fleury

    by Adrian Colyer,

    Your message is awaiting moderation. Thank you for participating in the discussion.


    I'm not going to reveal the exact size of the development effort for the SpringSource Application Platform, but let me at least say it took several person-years of some very smart people to get to this stage. That's not the kind of sizing that a lightweight integration takes. Making OSGi work for enterprise application development, and with existing enterprise application libraries was a lot of work. Plus even forgetting the end-user OSGi support, the dm-kernel itself provides for an excellent server platform with a lot of attention to detail paid to things like efficient threading models, deadlock detection, per-application trace logs etc..

    -- Regards, Adrian.

  • Re: Mr Fleury

    by A D,

    Your message is awaiting moderation. Thank you for participating in the discussion.


    Who cares if it took several man years of "very" smart people to create this box around OSGi? What people do care about is the business value a product brings, ease of development, standards availibility of talent, ROI and vendor-lockin..the list can go on. Unfortunately Raher than focusing on these issues , only thing Spring is using to promot S2AP all the time is
    - OSGi and it's integration
    - FUD (about JEE)

    I am not sure if this is going to win you many friends in the community that has started to question the "real" value of spring.

    Good luck to you (and your investors)!

  • Neil

    by Rod Johnson,

    Your message is awaiting moderation. Thank you for participating in the discussion.


    Let me first deal with your comments about VC funding. The fact that SpringSource is a rapidly growing company is immensely positive for Spring. Look at the huge amount of quality Spring releases that are resulting: Spring 2.5, Spring Web Flow 2.0, Spring Security 2.0, Spring Web Services 1.5, Spring Batch 1.0... All deliver real benefits from users, and we've never been able to deliver this much code in such a short space of time. The growth and success of our business is good for Spring and good for those who build and run Spring applications.

    Demonization of VC-funded companies is lame and superficial. Nearly every great software company has been VC funded. VCs and strong businesses are a necessary part of the software landscape. Take some leading enterprise Java solutions--Spring/Eclipse/Hibernate/Tomcat: all have benefited from either investment of large companies, or VC funding. At some point your buddies at Paremus will either get funded, acquired or fail to be able to realize their technology vision, and let all their users and customers down. They've got more chance of getting where they want to from an engineering perspetive if they go down the first route.

    There has been no change of direction at SpringSource: merely progressive execution of our plan to be take a leading position in enterprise Java. As for "Spring will no longer feel like "our" product - but SpringSource's": the people behind Spring are the people behind SpringSource.

    We chose in late 2006 to raise money in order to build the next-generation stack. We're proud we've accomplished that. Our company had been running for 3 years when we raised funding. We were already a real company with real technology. We had a choice of investors who wanted to buy into our vision. Anyone who has observed me over the years--whether they agreed with me or not--should be in little doubt that I am not likely to be an investors' puppet.

    Enterprise Java needs a transformation. We've helped to drive that with Spring and our longstanding thought leadership. There's further to go and we're proud that we're continuing along the route.



  • Re: Real life advantages of OSGi?

    by Adrian Colyer,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Michael, this is a great question and deserves a thorough answer. I started on the answer but it turned out to be longer than can comfortably fit in a comment. When I finish writing it up I'll post it on the SpringSource blog and put a link here...

  • Re: Mr Fleury

    by Rob Harrop,

    Your message is awaiting moderation. Thank you for participating in the discussion.


    Who cares if it took several man years of "very" smart people to create this box around OSGi? What people do care about is the business value a product brings, ease of development, standards availibility of talent, ROI and vendor-lockin..

    This is why we focused on developing a model that solves real problems today. As applications get larger, a robust mechanism to modularise said applications delivers real value to teams who are struggling to meet the demands placed upon them.

    Availability of talent shouldn't be a problem, applications written for the Platform just use Spring, standard Servlet APIs and standard OSGi.

    Going further, it's hard to see how coding to standard, widely accepted models can be seen as vendor-lockin.

    the list can go on. Unfortunately Raher than focusing on these issues , only thing Spring is using to promot S2AP all the time is
    - OSGi and it's integration
    - FUD (about JEE)

    OSGi is a big part of the Platform so highlighting our integration there is hardly 'unfortunate'. As to spreading FUD about JEE, I'm not sure that is entirely the case, in fact we are actively engaged in Java EE 6 and we committed to implementing some of the upcoming profiles on the Platform.

    Good luck to you (and your investors)!



  • Re: Mr Fleury

    by Adrian Colyer,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    "A", my only point in mentioning the development effort involved is that it should clearly indicate there is something more substantial going on than a mere surface integration of the technologies involved. Michael (above) asks a great question: (paraphrasing) ignoring the hype about OSGi, what benefits should I expect to see from moving a traditional JEE application to OSGi? I intend to answer that question fully in a separate posting.

    You seem confused about the relationship between "Spring", "SpringSource" and "S2AP".

    "Spring" (as in the Spring Framework) is an open source Apache-licensed project, which together with a number of other "Spring xxx" projects (e.g. Spring Security, Spring Web Flow, Spring Web Services, ...) is made freely available from "Spring" cannot promote S2AP, and the Spring Framework remains unchanged by this announcement. It is still exactly as it was, and will run happily in a wide range of Java environments.

    "SpringSource" is the company behind the Spring Framework, and the entity that has developed and is promoting the SpringSource Application Platform (S2AP).

    "S2AP" is an open source product developed and released by SpringSource, and made available from The availability of S2AP in no way changes the 'real' value of Spring (perhaps you can make a case it increases it, because now there is a new deployment option...). Anyone who wants to is free to deploy Spring-based applications on S2AP, and they are equally free to deploy them to any other platform.

  • Re: Neil

    by Rod Johnson,

    Your message is awaiting moderation. Thank you for participating in the discussion.


    "Buddies" is not offensive. At least here in the US. You're jumping to conclusions. As for Paremus, I wish them luck and wasn't attacking them or you. And I stand by my conclusion that the best thing they could do for their business and their technology is to raise funding, and that attacking us for doing likewise is unreasonable.

    As for "comments I did not make". Let me quote from what you wrote:

    It just seems the inevitable effect of VC funding (more marketing - no more innovation) is kicking in

    That was not a technical argument. I'll leave it to others to respond on technical matters. I was responding to your irrelevant comments on our business, which I felt it was important to correct.



  • Re: Mr Fleury

    by Adrian Colyer,

    Your message is awaiting moderation. Thank you for participating in the discussion.


    I don't doubt the considerable effort that has gone into the Spring Framework

    Like "A" above, you seem to be confused about the relationship between S2AP and Spring. It's true that an incredible amount of effort has gone into building the Spring Framework, but that is totally independent of the investment made in building the SpringSource Application Platform. I won't repeat the clarification here, please see my answer to "A"'s post above instead.

    I am aware of Newton and Infiniflow (I'll just refer to the core product as "Newton" from now on for the rest of this post). Newton and S2AP attack different problems. Newton is very much focused on the creation of a distributed system (from the Newton project home page, first paragraph answering "what is the Newton project?":

    Newton is a distributed component framework in which the components can be simple POJOs or wrappers around components based on other models.

    S2AP is not attempting to provide a distributed component framework. It shares in common with Newton the use of OSGi and the use of Spring and Spring Dynamic modules (described in Paremus's own EclipseCon presentation of March this year as "one of the most advanced POJO frameworks available in the market place today") as a foundation for building applications within a single JVM, but there the comparison really ends. Newton is focused on creating an intelligent distributed computing fabric, S2AP is focused on providing a solid foundation for running Spring-based enterprise applications of the kind being deployed today on servers such as Tomcat, JBoss, GlassFish, WebLogic, and WebSphere. Our innovation does not manifest in a broad new API or surface area, it is in doing a solid job of making the model work for Spring-based enterprise applications of the kind being deployed today. To borrow a phrase, if you are unsure of the difficulties involved in doing this, try reading through the archives of the spring-osgi mailing list and see the difficulties that people have been having trying to get enterprise applications working smoothly on OSGi.

    In closing, let me repeat my point that S2AP and Spring are completely different projects - you seem to be drawing conclusions about Spring itself from discussion of a completely different entity. With regards to Spring itself, we are obviously listening to different voices because the ones I'm hearing in droves are all asking for advice on standardizing on the Spring Framework across their development organizations.

  • Re: Neil

    by Rod Johnson,

    Your message is awaiting moderation. Thank you for participating in the discussion.


    I didn't mean to offend you, and on re-reading I see that "demonization" was stronger than I intended. I apologize.

    it just seems the inevitable effect of VC funding (more marketing - no more innovation) is kicking in

    I hope you take a closer look at the Application Platform. I think you'll then see that we are very focused on tackling hard practical problems around OSGi and delivering a truly innovative solution.



  • Re: Real life advantages of OSGi?

    by Adrian Colyer,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Here is the reply I promised earlier.

  • Re: Neil

    by Neeme Praks,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Let's be clear, I'm not hitting in at some marketing angle, I'm genuinely disappointed at the rate _all_ application server development is happening at. Writing distributed applications today is not much simpler than it was 7-8 years ago and that sucks, doesn't it? I suppose I'm just frustrated that people like yourselves who are in a such good position to push that envelope don't appear to be doing so right now.

    As is Newton, the fact that it can do things that S2AP can't doesn't infer that it can't do things S2AP can. Newton is perfectly capable of acting as an OSGi application server that is a simple but valid use and it certainly can deploy applications "of the kind being deployed today on servers such as Tomcat, JBoss, GlassFish, WebLogic, and WebSphere".

    But really it's not about S2AS vs. Newton or Spring vs WebLogic etc. - I'm sure you guys will make a darn good job of S2AP; what I'm interested in is solving the real and tough problems we have today in distributed enterprise environments. For the 80% of people who need to worry mostly about Hibernate and web apps they're pretty sorted already - it's those of us who keep finding ourselves in the last 20% (or even less) who need just a little more help :-)

    A bit of background:

    I'm in the process of evaluating different runtime environments to use as the backbone for the next generation of our company product family (location based services). And so far I have had plans to use Newton as that backbone (due to the distributed computing support). With the release of S2AP, I have also looked briefly at using that instead.

    So, I would compare these two platforms like this:

    • Newton - has excellent support for distributed computing. I have no information available if Newton also takes some effort to make Spring-contracts work in OSGi environment.

    • S2AP - has support for making Spring-contracts work in OSGi environment (load-time weaving, etc). But the part of making the whole solution work in a distributed manner is still left on the shoulders of the application developer.

    Now, can I somehow take the best of both worlds/products?

    • question to Neil (as the best Newton expert available on this thread) - does Newton do some magic (similar to S2AP) to make Spring-contracts work in OSGi environment? For specific description of that magic you can refer to the blog post that Adrian posted above.

    • question to Adrian - as both Newton and S2AP are based on OSGi, I could "just" combine those two products, right? Maybe you even have plans for doing something like this (borrow stuff from Newton) in S2AP roadmap? Can you predict the amount of engineering required to make this work?

    I guess other people on this thread would also find answer to these questions interesting.


  • Re: Neil

    by richard nicholson,

    Your message is awaiting moderation. Thank you for participating in the discussion.


    I'd just like to jump in and answer the specific questions you raised.

    Question to Neil:

    Not quite sure what you mean by "Spring-Contracts", but I can comment on Load Time Weaving.

    Newton fully supports Spring-DM. Spring-DM (I believe) doesn't support load-time weaving; this a current OSGi limitation. The reason for this is as follows:

    1. OSGi bundles are limited to using code from packages they import, as defined at compile time.

    2. Load-time weaving potentially changes the code a bundle uses, making it necessary to use code from packages that aren't imported.

    3. They can't -> Bang The OSGi Alliance are well aware of this problem and currently working on a standards based solution.

    Paremus will fully support these capabilities once standardized by the OSGi Alliance.

    Question to Adrian: Any third party "borrowing stuff" from the Newton would need to comply with Newton's AGPL licensed and Paremus copyright, i.e. all derivative works must be AGPL; including services hosted from a derivative platform. Parties wishing to avoid these AGPL obligations, perhaps wanting to build a commercial product built up, or service run hosted upon a Newton derived platform, need to engage in commercial dialogue with Paremus; this also allowing access to the much more powerful Infiniflow platform.

    On the larger debate, I'll only make one comment. I believe that GPL license model is an excellent open-source license model. The backlash against companies that use the GPL license is quite frequently driven by self-interest.

    Remember free as in Freedom, not "free beer"!

    Regards Richard

  • Re: Neil

    by Geir Hedemark,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I didn't for one minute say that VC funding is evil - this is how you read that bit Rod, and if I was unclear in my comment let me now be more clear - from what I see, and have seen, it does inevitably slow down innovation in open source technology projects, however, (...)

    I think you are only looking at one side of the coin here.

    Working for a startup without funding is, as you put it, pushing the envelope. You have to. If you don't, you won't get paid, and you won't succeed.

    Generally, what goes along with "pushing the envelope" is also a fair bit of waste. Shortcuts get taken, dumb decisions get made in order to meet whatever needs it is perceived the market has. That is also part of what being a startup is all about. Most startups fail. Those who don't generally rewrite their code a number of times before getting it right.

    Now, before Rod comes and takes my head off - I am not talking about Springsource. I am talking about my own experiences working for startups, and the Spring framework seems to suffer less from this affliction than the products put out by many other startups.

    So yes, the speed may go down. You also don't get the same amount of waste. I can't see anything wrong with that.

    I really, really don't agree with you that distributed applications look the same now as 7-8 years ago. From my hilltop I can see extreme changes. Stuff gets tested (and Spring is a major part of making that possible), there are at least attempts at developing systems in a more agile way, there are other platform options beside EJB 1.0. I really can't see your point of view at all. Stuff is vastly different than they were in 2000, and mostly for the better.

    I could also wish for faster change. There are some technologies I have not tried to introduce because there are nobody out there who knows them. Getting people who know their way around AOP is non-trivial around here. OSGi? Perhaps in a while.

    I hope Springsource keeps up the good work. I like what they have been doing so far. I haven't used S2AP yet, so I won't comment on that. Yet.


  • Not consumable by application developers

    by Bill Burke,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Number one, I don' believe that standard OSGi is an end user/application developer construct. Its not something that should be consumed by app developers which instead should be focused on writing POJOs and/or EJBs. It provides really no benefits during development and primarily shows its value add in application development within production deployments.

    Second, the reason I want OSGi to become prevalent is so that we have a standardized kernel that the industry is using. I wish Java EE from the beginning defined a kernel, then all its services second. This would have made it much much easier to have standalone specifications that could be implemented a la carte by different vendors and open source organizations. So, really, IMO, OSGi is really something that is going to benefit vendors and framework developers from a software development perspective.

    Third, unless Spring Source standardizes its OSGi innovations, including DI integration, it pretty much isn't very interesting, because most of us want to unify under a standard, not a proprietary, GPL based solution that is going to lock us into one vendor. This is what standards are for and I am continually disappointed (but not surprised) that Rod and Co. have little interest in beefing up standards.

    Fourth, if you dig up some of Marc Fleury's old talks on the JBoss Microkernel you see a lot of similar features, arguments, and marketing talk that folks like Glassfish and SS are touting now. Just replace JMX with OSGi and u see what I mean. I'm not saying this to say "We were here first :p", but more to expand on the argument that there is no innovation here. OSGi is just a standarization of what many of us have been doing for years. And this is a *good* thing. We need the standardization, we just don't need the proprietary aspect of it.

    @Neil, you have a point about VC's, business, and innovation. The thing is, most companies do not want a product that is changing every other month. They want something stable, productized, clean, and smooth. What I've experienced at the last few companies I've worked at is that productization of a project is at least an order of magnitude more work that creating the project (and an order of magnitude more monotonous and tedious). IMO, Spring Source is at this productization phase and you will naturally see a slow down in innovation. This is because productization is actually more important than innovation at times.

    Bill Burke
    JBoss, a division of Red Hat

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

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