Discussions

News: SpringSource Application Platform - totally rocks

  1. As you may have noticed elsewhere, SpringSource announced the SpringSource Application Platform in beta today, but... why hasn't TSS talked about it? Well, I'll tell you why: because it's not available yet! Totally radical, logical idea, but it's not yet downloadable. (Not at 2:00 p.m. EDT, at least. I've been watching, refreshing, waiting.) [Incidentally, it's up now.] So what is the SpringSource Application Platform? It's just that: an application platform, built on OSGi, that can resolve Spring bean references by looking up services through OSGi - all of the capabilities OSGi provides, without the headache of deployment. In addition, Rod Johnson said that it would be able to deploy .WAR files through the use of a Tomcat (or servlet container) service. Right now, of course, OSGi can be deployed in a web container (as a WAR itself, as Apache Sling does), or can resolve servlet references to OSGi services through the plugin structure. However, with S2AP (the acronym they seem to prefer), the servlets can simply look up beans through the Spring context - and the application platform can resolve those references to OSGi services. The power this implies cannot be understated. [Editor's note: erm... okay, as a reader commented, I meant OVERstated. This is great stuff.] It's going to have two versions: a GPLed, open version, and a subscription-based version. The current offering (or, if you will, unavailable offering) is a beta for the subscription-based version. It requires registration to see, and I'm sure when it's around, it'll rock beyond what we expect.

    Threaded Messages (225)

  2. And naturally, it's there now - not fifteen minutes after I called SpringSource to ask about it. :)
  3. Practical use of OSGI[ Go to top ]

    Hi, I am not able to understand the significance and the impact OSGI is going to provide. Can you provide a practical example of what the current problem is and how the OSGi container is going to resolve it?
  4. I think a lot of people (like Craig Walls) have been waiting for this for a long time... Only a few more minutes :-) Rgds Rod SpringSource
  5. Congratulations! Finally a java application server that really covers our needs in enterprise development! This is a good complement of the spring core framework that ties together OSGi - servlet - IOC - EE services. IMHO, the reasons to use EJB servers (like glassfish or jboss) are now looking down to zero.
  6. Why is everyone so overexcited over OSGi? It's just a module system... Yes you can make you app modular easily and plug-in ready-made module, but you could do that (or almost that) in J2EE apps with EJB/RA/... modules. It's not a silver bullet, bad design will still make up a bad application, just more complicated one. For most people OSGi is a bit too vague. On the last conference we were constantly explaining how JavaRebel _does not_ compete with OSGi and in fact works perfectly well with it. People are sure that the bundles will be so fine-grained that reloads will be instant (thanks to the microdemos, no doubt). It might be true in some cases that are small enough, but likely not in most of them.
  7. Why is everyone so overexcited over OSGi? It's just a module system... Yes you can make you app modular easily and plug-in ready-made module, but you could do that (or almost that) in J2EE apps with EJB/RA/... modules. It's not a silver bullet, bad design will still make up a bad application, just more complicated one.

    For most people OSGi is a bit too vague. On the last conference we were constantly explaining how JavaRebel _does not_ compete with OSGi and in fact works perfectly well with it. People are sure that the bundles will be so fine-grained that reloads will be instant (thanks to the microdemos, no doubt). It might be true in some cases that are small enough, but likely not in most of them.
    - OSGi is a bit more then "just a module system" especially when compared to J2EE platforms. - No, it is not a silver bullet and unfortunately no matter how many frameworks attempt to simplify design efforts, bad design will occasionally find its way through. Although I would disagree about "more complicated one", since in a "just a modular system" bad design is incorporated into modules that could easily be removed right...? - I am also struggling to agree on: "For most people OSGi is a bit too vague. . ." I am certainly not a genius, thus could very easily align with "most people", and I didn't find it to be to difficult to understand. Bundles are JARs, Manifest actually means something, versioning etc. . . way less complicated then JEE, although with enough bundles you could easily make a JEE platform based on OSGi similar to Spring making Enterprise Java Platform. Look at it as micro-kernel. . . - But I am completely lost on "JavaRebel competing with OSGi" comment and what does it have to do wit this thread?
  8. Why is everyone so overexcited over OSGi? It's just a module system... Yes you can make you app modular easily and plug-in ready-made module, but you could do that (or almost that) in J2EE apps with EJB/RA/... modules. It's not a silver bullet, bad design will still make up a bad application, just more complicated one.

    For most people OSGi is a bit too vague. On the last conference we were constantly explaining how JavaRebel _does not_ compete with OSGi and in fact works perfectly well with it. People are sure that the bundles will be so fine-grained that reloads will be instant (thanks to the microdemos, no doubt). It might be true in some cases that are small enough, but likely not in most of them.
    Refering to OSGi as 'just a module system' is a bit like saying the JVM is just a bytecode interpreter. OSGi provides a sophisticated and well-defined model for building modular applications supporting multiple module versions and dynamic changes over time. I'm not really sure what you mean about OSGi being vague - it's anything but, the spec is exhaustive. The refresh support works in real-world scenarios, and handles typical inter-module dependencies cascading the refreshes as necessary. The SpringSource Application Platform extends this refresh to support more complex relationships, such as those introduced when using load-time weaving.
  9. Refering to OSGi as 'just a module system' is a bit like saying the JVM is just a bytecode interpreter. OSGi provides a sophisticated and well-defined model for building modular applications supporting multiple module versions and dynamic changes over time.

    I'm not really sure what you mean about OSGi being vague - it's anything but, the spec is exhaustive.
    Well, so it's a sophisticated and well-defined module system. Looking at Eclipse plug-in system, which uses it extensively, it has its pros and its cons. The spec isn't vague, but there's a lot of buzz surrounding OSGi and most people won't read the specm they'll read the vague coverage. When talking to people at the conference a lot of them thought that OSGi will magically solve many unrelated problems.
  10. Refering to OSGi as 'just a module system' is a bit like saying the JVM is just a bytecode interpreter. OSGi provides a sophisticated and well-defined model for building modular applications supporting multiple module versions and dynamic changes over time.
    Is that something which has been available in .NET since .NET 1.0?
  11. .NET modules[ Go to top ]

    Refering to OSGi as 'just a module system' is a bit like saying the JVM is just a bytecode interpreter. OSGi provides a sophisticated and well-defined model for building modular applications supporting multiple module versions and dynamic changes over time.


    Is that something which has been available in .NET since .NET 1.0?
    In theory .NET does some of that, except that .NET itself has always broken backwards compatibility with each release of the CLR & framework, making it a moot point in reality. Peace, Cameron Purdy Oracle Coherence: Data Grid for Java and .NET
  12. Re: .NET modules[ Go to top ]

    Java and Java EE have historically been weak in modularity, versioning etc. We believe that building on OSGi and delivering it in a form useable by enterprise application developers--with business problems to solve, who should not need to focus on low-level infrastructure--solves an important problem and delivers real benefits to developers and operations staff. Another way of looking at it: OSGi is used to power the Eclipse plugin model. Eclipse provides OSGi with a context on the desktop that makes it valuable to Java developers who want to build applications. The SpringSource Application Platform aims to provide a similar context that brings OSGi benefits to enterprise application deveopers. Rgds, Rod
  13. Re: .NET modules[ Go to top ]

    Java and Java EE have historically been weak in modularity, versioning etc. We believe that building on OSGi and delivering it in a form useable by enterprise application developers--with business problems to solve, who should not need to focus on low-level infrastructure--solves an important problem and delivers real benefits to developers and operations staff.
    Is it already too late to retrofit those features into the Java and/or JEE platform itself? Thanks.
  14. Re: .NET modules[ Go to top ]

    Java and Java EE have historically been weak in modularity, versioning etc. We believe that building on OSGi and delivering it in a form useable by enterprise application developers--with business problems to solve, who should not need to focus on low-level infrastructure--solves an important problem and delivers real benefits to developers and operations staff.


    Is it already too late to retrofit those features into the Java and/or JEE platform itself? Thanks.
    IMO, it really depends on Sun. Most vendors have been pushing for OSGi in EE as well as fixing DI. Sun just has to stop being stubborn. Would be cool if SpringSource pushed their new-found weight around to get new and improved DI within EE 6, but, their too interested in staying proprietary and protecting their fiefdom.
  15. Re: .NET modules[ Go to top ]

    Bill,
    Would be cool if SpringSource pushed their new-found weight around to get new and improved DI within EE 6, but, their too interested in staying proprietary and protecting their fiefdom.
    I'm surprised that you don't know that I proposed a DI JSR last year. It was strongly opposed by some of your own colleagues, which was one of the reasons we had little choice but to withdraw it. Btw I don't think that Sun are an obstacle to improving DI in Java EE. Totally agree about OSGi. We have vigorously lobbied Sun to play nice with OSGi and I think that they are listening to the many voices from vendors and the community on this matter. I imagine both we and Red Hat have played a constructive role here. Rgds Rod
  16. Re: .NET modules[ Go to top ]

    Bill,
    Would be cool if SpringSource pushed their new-found weight around to get new and improved DI within EE 6, but, their too interested in staying proprietary and protecting their fiefdom.
    I'm surprised that you don't know that I proposed a DI JSR last year. It was strongly opposed by some of your own colleagues,
    Well, one reason is because it was Java 8 (9?) SE proposal and not EE. EE needs it much more than SE does. It also needs to play nicely with Web Beans as there is some pretty interesting and innovative stuff their we contributed from the Seam movement. You guys all need to get together and decide a compromise as there is a lot of good technology on both sides that could be standardized.
    Btw I don't think that Sun are an obstacle to improving DI in Java EE.
    IMO, Sun is the obstacle for improving anything in EE. We managed to muscle through JPA with a lot of opposition due to Sun's backing. I think EE and Java are much better for it. Would be the same with DI if people got their act together. Unfortunately, the EE 6 expert group wasted tons of time discussing worthless unneeded profiles instead of evolving the spec technically.
    Totally agree about OSGi. We have vigorously lobbied Sun to play nice with OSGi and I think that they are listening to the many voices from vendors and the community on this matter. I imagine both we and Red Hat have played a constructive role here.

    Rgds
    Rod
    What I find bizarre is that Glassfish has support for it...Time to get it in the spec. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com
  17. Glassfish has modularization and lazy loading of containers. Being JEE5 compliant, it embraces the POJO model. And everything a Java web/enterprise application could ever need is "just there", via simple configs, annotations, and the aforementioned lazy loading. And oh yeah, Glassfish is (or is going to) to be incorporating OSGI And it sounds like the Spring platform is going to offer similar features and functionality. The big difference is that the Spring platform is not, nor will it be, JEE compliant.
  18. Glassfish has modularization and lazy loading of containers. Being JEE5 compliant, it embraces the POJO model. And everything a Java web/enterprise application could ever need is "just there", via simple configs, annotations, and the aforementioned lazy loading. And oh yeah, Glassfish is (or is going to) to be incorporating OSGI

    And it sounds like the Spring platform is going to offer similar features and functionality. The big difference is that the Spring platform is not, nor will it be, JEE compliant.
    Jeff, not necessarily. S2AP is built around OSGi; if Glassfish can be deployed as an OSGi container (which it can), then S2AP can definitely leverage Glassfish as a full Java EE container in and of itself, while still providing other services. What's more, since SpringSource is on the Java EE EG, there's a very good chance that S2AP will fulfill at least some of the Java EE profiles.
  19. We will certainly be looking to support the relevant JEE 6 profiles with the Application Platform when they become finalized. Many existing products already build on OSGi - including offerings from IBM and BEA. From the details available at Sahoo's blog it looks like GlassFish plans to do something similar. Where the SpringSource Application Platform is different is that we expose the OSGi model to end users for the development of their own applications. This means more than that you can simply develop and deploy an OSGi bundle to the platform - it means that a *lot* of work has gone into making sure that existing enterprise libraries, designed without OSGi in mind, can be used from within the OSGi service platform. Building a platform *on* OSGi, but not having an OSGi based programming and deployment model for end users is a very different proposition to unlocking OSGi for enterprise application development itself.
  20. Great job[ Go to top ]

    You have remarkable certainty about what we will not do in the future.
    classic line. i'll have to remember that. Great job guys! I think there's a lot of pent up demand for this.
  21. Jeff
    The big difference is that the Spring platform is not, nor will it be, JEE compliant.
    You have remarkable certainty about what we will not do in the future. True, this release is not a full Java EE 5 implementation, although it offers a complete implementation of the Java EE web stack, including legacy WAR deployment. (That is, of the parts of Java EE that are actually used in most applications.) That's because it's not rational for us or any other new market entrant to implement much of the legacy baggage that would require, and because it would unnecessarily weigh down the platform. Another EJB 1.1 implementation (remember those public instance variables in entity beans)? EJB 2.0 with the abstract methods? Home interfaces? However, we are supportive of Java EE 6 and are on the expert group. I believe that we might very well implement profiles A and B in future--although, given that Java EE 6 is non-final, it's not possible to make a firm commitment at this point. Also, OSGi is itself a standard. Rgds Rod
  22. You have remarkable certainty about what we will not do in the future.
    Okay, okay, I'm not certain at all, and I apologize for sounding certain. But based on reading your blog from time to time and your posts here at TSS, and your repeated proclamations that JEE, and JEE app servers, are dead or dying, increasinly replaced by Spring, made me assume that you were in no hurry to be JEE compliant.
    True, this release is not a full Java EE 5 implementation, although it offers a complete implementation of the Java EE web stack, including legacy WAR deployment. (That is, of the parts of Java EE that are actually used in most applications.) That's because it's not rational for us or any other new market entrant to implement much of the legacy baggage that would require, and because it would unnecessarily weigh down the platform. Another EJB 1.1 implementation (remember those public instance variables in entity beans)? EJB 2.0 with the abstract methods? Home interfaces?
    That's cool, and it probably helps make you more agile to not have to implement legacy (and very bad) specs like EJB 2.x. But the flip side of that is that with stuff like Glassfish, a customer can run their existing, legacy EJB 2.x stuff, that works currently (and that they had to work really hard to get running), along side the new EJB 3.x and JPA stuff. It makes a smoother transistion. But then again, Spring works with regular J2EE app servers. So I guess that's a push.
  23. Jeff
    That's cool, and it probably helps make you more agile to not have to implement legacy (and very bad) specs like EJB 2.x.
    It certainly does make us more agile. And we agree on the value of those specs.
    But the flip side of that is that with stuff like Glassfish, a customer can run their existing, legacy EJB 2.x stuff, that works currently (and that they had to work really hard to get running), along side the new EJB 3.x and JPA stuff. It makes a smoother transition. But then again, Spring works with regular J2EE app servers. So I guess that's a push.
    We aren't primarily focused on the section of the market that is running very old applications using such legacy technology. Remember that most production deployments in enterprise Java, according to BZ Media and other research, are now on Tomcat, and therefore are not using those APIs, whose usage has been declining sharply for several years. Many applications running on full-blown application servers avoid those old models in any case (for the reasons you and I agree on), often using Spring already. No product is a perfect solution for 100% of the market. We are happy to be able to address the majority of the market, and try to provide the ideal solution without legacy baggage. For users with EJB 2.x applications, the possible courses are: - Stay on a Java EE application server altogether - Leave the old applications on the Java EE application server, if they are running fine, and deploy new ones on another platform - Eliminate the legacy model and enjoy a wider choice of platform (not just SpringSource Application Platform. In many (not all) cases this is feasible and can deliver other benefits; many users are going down this path any way. Which is the best course will depend on the specific case. Rgds Rod
  24. nor will it be, JEE compliant.
    who cares?
  25. Rob Harrop just posted a blog entry providing a high-level overview of the platform and providing links to documentation and downloads. -- Regards, Adrian.
  26. Worth noting[ Go to top ]

    Once you start it up, the documentation doesn't actually tell you what the admin username/password is - not that I could see, at least. It's "admin" and "springsource" by default, held in the $PLATFORM_HOME/servlet/conf/tomcat-users.xml file.
  27. Re: Worth noting[ Go to top ]

    Once you start it up, the documentation doesn't actually tell you what the admin username/password is - not that I could see, at least. It's "admin" and "springsource" by default, held in the $PLATFORM_HOME/servlet/conf/tomcat-users.xml file.
    Hi Joseph, FYI: the user name and password for the admin console actually are listed in the user guide. Refer to section 5.1 "Deploy an Application". regards, Sam
  28. Why GPLV3 ?[ Go to top ]

    And what about vendor-lock in ?
  29. Re: Why GPLV3 ?[ Go to top ]

    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. In terms of vendor lock-in, the application platform does not introduce any new programming model - the programming model remains Spring and Spring Dynamic Modules, with an OSGi-based deployment format.
  30. Re: Why GPLV3 ?[ Go to top ]

    Why GPL3?
    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. GPL guarantees end users that the software contributes to maximizing the amount of open source available, without imposing any onerous obligations on them. GPL would prevent a commercial vendor building a closed product around the SpringSource Application Platform without giving back to the community. I think that's perfectly reasonable. Also, GPL is the most common open source license, adopted by a majority of open source projects.
    And what about vendor lock in?
    The Application Platform supports standard WAR files and standard OSGi bundles. We provide an additional, new, deployment model that offers semantics that are offered by neither of these existing formats. It builds on standard OSGi bundles. We hope that standardization in either the OSGi Alliance or JCP will eventually meet this need, but we believe there was a strong market demand to deliver a working solution. Innovation can never happen if communities and vendors never move in advance of standards, delivering benefit to their users. The programming model is based around the proven Spring model--the least invasive enterprise Java programming model available--and the Java EE web stack. You do not need to write Java code that is specific to the Application Platform, nor is the deployment model dependent on anything but open source software. The Spring Framework and Spring Portfolio maintain their commitment to maximizing portability between platforms. Let me quote from Rob Harrop's blog introducing the Application Platform today to provide a little more detail: The Platform supports applications packaged in three forms: - Java EE WAR - Raw OSGi bundles - Platform Archive (PAR) Standard WAR files are supported directly in the Platform. At deployment time, the WAR file is transformed into an OSGi bundle and installed into Tomcat. All the standard WAR contracts are honoured, and your existing WAR files should just drop in and deploy without change. Any OSGi-compliant bundle can be deployed directly into the Platform, and can take full advantage of on-the-fly provisioning for any dependencies referred to by Import-Package and Require-Bundle. The PAR format is the recommended approach for packaging and deploying applications for the Platform. A PAR is simply a collection of OSGi bundles (modules) grouped together in a standard JAR file, along with a name and a version that uniquely identify the application. The PAR file is deployed as a single unit into the Platform. The Platform will extract all the modules from the PAR and install them. Third-party dependencies will be installed on-the-fly as needed. Rgds Rod
  31. Re: Why GPLV3 ?[ Go to top ]

    Creating an application platform that makes the benefits of OSGi available to end users was a huge investment for us. ...
    I should clarify: in my last post I was quoting Adrian from here, hence Adrian and I used the same wording on this thread. Rgds Rod
  32. Re: Why GPLV3 ?[ Go to top ]

    GPL would prevent a commercial vendor building a closed product around the SpringSource Application Platform without giving back to the community.
    Does nobody actually, you know, READ these licenses? Users who change GPL code have absolutely no, zero, zippo, big bagel, goose egg obligation to give back to "the community". I can take this code, make all the changes I want, sell it to my customers, and you can come knock on my door saying "I want the code, it's GPL! Give me the code!" and I can nod and smile knowingly and tell you to pound sand. "Give me $100K and I'll give you the software." Joe Random User has absolutely no "right" and I have no "commitment" to give them the source code. I, as a developer and user of GPL source code only have an obligation to the people who receive the software, whom I have a distribution relationship with. And there's nothing that says I have to enter in to that relationship with anyone "for free". When I sell the software to a customer, I have an obligation to make the source available to the customer, and only that customer, and that customer can then run off and do with it whatever they wish. But they aren't obligated to do that, either. They don't have to suddenly post the code on a public FTP site, or make some announcement somewhere. Sure, they COULD do that, they just don't. Hospitals, manufacturers, etc. aren't really in to that whole "let's host our patient record system or distribution system source code for all the world to see". Of course, at the same time, commercial entities fear the GPL. It's the scarlet letter of the open source community as far the commercial space. It's why anything of interest is done twice. Once in GPL, and once in a more open license. Finally, and this is VERY interesting, note that this system is entirely GPL. That means that the INFRASTRUCTURE your application runs on affects your APPLICATION. That means if you DO deploy an application against this infrastructure, and you utilize any dependency upon that infrastructure within your application, then you application is GPLd. This is in stark contrast to, say, JBoss which is in itself an LGPLd infrastructure. That effectively means that the container is under similar restrictions as any other GPL code (change the container, distribute the changes, the source goes with it), but at least your application deployed on top of it is not. Mind, this should likely not affect something as normal as a WAR, but even that is assuming that you're using SUNs Servlet Jars to implement the API (i.e. the interface), and not SpringSources Servlet API Jars (assuming they're GPLv3 like the rest). If they DO use that, then, whammo -- GPL'd WAR. But I don't know how it might affect any other application that wants to leverage this infrastructure. So, anyway, if you're GPL shy, I'd stay away at the moment. And it will be interesting to see how the case works out for a "new", "proprietary" application server.
  33. GPL3 and FUD[ Go to top ]

    Will
    Users who change GPL code have absolutely no, zero, zippo, big bagel, goose egg obligation to give back to "the community". I can take this code, make all the changes I want, sell it to my customers, and you can come knock on my door saying "I want the code, it's GPL! Give me the code!" and I can nod and smile knowingly and tell you to pound sand. "Give me $100K and I'll give you the software."
    You are splitting hairs when you argue that derivative works based on GPL software distributed by closed source vendors can avoid being opened to "the community." Let's suppose that Oracle built a derivative work on SpringSource Application Platform. They would have to distribute the code of that derivative work under the GPL. I think you will agree that if that code was of value, causing many people to buy the product, the code would quickly find its way back into a public repository. Therefore Oracle would assume that any derivative work is effectively going to be opened up. Furthermore the wording is that the modified source code must be made available to the program's users. That would presumably include anyone evaluating the product. So my comment reflects the reality.
    [GPL] is the scarlet letter of the open source community as far the commercial space.
    GPL is widely used in products with thriving commercial activity around them. Like Linux. The kernel, at the heart of all Linux systems, is developed and released under the GNU General Public License and its source code is freely available to everyone. - Linux Online
    That means that the INFRASTRUCTURE your application runs on affects your APPLICATION. That means if you DO deploy an application against this infrastructure, and you utilize any dependency upon that infrastructure within your application, then you application is GPLd.
    Incorrect. This is FUD. The programming model used by the server is the established Spring programming model you could have used on another platform. I've already stated in this thread that you don't need to write code to the platform, hence you are not creating a derivative work. The implementation of the server is separate from your code. Using GPL is quite different from creating a derivative work It is highly likely that you use GPL software daily (possibly in your operating system, and in many many other projects), and it doesn't make you need to open up your own code. Rgds Rod
  34. Re: GPL3 and FUD[ Go to top ]

    You are splitting hairs when you argue that derivative works based on GPL software distributed by closed source vendors can avoid being opened to "the community."
    There is this impression, in the world at large, that I, as a vendor, am obligated and compelled to make those changes available to all comers. That if I create a GPL work that I'm suddenly responsible for opening the doors wide and giving it access to the world. That is simply not true. I'm not obligated to give it to anyone but my customers. Even if I was Oracle, I could provide the source on the distro CDs, or I could provide the download through a restricted users portal. You're right, that the customer can do with it what they will, and I can't stop them, and certainly that's a consideration that crosses vendors minds when they adopt a GPL project. The vendor can't control the release to the wild, but they don't have to enable the distribution to the world at large. And, basically, I don't really think that code would then come back in to the community -- specifically not this community, as who ever DOES release it certainly doesn't have copyright on the code, and therefore the code can't be relicensed. As the products vendor, who has a controlling copyright, you CAN (and apparently do) relicense it. But you certainly aren't going to take back contributions that don't have at least shared copyright, because as soon as that happens you can't relicense the whole under something other than GPL. So, there's not a whole lot of value to the community there. So, Oracles version can have all this value add, but it's hard to see it necessarily coming back in to the community itself save as an unsupported fork. I mean, Oracle certainly isn't going to support it, it will be difficult for you to support it without merging it back (and licensing the whole as GPL only), and it's a dead branch unless someone is willing to propagate any new changes from your project, or the latest release from Oracle in to the new fork. Most folks simply aren't that motivated.
    GPL is widely used in products with thriving commercial activity around them. Like Linux. The kernel, at the heart of all Linux systems, is developed and released under the GNU General Public License and its source code is freely available to everyone. - Linux Online

    That's because the GPL affecting the kernel doesn't actually affect the applications running under the userland. You'll note that while the kernel is GPL, the libraries are not.
    Incorrect. This is FUD. The programming model used by the server is the established Spring programming model you could have used on another platform.
    If I ship an application with your platform, it will most likely have to be GPL, as I can't see how it can't be linking to your GPLd libraries in some way. Even if I simply deploy upon it. Even a simple, page 10 from "Servlets for Dummies" WAR would be GPLd, as it's obviously using artifacts from your platform, minimally to implement the HTTPServletRequest (again, assuming the entirety of your platform is GPL, but you get the point). Now, I can ship your infrastructure independently from my application, and the customer can then deploy my application on to your infrastructure, and that would be a loophole around GPLing my application. Not very user friendly though. But if I ship a combined application deployed on your infrastructure, my code is infected by the GPL simply by linking to your code. I can ship an application on top of JBoss without this problem, because they are LGPL. I can't ship a changed JBoss without providing access to the source code, but I can license my application itself, apart from JBoss however I want, even though they are "combined" when delivered. That's why LGPL (e.g. gclib et al), and GPL w/Classpath Exemption (e.g. OpenJDK, GNU Classpath) exist -- to prevent libraries from tainting code that use those libraries. I mean, don't you think that the GNU folks know about this detail regarding the GPL and class libraries being as they came up with both LGPL and GPL w/CE in order to work around it? And this is also why MySQL's JDBC driver is NOT LGPL, they use the GPL as a tool to push commercial licenses. Simply put, if your goal is to simply ensure that your infrastructure remains, effectively, GPLd but that it has no effect on applications wishing to use your infrastructure, then you should relicense it to LGPL or GPL w/Classpath exemption. Is that your intent? To keep the infrastructure apart from any applications deployed on it? Simply if I take your infrastructure, write my application to the assorted apis given (including, perhaps container specific APIs, like Glassfish's AMX beans), deploy it on your infrastructure, shut it down, and then zip up the entire directory to a customer as a single whole, do I need to open up my source code? If not, then I'm curious what commercial market you're looking at, as I don't know if there's a big custom infrastructure market out there (I could be quite wrong however).
  35. Re: GPL3 and FUD[ Go to top ]

    There is this impression, in the world at large, that I, as a vendor, am obligated and compelled to make those changes available to all comers. That if I create a GPL work that I'm suddenly responsible for opening the doors wide and giving it access to the world. That is simply not true. I'm not obligated to give it to anyone but my customers. Even if I was Oracle, I could provide the source on the distro CDs, or I could provide the download through a restricted users portal.
    The software will be redistributed as GPL in practice. This is a disincentive to a vendor like Oracle building a closed source application on it, so it achieves its goal.
    If I ship an application with your platform (like Oracle in that case), it will most likely have to be GPL
    Our interpretations of the GPL differ. We do not regard running an application on the platform as creating a derivative work. If you are an ISV creating a closed product on our platform which integrates with or modifies its internals and distributing that product you may trigger GPL obligations. It is important to note that an end user--such as a bank or media company building a web site--has no obligations. From the GPL FAQ:
    A company is running a modified version of a GPL'ed program on a web site. Does the GPL say they must release their modified sources? The GPL permits anyone to make a modified version and use it without ever distributing it to others. What this company is doing is a special case of that. Therefore, the company does not have to release the modified sources. It is essential for people to have the freedom to make modifications and use them privately, without ever publishing those modifications. However, putting the program on a server machine for the public to talk to is hardly “private” use, so it would be legitimate to require release of the source code in that special case. Developers who wish to address this might want to use the GNU Affero GPL for programs designed for network server use.
    Rgds Rod
  36. Re: GPL3 and FUD[ Go to top ]

    Our interpretations of the GPL differ. We do not regard running an application on the platform as creating a derivative work. If you are an ISV creating a closed product on our platform which integrates with or modifies its internals and distributing that product you may trigger GPL obligations.
    Then you need to clarify integrates, because on the whole, Sun, MySQL (now Sun, but...), the FSF and others disagree with your interpretation. I guess they have different lawyers. I don't know your platform, I don't know what it does or doesn't offer. But, as an example, much like JBoss uses JMX internally, Glassfish has the concept of an AMX bean, which is an administrative management bean (all of the management tasks, for example are done via AMX beans). AMX Beans are a purely Glassfish concept and development (albeit similar and inspired by JMX, they are not JMX beans per se). If you write an application that relies on AMX beans, but is other wise a "pure" JEE application, you have created a dependency on Glassfish in that case. Is that what you mean by "integrate"? You've mentioned that you use Spring and OSGi development models, that you should be able to deploy an application on an another OSGi container, for example (you cited an Eclipse one). But if I leverage some S2AP specific component in my application, that is I'm actually trying to get explicit value out of the container leveraging some container feature, rather than implicit value (maybe your container is faster, less memory, whatever). Mind, I'm not trying to create my own application container, I'm just leveraging the one provided as best as possible. Is my application going to trigger the GPL? Every JEE application of some complexity has some container dependency, typically this is a potential porting issue in the future. Is this a potential licensing issue if I were to use you container in a similar way? That uncertainty (both "integrates with or modifies its internals" and the other interpretations of the GPL by other parties (including the authors of the GPL)) is just that -- uncertainty. I think there needs to be stark clarity on this issue for folks wishing to potentially use your software. Well, let me put it this way. The clarity is there -- buy a license, and you buy clarity. But I mean some clarity regarding what the GPL version can and can not be used for.
  37. Re: GPL3 and FUD[ Go to top ]

    Using GPL is quite different from creating a derivative work It is highly likely that you use GPL software daily (possibly in your operating system, and in many many other projects), and it doesn't make you need to open up your own code.

    Rgds
    Rod
    Rod, everyone knows you are a really smart guy. Maybe you just aren't being clear, but this statement is totally incorrect. If the interfaces people code to are GPL'd then the application is a derivative work according to the FSF. (See http://www.fsf.org/licensing/licenses/lgpl-java.html - pay particular attention to their definition of linking). You really don't have the right to interpret their license differently than they do. You do have to option to do what Sun did with OpenJDK, which was to license most of the JDK under the GPL but then license the API under a more acceptable license. If you aren't even exposing any API's then you don't have a problem. If that is the case, just say so. Not too many people will care if your license is proprietary, GPL or whatever, as long as it doesn't force them to license their code under the GPL - which it will do if they have any imports for GPL'd classes or interfaces. The real shame of this is that it will be impossible for me to use this in any of the Apache projects I work on.
  38. Re: GPL3 and FUD[ Go to top ]

    Using GPL is quite different from creating a derivative work It is highly likely that you use GPL software daily (possibly in your operating system, and in many many other projects), and it doesn't make you need to open up your own code.

    Rgds
    Rod


    Rod, everyone knows you are a really smart guy. Maybe you just aren't being clear, but this statement is totally incorrect. If the interfaces people code to are GPL'd then the application is a derivative work according to the FSF. (See http://www.fsf.org/licensing/licenses/lgpl-java.html - pay particular attention to their definition of linking). You really don't have the right to interpret their license differently than they do. You do have to option to do what Sun did with OpenJDK, which was to license most of the JDK under the GPL but then license the API under a more acceptable license. If you aren't even exposing any API's then you don't have a problem. If that is the case, just say so.

    Not too many people will care if your license is proprietary, GPL or whatever, as long as it doesn't force them to license their code under the GPL - which it will do if they have any imports for GPL'd classes or interfaces.

    The real shame of this is that it will be impossible for me to use this in any of the Apache projects I work on.
    Ralph, the whole point is you do not code against any interfaces of the SpringSource Application Platform. People install the Platform just like any other server. The applications they deploy into it are coded against standard Java SE, Jave EE, Spring Framework (Apache License), Spring Dynamic Modules (Apache License), other Spring projects (all Apache Licensed), etc. The fact that the Platform is GPL is relevant w/regards to redistributing the Platform. For example, if as opposed to asking your customer to install the Platform, and then install your application into it, you wish to ship your customer one package which includes both the Platform and the Application, _then_ the license of the Platform becomes relevant. You either need to accept that your application will become GPL, or purchase a redistribution license from SpringSource. But nobody is forcing anybody to bundle anything with the Platform, and again, there is no need to code against any Platform APIs. Regards, Colin Sampaleanu SpringSource
  39. Re: GPL3 and FUD[ Go to top ]

    The fact that the Platform is GPL is relevant w/regards to redistributing the Platform. For example, if as opposed to asking your customer to install the Platform, and then install your application into it, you wish to ship your customer one package which includes both the Platform and the Application, _then_ the license of the Platform becomes relevant. You either need to accept that your application will become GPL, or purchase a redistribution license from SpringSource. But nobody is forcing anybody to bundle anything with the Platform, and again, there is no need to code against any Platform APIs.

    Regards,
    Colin Sampaleanu
    SpringSource
    Colin, now it seems you have gone too far in the other direction. If, as you say, applications do not code to any platform APIs or any other GPL'd code, then merely bundling them with the platform will not require them to be licensed under the GPL as they are not a derivative work under U.S. copyright law. While the definition of a derivative work in software is a bit murky, with the GPL it usually revolves around what "linking" is, not merely aggregation. In fact, if what you said were true then all the Apache licensed software within the platform would also have to be "upgraded" to the GPL. Since the applications being aggregated with the platform must all be based on other technologies not under the GPL (since the platform apparently has no APIs of its own), such as OSGi or the Spring container, then it is difficult to imagine how they could be classified as a "covered work" under the GPL.
  40. Re: GPL3 and FUD[ Go to top ]

    Using GPL is quite different from creating a derivative work It is highly likely that you use GPL software daily (possibly in your operating system, and in many many other projects), and it doesn't make you need to open up your own code.

    Rgds
    Rod


    Rod, everyone knows you are a really smart guy. Maybe you just aren't being clear, but this statement is totally incorrect. If the interfaces people code to are GPL'd then the application is a derivative work according to the FSF. (See http://www.fsf.org/licensing/licenses/lgpl-java.html - pay particular attention to their definition of linking). You really don't have the right to interpret their license differently than they do. You do have to option to do what Sun did with OpenJDK, which was to license most of the JDK under the GPL but then license the API under a more acceptable license. If you aren't even exposing any API's then you don't have a problem. If that is the case, just say so.

    Not too many people will care if your license is proprietary, GPL or whatever, as long as it doesn't force them to license their code under the GPL - which it will do if they have any imports for GPL'd classes or interfaces.

    The real shame of this is that it will be impossible for me to use this in any of the Apache projects I work on.


    Ralph, the whole point is you do not code against any interfaces of the SpringSource Application Platform.

    People install the Platform just like any other server. The applications they deploy into it are coded against standard Java SE, Jave EE, Spring Framework (Apache License), Spring Dynamic Modules (Apache License), other Spring projects (all Apache Licensed), etc.

    The fact that the Platform is GPL is relevant w/regards to redistributing the Platform. For example, if as opposed to asking your customer to install the Platform, and then install your application into it, you wish to ship your customer one package which includes both the Platform and the Application, _then_ the license of the Platform becomes relevant. You either need to accept that your application will become GPL, or purchase a redistribution license from SpringSource. But nobody is forcing anybody to bundle anything with the Platform, and again, there is no need to code against any Platform APIs.

    Regards,
    Colin Sampaleanu
    SpringSource
    Okay, what happens if I run the application at a co-location that our company maintains. I'm not distributing the software but my customers are using it via the web. Do I have to buy a license? D
  41. Re: GPL3 and FUD[ Go to top ]

    v3 of the GPL has clarified this question. To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying. Please refer to our FAQ or the GPL FAQ for further questions.
  42. Re: Re: Why GPLV3 ?[ Go to top ]

    FINALLY - someone who has a clue of how the GPL works. Thanks for elaborating Will. Note that applications built for internal use (i.e. internal customers) that use a GPL product don't have to worry about this issue. But the second they sell and ship the product to external customers, then they'll have to deal with that fact. So now that everyone understands this, do you all know that if you ship your product to customers and that product contains the MySQL JDBC .jar, that your product must also be GPL'd or if not, that you have to pay MySQL for a non-GPL version? I bet many people didn't know that. How many folks are rethinking their use of MySQL now? ;) (Use Postgres...). But, this is how open source developers make money, and that's not a bad thing (we all gotta eat). If you want professional developers to maintain a quality product, and you want it to be really good - they gotta get their paycheck some how. The GPL allows it to be open source for open collaboration and peer review, but also affords a financial avenue to the supporting company - they can sell their code under a separate license so the purchasing company does not have to abide by the GPL as well. And you're correct that JBoss is LGPL, but Fleury told me that he wished he had gone the GPL route if he had known better. The fact that JBoss had been a quality product on its own and they were able to sell support licenses is what allowed them to ignore forceful/imposing route of the GPL (force the licence or the cash on you - pick your poison) and become an open source powerhouse. I personally think SpringSource could have done the same thing with LGPL, but the GPL guarantees cash avenues for them that wouldn't have been possible under LGPL. Hence Marc's wish in retrospect.
  43. But, this is how open source developers make money, and that's not a bad thing
    Nope, that's not how Open Source works. Just how a VC founded startup tries to cash in.
    If you want professional developers to maintain a quality product, and you want it to be really good - they gotta get their paycheck some how. The GPL allows it to be open source for open collaboration and peer review, but also affords a financial avenue to the supporting company - they can sell their code under a separate license so the purchasing company does not have to abide by the GPL as well.
    Only in a venture capitalist's wildest dreams. Use their input, build up trust and then milk them. Fortunately for us, this will not work. SpringSource is doomed.
  44. Still waiting for the why EPL is compatible with GPL v3...
  45. Did the S2AP guys notice Neil Bartlett's comment?
    But EPL, as used by Equinox which you also bundle in S2AP, is not compatible with GPLv3. Could you tell us what your legal counsel advised with regard to this apparent problem?
    GPL and EPL licenses are completely incompatible (EPL to GPL and GPL to EPL). Products licensed under GPL cannot contain code licensed under EPL (and vice versa). It makes open source licensing for S2AP completely invalid. For more details read here: http://www.gnu.org/philosophy/license-list.html http://en.wikipedia.org/wiki/Eclipse_Public_License
  46. Nope, that's not how Open Source works. Just how a VC founded startup tries to cash in.
    I didn't say anything about how Open Source works - you need to read a little more accurately. I said that is how "open source developers make money". It is very hard to misconstrue that statement, but apparently it was easy enough for you. If I have an open source project, and I want to only work on that as my primary day job, then I must make money somehow. My statement about the GPL allowing dual licensing, one for free for open collaboration and peer review, the other for pay to allow distributed projects to stay closed source, remains.
    Only in a venture capitalist's wildest dreams.
    It works just great for MySQL ;) It works for other companies as well. Although I'd still be more comfortable with LGPL, lest I be required to pay SpringSource if I ship an application with the Platform embedded (even if I don't use the Platform's APIs directly), I still wish them the best of luck. Its a wonderful thing to get paid for working on open source as your day job!
  47. GPLV3 will not work for you[ Go to top ]

    If I have an open source project, and I want to only work on that as my primary day job, then I must make money somehow. My statement about the GPL allowing dual licensing, one for free for open collaboration and peer review, the other for pay to allow distributed projects to stay closed source, remains.
    Applies only to a small number of "distributed projects", i.e. sold products. Read Will Hartung's comment. Inhouse projects an the projects at your customers are not obliged by the GPL to publish any code. OTOH, dual licenses look like Shareware and will hardly attract many users.
  48. Re: Why GPLV3 ?[ Go to top ]

    I understand your reasoning for using GPL3 but it will keep your software out of a lot of companies -- even ones that would only be using it for internal purposes.
  49. Re: Why GPLV3 ?[ Go to top ]

    I understand your reasoning for using GPL3 but it will keep your software out of a lot of companies -- even ones that would only be using it for internal purposes.
    +1
  50. Re: Why GPLV3 ?[ Go to top ]

    Marc
    I understand your reasoning for using GPL3 but it will keep your software out of a lot of companies -- even ones that would only be using it for internal purposes.
    It's important that people understand that it is totally clear that the GPL3 does not impose any obligations on internal use. Period. No ambiguity. Again, from the GNU FAQ:
    A company is running a modified version of a GPL'ed program on a web site. Does the GPL say they must release their modified sources? The GPL permits anyone to make a modified version and use it without ever distributing it to others. What this company is doing is a special case of that. Therefore, the company does not have to release the modified sources. It is essential for people to have the freedom to make modifications and use them privately, without ever publishing those modifications.
    Companies who want to redistribute and sell a closed product on SpringSource Application Platform can approach us to obtain an alternative license for the GPL3 portions of the server platform. That's only fair. Because the GPL makes so much sense from this point of view--good for community, but requiring remuneration from companies who want to deliver closed products on open souce work--I think you will see more and more adoption of GPL (which is anyway already the most popular open source license). So I suspect the ignorant fear will subside. We also offer an alternative license for end users, but there is no reason they should choose that out of fear; only because it's part of a total package with other benefits. Rgds Rod
  51. Re: Why GPLV3 ?[ Go to top ]

    It's important that people understand that it is totally clear that the GPL3 does not impose any obligations on internal use. Period. No ambiguity.
    Rod, I can tell you for sure that even though what you say may be factually accurate, it makes no difference at all for many organizations. Many large organizations have blanket decreed that no GPL products are allowed anywhere in the organization, regardless of whether it's usage is internal-facing or client-facing. You can debate to the ends of the Earth whether that's a good decision or not... and I'd be leaning on the side of it being a bad decision myself frankly... but the fact is that many organizations have said the same type of thing. There's a perception of risk WRT the GPL's usage under any circumstances in many companies, whether that should be the case or not. I've heard a similar story from many architects and developers I've spoken to.
    ...I think you will see more and more adoption of GPL (which is anyway already the most popular open source license). So I suspect the ignorant fear will subside.
    My crystal ball is in the shop this week, so I can't prognosticate on the assertion about ignorant fears subsiding :) I can only speak to the here and now, and only there based on my own experience and anecdotal "evidence", and that experience and "evidence" leads me to think Marc raises a fair point. By the way, can you cite a reference that supports the assertion that the GPL is the most popular open-source license? You may well be correct, but I'd love to see supporting evidence (or is that an anecdotal assertion?) because it's not what I would have bet was the case. Frank W. Zammetti Author of "Practical DWR 2 Projects" and "Practical JavaScript, DOM Scripting and Ajax Projects" and "Practical Ajax Projects With Java Technology" for info: apress.com/book/search?searchterm=zammetti&act=search Java Web Parts - javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! My "only partially serious" blog: zammetti.com/blog
  52. Re: Why GPLV3 ?[ Go to top ]

    It's important that people understand that it is totally clear that the GPL3 does not impose any obligations on internal use. Period. No ambiguity.

    Rod, I can tell you for sure that even though what you say may be factually accurate, it makes no difference at all for many organizations.

    Many large organizations have blanket decreed that no GPL products are allowed anywhere in the organization, regardless of whether it's usage is internal-facing or client-facing. You can debate to the ends of the Earth whether that's a good decision or not... and I'd be leaning on the side of it being a bad decision myself frankly... but the fact is that many organizations have said the same type of thing. There's a perception of risk WRT the GPL's usage under any circumstances in many companies, whether that should be the case or not. I've heard a similar story from many architects and developers I've spoken to.

    ...I think you will see more and more adoption of GPL (which is anyway already the most popular open source license). So I suspect the ignorant fear will subside.

    My crystal ball is in the shop this week, so I can't prognosticate on the assertion about ignorant fears subsiding :) I can only speak to the here and now, and only there based on my own experience and anecdotal "evidence", and that experience and "evidence" leads me to think Marc raises a fair point.

    By the way, can you cite a reference that supports the assertion that the GPL is the most popular open-source license? You may well be correct, but I'd love to see supporting evidence (or is that an anecdotal assertion?) because it's not what I would have bet was the case.

    Frank W. Zammetti
    Author of "Practical DWR 2 Projects"
    and "Practical JavaScript, DOM Scripting and Ajax Projects"
    and "Practical Ajax Projects With Java Technology"
    for info: apress.com/book/search?searchterm=zammetti&act=search
    Java Web Parts - javawebparts.sourceforge.net
    Supplying the wheel, so you don't have to reinvent it!
    My "only partially serious" blog: zammetti.com/blog
    My bias 2 bits on the topic of GPL. I know of atleast 3 large US corporations with blanket prohibition of GPL software. By prohibition, I mean it's not allowed. By not allowed I mean anyone installing or downloading GPL software is subject to immediate dismissal. I'm willing to bet a significant percent of the fortune 100 companies in the US have similar blanket prohibition of GPL software. Makes absolutely no difference how the software is used. Did SpringSource make a gigantic mistake? Only time will tell, but my guess is this. Companies that create software policy based on what lawyers say are going to start prohibiting Spring, because of a perceived risk. Whether that risk is real or not doesn't make a difference. Don't take my word for it. Go ask the top 3 healthcare companies in the US if they have a strict policy against GPL software. Or go ask the top 5 US banks about their policy on GPL software. It doesn't really matter what GPL license says, if the lawyers advising business executives perceive a risk. peter
  53. Re: Why GPLV3 ?[ Go to top ]

    My bias 2 bits on the topic of GPL. I know of atleast 3 large US corporations with blanket prohibition of GPL software. By prohibition, I mean it's not allowed. By not allowed I mean anyone installing or downloading GPL software is subject to immediate dismissal.
    So they don't run Linux? The kernel (and much else) is GPL.
  54. Re: Why GPLV3 ?[ Go to top ]

    My bias 2 bits on the topic of GPL. I know of atleast 3 large US corporations with blanket prohibition of GPL software. By prohibition, I mean it's not allowed. By not allowed I mean anyone installing or downloading GPL software is subject to immediate dismissal.

    So they don't run Linux? The kernel (and much else) is GPL.
    Good point. There are exceptions like linux. Some shops allow linux if it came with the server. The point about not allowing developers to download or use GPL software isn't something I dreamed up. It's from first hand experience at large institutions and having software management tools that do daily audits of the software on each person's system. I don't agree with that kind of policy, but it's a reality in many fortune 100 companies. Plus, buying a server with Linux pre-installed is different than downloading and installing GPL software. Take IBM for example, they sell linux systems and use linux internally. Back when I worked at IBM, downloading and using GPL software was prohibited. To get approval requires a lengthy approval and clear justification. Even then, the lawyers may shoot the request down. For comparison, using software under apache license was acceptable, but still had to be approved by the lawyers. Considering some of spring's developers have experience with large institutions and a few have worked for IBM in the past, I'm sure you can confirm what I'm saying isn't FUD. I still have friends that worked at IBM and AFAIK, the GPL policy is still the same. In fact plenty of Apache committers are IBM employees, so it should be easy to confirm what I'm saying is factual. As I said, whether GPL is a huge mistake isn't clear to me. Only time will tell. I doubt anyone could make an accurate prediction. Even though the GPL faq states clearly the official stance, I've had corporate lawyers give different interpretations. Law rarely fits into 1 single interpretation, so it largely depends on how each business interprets it. It's clear that springsource doesn't consider it an issue, but you have no control over how businesses and lawyers interpret it. peter
  55. Re: Why GPLV3 ?[ Go to top ]

    Wow, 174 replies and counting, mostly about GPL, hmm, i knew I should have done law ;-) !!! ha ha Lets stay technical please, even though it clearly doesn't pay !!!
  56. Re: Why GPLV3 ?[ Go to top ]

    Wow, 174 replies and counting, mostly about GPL, hmm, i knew I should have done law ;-) !!! ha ha

    Lets stay technical please, even though it clearly doesn't pay !!!
    This is TSS, if you want technical, go on the Spring forums... Or better yet, check out www.infoq.com. Much better content and atmosphere.
  57. Re: Why GPLV3 ?[ Go to top ]

    Or better yet, check out www.infoq.com. Much better content and atmosphere.
    Nasty
  58. Re: Why GPLV3 ?[ Go to top ]

    Wow, 174 replies and counting, mostly about GPL, hmm, i knew I should have done law ;-) !!! ha ha

    Lets stay technical please, even though it clearly doesn't pay !!!
    I'm glad for the dicussion on GPL. I've learned something and how the ammo I need if the question arises.
  59. Re: Why GPLV3 ?[ Go to top ]

    Wow, 174 replies and counting, mostly about GPL, hmm, i knew I should have done law ;-) !!! ha ha

    Lets stay technical please, even though it clearly doesn't pay !!!


    I'm glad for the dicussion on GPL. I've learned something and how the ammo I need if the question arises.
    You should see the reaction when extjs changed their licensing from LGPL to GPL (http://www.extjs.com/forum/showthread.php?t=33096). Developers really hate GPL for the right/wrong reasons. At least, the spring guys are ethical. At least they are not changing their licensing from LGPL to GPL. It is GPL from day one. D
  60. Re: Why GPLV3 ?[ Go to top ]

    At least, the spring guys are ethical. At least they are not changing their licensing from LGPL to GPL. It is GPL from day one.
    What I find distasteful is what they are *not* saying. That they chose GPL only for busines gain, to dual-license and charge mula... I can just imagine how evil people would call JBoss if we did the same... Just goes to show you what a double standard TSS and others have.
  61. Re: Why GPLV3 ?[ Go to top ]

    At least, the spring guys are ethical. At least they are not changing their licensing from LGPL to GPL. It is GPL from day one.


    What I find distasteful is what they are *not* saying. That they chose GPL only for busines gain, to dual-license and charge mula...

    I can just imagine how evil people would call JBoss if we did the same... Just goes to show you what a double standard TSS and others have.
    Its not that there is a double standard. Its that the Spring guys don't grate on the nerves as much as the JBoss guys.
  62. Re: Why GPLV3 ?[ Go to top ]

    Wow, 174 replies and counting, mostly about GPL, hmm, i knew I should have done law ;-) !!! ha ha

    Lets stay technical please, even though it clearly doesn't pay !!!


    I'm glad for the dicussion on GPL. I've learned something and how the ammo I need if the question arises.


    You should see the reaction when extjs changed their licensing from LGPL to GPL (http://www.extjs.com/forum/showthread.php?t=33096).

    Developers really hate GPL for the right/wrong reasons.

    At least, the spring guys are ethical. At least they are not changing their licensing from LGPL to GPL. It is GPL from day one.

    D
    I saw that one. I was eyeballing myGWT for a while. I'm glad I didn't take the plunge like a couple of guys I know. Changing from LGPL to GPL really stinks and smacks of a trap.
  63. Re: Why GPLV3 ?[ Go to top ]

    Peter
    Companies that create software policy based on what lawyers say are going to start prohibiting Spring, because of a perceived risk.
    There is no change to the Spring Framework's licensing, as I've repeatedly stated on this thread and elsewhere. It's still Apache 2.0. So anyone "prohibiting Spring" would be (a) misinterpreting the GPL license of a different product and (b) not reading the license of Spring itself. Perhaps you mean "SpringSource Application Platform" rather than Spring? Rgds Rod
  64. Re: Why GPLV3 ?[ Go to top ]

    Frank
    By the way, can you cite a reference that supports the assertion that the GPL is the most popular open-source license? You may well be correct, but I'd love to see supporting evidence (or is that an anecdotal assertion?) because it's not what I would have bet was the case.
    GPL is the most popular open source license, and by a huge margin. Some statistics:
    • 62.8% of projects tracked on freshmeat are GPL
    • As of November 2003 71% of projects on SourceForge were GPL (I'm trying to find a more recent link, I know I saw one a few weeks ago, and of course the proportion was similar)
    See this article for some more links. I think this bears out my points about some of the fear about GPL reflecting a lack of information. As for actual usage of GPL, A 2003 survey of DoD use of OSS found that 52% of applications were GPL. Rgds Rod
  65. Re: Why GPLV3 ?[ Go to top ]

    Rod, I can tell you for sure that even though what you say may be factually accurate, it makes no difference at all for many organizations.
    There may be some organizations who choose an interpretation of the GPL that is at variance with the unambiguous facts. In which case they can either not use the software or purchase an alternative license. If they're that risk averse, they are unlikely to be using open source software without commercial support in any case. But bear in mind that MySQL, Linux and many other open source projects are already widely adopted and are wholly or contain much GPL. Licensing choice is always a tradeoff and we see no reason to reject the most common open source license which is a good fit for what we want to do because of ignorance in some quarters. Rgds Rod
  66. Re: Why GPLV3 ?[ Go to top ]

    to make it more clear: - using GPLed Spring app platform with closed source app(s) IS ok - modifying/extending GPLed Spring app platform and hiding it IS NOT ok - modifying/extending GPLed Spring app platform and sharing it (the platform only) + deploying closed source app(s) on it IS ok is that correct?
  67. Re: Why GPLV3 ?[ Go to top ]

    to make it more clear: 1. using GPLed Spring app platform with closed source app(s) IS ok 2. modifying/extending GPLed Spring app platform and hiding it IS NOT ok 3. modifying/extending GPLed Spring app platform and sharing it (the platform only) + deploying closed source app(s) on it IS ok is that correct?
    1. Using the platform to run closed source applications is OK. This immediately covers the vast majority of companies and developers who are end users. This would cover for example, software use by companies like Google, banks, media companies etc. 2. Modifying and extending the platform and "hiding" (closing) it is OK, unless you redistribute. So if you modify it in your own company, or you modify it and distribute your modifications in GPL open source, that's OK. If you modify it and distribute a closed source product including those modifications, that is not OK. This would exclude Oracle, for example, from modifying the server and redistributing it as a closed source product. We believe this is a Good Thing. 3. It is fine to run closed source applications on the platform. Whether you can redistribute them as one closed product (bundling the platform) would depend if they constituted a derivative work.
  68. GPL/EPL compatibility[ Go to top ]

    Where is the answer to the Eclipse Public License incompatibility with GPL? As it stands right now, S2AP doesn't seem to be properly licensed under GPL and makes it really murky in terms of what actual license the app server is distributed under. Also, in regard to
    # 62.8% of projects tracked on freshmeat are GPL # As of November 2003 71% of projects on SourceForge were GPL (I'm trying to find a more recent link, I know I saw one a few weeks ago, and of course the proportion was similar)
    I bet that large number of these projects are incorrectly licensed under GPL by reusing code from incompatible licenses. I haven't really done any checking, but I just saw another very similar popular LGPL/GPL project falling into the same EPL/GPL incompatibility trap.
  69. Where is the answer to the Eclipse Public License incompatibility with GPL?

    As it stands right now, S2AP doesn't seem to be properly licensed under GPL and makes it really murky in terms of what actual license the app server is distributed under.
    Wouldn't it be enough for them to add a clause similar to the "system library exception"? As long as they use libraries that allow this there shouldn't be a problem I think. See: http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs
  70. Re: Why GPLV3 ?[ Go to top ]

    3. modifying/extending GPLed Spring app platform and sharing it (the platform only) + deploying closed source app(s) on it IS ok
    is that correct?
    3. It is fine to run closed source applications on the platform. Whether you can redistribute them as one closed product (bundling the platform) would depend if they constituted a derivative work.
    That hand wavy "maybe" means "No, it's not ok". Shipping anything with S2AP is a derivative work in the eyes of the GPL, whether you change S2AP itself or not. As an ISV, you would have to do the final integration at the client site on top of S2AP rather than being able to ship a combined application.
  71. Re: Why GPLV3 ?[ Go to top ]

    And what about vendor-lock in ?
    To be truthful, I have been concerned over this for quite some time. The ultimate answer from my perspective has been that this really belongs on the shoulders of the developer, we just have to make sure the "artificial barriers" to adopting the Java EE standard is lowered as much as possible and hope for the best possible outcome for all of us. As explained in some of the other posts here, the most problematic non-standard portions of this is the PAR format and any hard dependency on Spring specific APIs. Fortunately, this platform appears to be quite open and extensible on first blush. This means that you could potentially extend it to support all Java EE APIs including EJB 3.x (and yes, even legacy Entity Beans) and EAR deployments. I am working to implement a project to do just that. To my relief, the SpringSource folks seem very supportive of the effort so far, which makes me hope that they do have the right intentions at heart and have not allowed self-interest (or blind bias) to override doing the right thing for the community at large. If that wasn't the case, I think the writing would be on the wall for them pretty soon. I have faith that the Java centric community has way too many smart, passionate, independent folks for things to stray that far in any bad direction. Developers using the Spring platform can still make their applications fully Java EE compliant and minimize dependency on non-standard APIs if they so choose just by adding a few plug-ins similar to what I am trying to do on top of the platform. Such plug-ins could be implemented to be as thin as possible by heavily relying on Spring APIs themselves. The bigger question on my mind is how quickly Java EE supports OSGi interoperability. I believe this problem will be solved in the Java EE 6 time-frame due to a proposal to expand the DI capabilities of Java EE complaint application servers, but we will see how it goes... Cheers, Reza P.S.: Incidentally, if you are interested in helping me write the Spring-EJB/Java EE bridge mentioned above, please do email me at reza_rahman at lycos dot com. I could use all the help I can get :-).
  72. Re: Why GPLV3 ?[ Go to top ]

    My real concern is (and always) has been vendor lock-in. Most of the power of spring still came from the underlying containers and integration other libraries (e.g Hibernate). Would the big companies (not talking about small websites ) giver up their platform for Spring+OSGI combination that is unproven in any environment (not talking about spring over other containers)? what advantage would I get by locking myself into spring platform when I can get the same from other platforms (e.g Glassfish on with Osgi ) and remain *standard compliant*? Also the JEE does provide a full POJO model (although with limited DI) so complexity of a EJB3/JPA implementation should be similar to that of Spring/JPA. Unless Spring becomes JEE (atleast profiles A, B) compliant it would have difficulty in adoption in some big companies/banks I know of...
  73. Re: Why GPLV3 ?[ Go to top ]

    what advantage would I get by locking myself into spring platform when I can get the same from other platforms (e.g Glassfish on with Osgi ) and remain *standard compliant*?
    The Platform enables applications to be constructed from OSGi bundles and then deployed and managed as applications and not simply as collections of bundles. Applications are understood by the platform and are used to provide a scope that stops exported packages and services of distinct applications from colliding and that provides a boundary for context class loading and load-time weaving support. Glassfish v3 has a stated requirement to "Support OSGi as a means for 3rd parties to extend the functionality of the application server", but I don't see any evidence that OSGi will be exposed to applications. Maybe someone from Glassfish would like to comment? Oh, and don't forget that OSGi is a standard. Glyn Normington SpringSource
  74. Re: Why GPLV3 ?[ Go to top ]

    what advantage would I get by locking myself into spring platform when I can get the same from other platforms (e.g Glassfish on with Osgi ) and remain *standard compliant*?


    The Platform enables applications to be constructed from OSGi bundles and then deployed and managed as applications and not simply as collections of bundles. Applications are understood by the platform and are used to provide a scope that stops exported packages and services of distinct applications from colliding and that provides a boundary for context class loading and load-time weaving support.

    Glassfish v3 has a stated requirement to "Support OSGi as a means for 3rd parties to extend the functionality of the application server", but I don't see any evidence that OSGi will be exposed to applications. Maybe someone from Glassfish would like to comment?

    Oh, and don't forget that OSGi is a standard.

    Glyn Normington
    SpringSource
    I was talking about the Spring Application Server (or is it "The Platform") that *IS* non standard , never said anything about OSGi (didn't I say Glassfish + OSGi is standard compliant?). Regarding Glassfish and OSGI, Jerome Dochez has clarified this here http://www.infoq.com/news/2008/04/springsource-app-platform. So it seems that your "platform/server" has only a subset of functionality of (Glassfish + OSGi) combination. Also contrary to what some of other people posting here have said there is and will be an *IMPLICIT* springsource lock-in (dependency on context, API, patterns etc).
  75. Re: Why GPLV3 ?[ Go to top ]

    what advantage would I get by locking myself into spring platform when I can get the same from other platforms (e.g Glassfish on with Osgi ) and remain *standard compliant*?


    The Platform enables applications to be constructed from OSGi bundles and then deployed and managed as applications and not simply as collections of bundles. Applications are understood by the platform and are used to provide a scope that stops exported packages and services of distinct applications from colliding and that provides a boundary for context class loading and load-time weaving support.

    Glassfish v3 has a stated requirement to "Support OSGi as a means for 3rd parties to extend the functionality of the application server", but I don't see any evidence that OSGi will be exposed to applications. Maybe someone from Glassfish would like to comment?

    Oh, and don't forget that OSGi is a standard.

    Glyn Normington
    SpringSource

    I was talking about the Spring Application Server (or is it "The Platform") that *IS* non standard , never said anything about OSGi (didn't I say Glassfish + OSGi is standard compliant?).
    Regarding Glassfish and OSGI, Jerome Dochez has clarified this here
    http://www.infoq.com/news/2008/04/springsource-app-platform.

    So it seems that your "platform/server" has only a subset of functionality of (Glassfish + OSGi) combination.
    Also contrary to what some of other people posting here have said there is and will be an *IMPLICIT* springsource lock-in (dependency on context, API, patterns etc).
    Jerome clarified in that post that Glassfish has exposed extension points, and talks about the (potential) ability to embed containers like the SpringSource one, therefore allowing apps in the Spring container to have access to the full OSGi apis. He did not say that otherwise, users could simply deploy standard OSGi bundles, have access to the full OSGi apis, and therefore use a full OSGi component model. Hopefully he can clarify that part, but you are putting words in his mouth (that he didn't say)... Additionally, there are the other aspects already discussed in threads here, related to classloader handling, load time weaving, etc., where the SpringSource Platform does some pretty heavy lifting, and makes the OSGi end-user experience a lot friendlier. Regards, Colin SpringSource
  76. Springsource == shaky company[ Go to top ]

    yes, there is a vendor lock-in! And what's worse, Springsource is a small privately owned company that is living of the venture capital by Benchmark Capital I wouldn't be surprised if Springsource was bleeding money, as many of the consultants it employs are top names in the Java world and probably receive high salaries. As long Springsource isn't publishing its finances on its website, so that everyone can check whether the company is financially sound, it is crazy to make a decision for the Spring framework and against the JEE standard.
  77. Malicious FUD[ Go to top ]

    Ralf
    And what's worse, Springsource is a small privately owned company that is living of the venture capital by Benchmark Capital. I wouldn't be surprised if Springsource was bleeding money...
    Pure FUD and complete speculation. We are in a very strong financial position. This company is going to stick around for the long term. We have hundreds of subscription customers and thousands of training customers. Those customers include 9 of the world's 10 largest banks; they feel very comfortable doing business with us. Our revenue is growing rapidly worldwide and we exceeded our 2007 plan. The series of announcements we've made this year and will continue to make over the next few months clearly show successful this company is. Far from being purely dependent on Benchmark Capital, we had grown our business successfully for nearly 3 years before taking funding. Let's talk about technology rather than malicious speculation about things you have no knowledge of.
    As many of the consultants it employs are top names in the Java world and probably receive high salaries.
    You've noticed--we employ many of the best developers in the Java world. That's why we provide real leadership, deliver some of the best technology in the Java world and are building a great company around it. That's a key reason why we will enjoy great success.
    As long Springsource isn't publishing its finances on its website, so that everyone can check whether the company is financially sound, it is crazy to make a decision for the Spring framework and against the JEE standard.
    Private companies do not normally publish numbers. Secondly, you are posing a false dichotomy of Spring vs Java EE. A majority of Java EE users at this point (according to Forrester analysts, not SpringSource) use Spring, which integrates closely with Java EE. Second, both the CEO and CTO of SpringSource have publicly commented on this thread that we intend to implement Profiles A and B of the forthcoming Java EE 6. We will not implement Profile C (full platform) because that profile is not demanded by our users and customers and because we believe it represents the past of Java EE, not the future. Let me reiterate why your charges of vendor lock-in are false: The Platform supports applications packaged in three forms: - Java EE WAR - Raw OSGi bundles - Platform Archive (PAR) Standard WAR files are supported directly in the Platform. At deployment time, the WAR file is transformed into an OSGi bundle and installed into Tomcat. All the standard WAR contracts are honoured, and your existing WAR files should just drop in and deploy without change. Any OSGi-compliant bundle can be deployed directly into the Platform, and can take full advantage of on-the-fly provisioning for any dependencies referred to by Import-Package and Require-Bundle. Thus we support two standards for deployment: WAR deployment and OSGi bundles. We provide a third format based on a standard, because there is no existing standard that meets that need. We are engaged in the JCP, the OSGi Alliance and other standards efforts. We do not ask people to write code to our platform. The Spring programming model is non-invasive and portable between containers. Thus it does not tie you to the SpringSource Application Platform. We also offer the Java EE web stack. Rgds Rod
  78. Still ASL 2.0 license?[ Go to top ]

    Rod, let me ask this question again... Can anyone from SpringSource make a clear statement on the future licensing policy for the Spring Framework? Will it be still ASL 2.0 or do you have plans to change this to GPL, too? I'm asking because Rod's statement "We have no plans to change the licensing of existing code" looks quite evasive to me. TIA Rgds P.
  79. Can anyone from SpringSource make a clear statement on the future licensing policy for the Spring Framework? Will it be still ASL 2.0 or do you have plans to change this to GPL, too?
    We are not changing the licensing of the Spring Framework. It will remain ASL 2.0. Yesterday's announcement concerns a SpringSource product distinct from the Spring Framework, which uses a different license. We are not changing a license, but talking about a new product. Thus I'm surprised this question is even being brought up.
  80. Re: Still ASL 2.0 license?[ Go to top ]

    Can anyone from SpringSource make a clear statement on the future licensing policy for the Spring Framework? Will it be still ASL 2.0 or do you have plans to change this to GPL, too?

    We are not changing the licensing of the Spring Framework. It will remain ASL 2.0.

    Yesterday's announcement concerns a SpringSource product distinct from the Spring Framework, which uses a different license. We are not changing a license, but talking about a new product. Thus I'm surprised this question is even being brought up.
    Well, don't be surprised. :-) I thought the same thing. GPL brings out that reaction. Heck, just last week, myGWT completed their migration to GPL from LGPL and didn't give a heads up, so I think that questions WRT GPL should not only be expected, but dealt with head on. I think your post answers that, but perhaps a FAQ or separate announcement would spread the word.
  81. Re: Still ASL 2.0 license?[ Go to top ]

    Can anyone from SpringSource make a clear statement on the future licensing policy for the Spring Framework? Will it be still ASL 2.0 or do you have plans to change this to GPL, too?

    We are not changing the licensing of the Spring Framework. It will remain ASL 2.0.

    Yesterday's announcement concerns a SpringSource product distinct from the Spring Framework, which uses a different license. We are not changing a license, but talking about a new product. Thus I'm surprised this question is even being brought up.
    When everything is called SpringSomethingOrOther and many disparate products in the suite are often referred to as one thing, I find it amazing that you'd be surprised at the confusion. After all, it's just "Spring" isn't it ?
  82. Absolutely no FUD[ Go to top ]

    Second, both the CEO and CTO of SpringSource have publicly commented on this thread that we intend to implement Profiles A and B of the forthcoming Java EE 6. We will not implement Profile C (full platform) because that profile is not demanded by our users and customers and because we believe it represents the past of Java EE, not the future.
    yes, I wholeheartedly agree. There is no need for outdated EJB 2.x stuff. No one needs really needs profile C. Customers demand EJB 3.1 light (profile B) however. I do not understand the discussion about licensing issues. Who really cares about that? If a bank chooses the Springframework, it should have no problems at all to pay for licensing or subscription. Customers pay for SAP and other software too. And We need consolidation in the Java framework space, not zillions of competing frameworks. My number one concern remains the viability of Springsource as a company. And therefore I think it's absolutely positive if Springsource changes the licensing in a way that allows it to better make money and thrive as a company. Yes, the latter is absolutely vital when developers have to be paid salaries.
  83. Re: Absolutely no FUD[ Go to top ]

    There is no need for outdated EJB 2.x stuff. No one needs really needs profile C. Customers demand EJB 3.1 light (profile B) however.
    Ralf: Fortunately, Rod's indicated that there is a willingness to start a Spring module to support this. The scope of this is TBD and could potentially include EAR support and beyond. In the worst case scenario, I would start it anyways and make it available for Spring plugability, probably either from Apache or Sourceforge (admitedly it's going to be a tall task if not supported by SpringSource, but not impossible; where there is a will there is a way). Cheers, Reza
  84. Re: Absolutely no FUD[ Go to top ]

    I do not understand the discussion about licensing issues. Who really cares about that?
    Obviously many people do. You might agree if you took the time to learn about possible issues and issues in the past.
    If a bank chooses the Springframework, it should have no problems at all to pay for licensing or subscription. Customers pay for SAP and other software too.
    So... banks are the only companies who would use SpringFramework? Everyone should use commercial closed source software because they have been doing in the past?
    And We need consolidation in the Java framework space, not zillions of competing frameworks.
    Yeah, let's regulate the market. I'd love people like you to tell me what's good for me. We should forbid people to try to make the wheel rounder. And definitively tell them to pay for software. It will be great.
    My number one concern remains the viability of Springsource as a company. And therefore I think it's absolutely positive if Springsource changes the licensing in a way that allows it to better make money and thrive as a company.

    Yes, the latter is absolutely vital when developers have to be paid salaries.
    We have a B. We have an S. BS!
  85. Re: Malicious FUD[ Go to top ]

    Pure FUD and complete speculation. We are in a very strong financial position. This company is going to stick around for the long term.
    Right, which is why you received VC funding -- I guess you took the money and have it sitting in your business bank account collecting interest? I don't think so. You're looking to scale up your business, and you need the cash to help shorten the time this is going to take. The VC people are looking for an ROI within a finite amount of time, usually 3-6 years, which means your company is eventually going public or will be acquired. I can't see this new application server product generating the level of market share that's going to be required to go public seeing as there are plenty of other companies already in this space -- companies which have a much longer history, more customers, and the capabilities to take the solution your business has produced and incorporate similar functionality into their own product, if the competition deems it important enough. Good luck, you're going to need it. Tom
  86. Re: Malicious FUD[ Go to top ]

    You're looking to scale up your business, and you need the cash to help shorten the time this is going to take.
    This is exactly what VC is actually supposed to make easier.
    The VC people are looking for an ROI within a finite amount of time, usually 3-6 years, which means your company is eventually going public or will be acquired.
    Oh no, often they are much more impatient. And they're typically expecting a return of investment (ROI) in the order of 20-30% per year! (This high return is not only needed to pay high salaries and administration costs of the VC fund managers, but also because it is important to keep in mind that many VC investments in startups fail so the successful investments have to compensate the losses). And regarding all the talk about the role of the community. It's nice if the "community" does something for free. But developers need to be paid. It may be exciting to contribute to a new framework or project. But once this project got mature it becomes much more boring to maintain it. It's also important to write excellent documentation. Who should do that? The community for free? Or do you teckies have too much spare time and no family? So nothing wrong if Springsource changes the licensing in way that better allows the company to make money, in particular given the circumstance that the Springframework is touted as a framework for Enterprise apps. Leave the license discussions to the Linux or FSF communists like Richard Stallmann.
  87. Re: Malicious FUD[ Go to top ]

    Btw: It is striking that in this Java Enterprise Community (TheServerside.com) economic issues are never discussed. Right on my realtime screen: Sun Microsystems (Java): -19.47% on disappointing results.
  88. Re: Malicious FUD[ Go to top ]

    Btw: It is striking that in this Java Enterprise Community (TheServerside.com) economic issues are never discussed.

    Right on my realtime screen:

    Sun Microsystems (Java): -19.47% on disappointing results.
    sorry, it should read: Right _now_ on my realtime screen:
  89. Re: Malicious FUD[ Go to top ]

    Btw: It is striking that in this Java Enterprise Community (TheServerside.com) economic issues are never discussed.

    Right on my realtime screen:

    Sun Microsystems (Java): -19.47% on disappointing results.


    sorry, it should read:

    Right _now_ on my realtime screen:
    Time to buy some Sun! :)
  90. Re: Malicious FUD[ Go to top ]

    Thomas
    We are in a very strong financial position.
    Right, which is why you received VC funding
    VC funding is a normal part of growing a great software company. Oracle, WebLogic and BEA are three relevant examples in our industry--all VC funded. Rgds Rod
  91. Re: Malicious FUD[ Go to top ]

    Thomas
    We are in a very strong financial position.
    Right, which is why you received VC funding
    VC funding is a normal part of growing a great software company. Oracle, WebLogic and BEA are three relevant examples in our industry--all VC funded.

    Rgds
    Rod
    Actually Im pretty sure that Oracle grew organically and didnt take any VC funding. But I agree with your underlying premise that there is nothing wrong with VC funding. If you see a market that ripe for the picking and you need to grow fast, then VC is pretty much the only answer.
  92. Re: Malicious FUD[ Go to top ]

    Berry Oracle received at least one round, from Sequoia Capital. Another example I forgot: Red Hat. It would be far harder to find a successful software company that did not take funding. Rgds Rod
  93. Re: Malicious FUD[ Go to top ]

    Thomas
    We are in a very strong financial position.
    Right, which is why you received VC funding
    VC funding is a normal part of growing a great software company. Oracle, WebLogic and BEA are three relevant examples in our industry--all VC funded.

    Rgds
    Rod
    Thanks for the lecture Rod. Frankly I have no issue with your company taking VC money. You stated "We are in a very strong financial position. This company is going to stick around for the long term." -- however the VC people are looking for an ROI and they won't wait around for ages to get it, especially considering the failure rate of venture backed businesses. Ultimately, there really are only 2 channels to exit: go public, or get bought up, and it's likely expected that this will happen within a few years. Whether or not your business will become the next BEA, Oracle, etc. has yet to be seen, but jumping into markets which are already saturated with competition is not a sign of a winning proposition as far as I'm concerned. I've been in several startup businesses over the past twelve years, and I've heard all the bullshit over and over, and it's the same in every company: "the pipeline is about to burst", "we're planning to go public Q1 of 200X", etc. Next thing, the company doesn't meet it's targets and the VC people bring in their own management, start screwing with the business model in ways one could not imagine, and generally screw things up to the point where the company hasn't a hope in the world. Your glass may have electric in the kool-aid, but don't assume mine does. Tom
  94. Re: Malicious FUD[ Go to top ]

    Thomas, I'm happy that I don't share your cynicism. Sure, many startups fail. However, we're a long way down the path, and have long been a real business. We have hundreds of customers, great technology, significant and rapidly growing revenue, a great team... WebLogic could have taken your view that basically starting a software business is hopeless. They were facing much larger competitors (such as IBM). But they built a better product and it kickstarted an industry. Seriously, we should be talking about technology on this thread rather than having this pointless discussion. Rgds Rod
  95. Re: Malicious FUD[ Go to top ]

    Thomas,

    I'm happy that I don't share your cynicism. Sure, many startups fail. However, we're a long way down the path, and have long been a real business. We have hundreds of customers, great technology, significant and rapidly growing revenue, a great team...

    WebLogic could have taken your view that basically starting a software business is hopeless. They were facing much larger competitors (such as IBM). But they built a better product and it kickstarted an industry.

    Seriously, we should be talking about technology on this thread rather than having this pointless discussion.
    Rgds
    Rod
    "[my] view that basically starting a software business is hopeless." Where did I say that? And don't tell me that's what I meant either because that, my friend, is bullshit. You have no idea of my background and interest in startup businesses, my experience, and I'm not about to elaborate on it here. Remember, it's not me that released this product announcement on TSS, and it's not me that decided to jump into a market where JBoss was years ago, and it's not me that claimed that "This company is going to stick around for the long term" when your window of opportunity is very clearly time limited. I should also note that it was not me who said the following: "Another link between these acquisitions are that Sun and Oracle now appear to be on a collision course. Oracle history shows their utter determination to crush any competitors in the database space, and their ability to do so. Sun is now a competitor in that highly profitable core business. With the loss of momentum from JBoss, the Java EE application server market now looks set to be a two-horse race between IBM and Oracle. Glassfish gives Sun a dark horse in this race, but it's unclear whether this market category will show the growth to accommodate a new entrant, given the growing predominance of Tomcat as a production platform." http://blog.springsource.com/main/2008/01/16/the-power-of-adoption-why-no-company-is-big-enough-to-deny-developers-what-they-want/ This, my friend, was all said by *you*. Oh and guess who owns WebLogic now? Tom
  96. Re: Malicious FUD[ Go to top ]

    Another link between these acquisitions are that Sun and Oracle now appear to be on a collision course. Oracle history shows their utter determination to crush any competitors in the database space, and their ability to do so. Sun is now a competitor in that highly profitable core business. With the loss of momentum from JBoss, the Java EE application server market now looks set to be a two-horse race between IBM and Oracle. Glassfish gives Sun a dark horse in this race, but it's unclear whether this market category will show the growth to accommodate a new entrant, given the growing predominance of Tomcat as a production platform.
    I stand by my point when I wrote that. There's no room for another Java EE commodity server. That's why we didn't build one. It's interesting to see that Glassfish is starting to position itself differently to the large incumbents also...
  97. Re: Malicious FUD[ Go to top ]

    Another link between these acquisitions are that Sun and Oracle now appear to be on a collision course. Oracle history shows their utter determination to crush any competitors in the database space, and their ability to do so. Sun is now a competitor in that highly profitable core business. With the loss of momentum from JBoss, the Java EE application server market now looks set to be a two-horse race between IBM and Oracle. Glassfish gives Sun a dark horse in this race, but it's unclear whether this market category will show the growth to accommodate a new entrant, given the growing predominance of Tomcat as a production platform.

    I stand by my point when I wrote that. There's no room for another Java EE commodity server. That's why we didn't build one. It's interesting to see that Glassfish is starting to position itself differently to the large incumbents also...
    Lost momentum? lol...you crack me up....You wish. Maybe if you close your eyes and wish hard enough... -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com
  98. Re: Malicious FUD[ Go to top ]

    Lost momentum? lol...you crack me up....You wish. Maybe if you close your eyes and wish hard enough...
    I do agree that the statement about "commodity" servers and "two horse races" are a little too much and aim to predict the impossible in a pretty fluid market. This is really moving more and more away from a discussion about technical merit to something more of a flame-driven morass triggered by hype and FUD. I really would have expected better from SpringSource. Maybe the "totally rocks" header is a little over the top as well. At heart, this is really just an application server that supports a subset Java EE profile + OSGi bundles + Spring. Frankly, I think that's what all the app servers are going to look like in pretty short order. Add to that the fact that this platform will not likely support WebBeans out-of-the-box, I am not so sure this level of self-congratulatory statements are really in order... Peace, Reza
  99. Re: Malicious FUD[ Go to top ]

    Add to that the fact that this platform will not likely support WebBeans out-of-the-box, I am not so sure this level of self-congratulatory statements are really in order...

    Peace,
    Reza
    Reza, It is my understanding that WebBeans will be part of the Java EE 6 B Profile. If that is the case, then S2AP *will* support WebBeans out of the box - just not in the 1.0 release. Regards, Rob
  100. Web Beans[ Go to top ]

    Reza
    Add to that the fact that this platform will not likely support WebBeans out-of-the-box, I am not so sure this level of self-congratulatory statements are really in order...
    Web Beans is non-final. No one has an implementation because there's no signed off spec to implement. Adrian and I have already said here and elsewhere that we will implement Profiles A and B, which is likely to include Web Beans. Btw a third party (not SpringSource) at the recent JAX conference in Germany gave a talk demonstrating how easy it was to implement the Web Beans functionality on top of Spring, with working examples. Rgds Rod
  101. Re: Malicious FUD[ Go to top ]

    Reza
    Maybe the "totally rocks" header is a little over the top as well. At heart, this is really just an application server that supports a subset Java EE profile + OSGi bundles + Spring. Frankly, I think that's what all the app servers are going to look like in pretty short order.
    I agree that we've implemented something other vendors will try to catch up with. However, doing so was non-trivial (far more than assembling existing pieces), and we will be working vigorously to retain our leadership. As we see more competition with similar products, of course it will provide a validation of what we're doing and the importance of this week's release. Bring on the competition--it will be good for everyone! Rgds Rod
  102. And what's worse, Springsource is a small privately owned company that is living of the venture capital by Benchmark Capital
    Can't believe I'm defending Spring guys :) but this is just plain idiotic... So does almost every succesfull startup that I know of! SpringSource is doing a right thing trying to monetize their huge user base. It is a business and NOT a social community. As long as they keep Spring Framework development under ASL 2.0 (which they promise to do) I don't see any conflicts and only a normal (and logical) business decisions. I blogged recently that professional open source is a hard, cut-throat and slow growth business. SpringSource is doing a heavy lifting and we shall see how successful they will be. Best, Nikita Ivanov. GridGain - Grid Computing Made Simple
  103. And what's worse, Springsource is a small privately owned company that is living of the venture capital by Benchmark Capital


    Can't believe I'm defending Spring guys :) but this is just plain idiotic... So does almost every succesfull startup that I know of!
    of course it's not PLAIN idiotic. You proved it yourself, stating that Springsource is a startup. As a matter of fact, Springsource is a small VC backed company that tries to establish own proprietary standards in the Java world. To put things into perspective, even Sun Microsystem is a shaky company. As a matter of fact, Sun is making not much money whith Java. Just compare operating margins: Microsoft: Operating Margin (ttm): 36.77% Oracle Corp: Operating Margin (ttm): 34.58% Adobe Systems Inc. (ADBE): Operating Margin (ttm): 29.13% SAP: Operating Margin (ttm): 26.65% Red Hat Inc. (RHT): Operating Margin (ttm): 13.46% Sun Microsystems (JAVA) Operating Margin (ttm): 5.74% (disappointing, low profitability implies that they cannot employ enough developers to enhance the Java platform.).
  104. or put in other words: How many developers are employed by Springsource to maintain and enhance Spring MVC and Web flow? You can count that with one hand. In the case of JBoss (for ex. Seam): basically they're facing the same problems. At least there are a few Red Hat developers working full-time on Seam, although this very innovative project is unfortunately understaffed too. Nevertheless, in total it is at present the most sensible platform for traditional serverside Java webapps and the most pragmatic framework for the Java world to really compete against ASP.NET. Other frameworks such as Wicket for example: Nice and innovative approach. But it's a waste of time to learn these alternative frameworks, as long as these frameworks are not maintained by financially healthy companies.
  105. Ralf SpringSource is a successful, growing company. Its growth is producing the ability to expand the resources we put into software. The community benefits. Our customers benefit. SpringSource is not resource constrained. This is evident from the fact the we are making an enormous ongoing commitment to the Spring Portfolio. I prefer facts to speculation. Consider some recent project major releases: Watch for Spring Web Flow 2.0, a major release due out very soon, which includes Spring JavaScript and Spring Faces for extensive AJAX support. I could go on, but I hope you get the idea... Rgds Rod
  106. Re: Spring's Web Portfolio[ Go to top ]

    To echo what Rod said here, we are delivering enormous amounts of innovation and integration in the Web space at present, more than we ever have in our history, and we will continue to do so in the future. I have a fully staffed development team working with me full-time across two continents on our Spring Web portfolio. In addition, we have close group of customers and community members that contribute meaningful ideas, patches, and extensions on a daily basis. Here are some of the things we have done recently: - We have delivered a POJO-based programming model for implementing Spring MVC control logic, based on the concept of annotated @Controllers. This includes support for auto-detecting and configuring @Controllers, as well as applying convention-based URL @RequestMapping policies. Spring MVC has always been one of the most flexible MVC frameworks, and now the core programming model is considerably simpler as well. When you add in the support we now have for running OSGi-enabled Spring MVC applications, where you can redeploy your entire web tier or a module of your web-tier without a container restart, you are looking at significant productivity gains during development and more flexibility with a smaller footprint at runtime. - Web Flow 2.0 represents a great leap forward for the Web Flow product itself, as well as our overall web portfolio. The 2.0.0 distribution introduces first-class support for handling Ajax events, securing flows, flow-managed persistence, Java Server Faces, and brings a simpler flow definition language introducing major new features such as flow definition inheritance, view backtracking policies, model-driven validation, and comprehensive EL integration. Have you seen our reference applications yet? Significant investment has been made on showing the community how you can design and build rich web applications with these technologies--the foundation starts with Spring MVC and it builds out from there. - We have introduced a new module called Spring JS (JavaScript) that ships with the Web Flow 2.0.0 distribution. Spring JS provides a lightweight abstraction over leading JavaScript toolkits such as Dojo 1. It provides a common client-side programming model for progressively enhancing a web page with rich Javascript widgets and Ajax remoting. Because its JavaScript, it is usable by any server-side framework. Because we build on an established UI toolkit, we don't reinvent the wheel - we simply make the underlying toolkit more accessible by providing a concise public API, while still allowing access to the full power of the underlying toolkit. Our reference application shows how to use the Spring.js API to progressively add Ajax, effects, and client-side validation behaviors. Turn Javascript off and those apps still are accessible. In addition, our JSF support builds on Spring.js to provide a set of declarative JSF components for these behaviors. - We have introduced a new module called Spring Faces, which provides complete JSF integration for a Spring MVC and Web Flow environment. I am really proud of my team for the work they have done here, as we've been able to show successfully you can integrate the core bread-n-butter of JSF, it's standard UI component model, into an existing, familiar MVC environment without losing any power. We have proven that the major component libraries work natively with this integration approach, and we will be continuing to work closely with JSF component providers and the JSF EG to ensure this in the future. In the future we have big goals that will address several key areas for our community in the web space. You'll see us address declarative model validation in a big way in the next release, important architectural topics like REST, and explore scripting languages as a means of defining control flow by elegantly mixing declarative and imperative constructs.
  107. Ralf

    SpringSource is a successful, growing company. Its growth is producing the ability to expand the resources we put into software. The community benefits. Our customers benefit.

    SpringSource is not resource constrained. This is evident from the fact the we are making an enormous ongoing commitment to the Spring Portfolio.

    I prefer facts to speculation. Consider some recent project major releases:
    Watch for Spring Web Flow 2.0, a major release due out very soon, which includes Spring JavaScript and Spring Faces for extensive AJAX support.

    I could go on, but I hope you get the idea...

    Rgds
    Rod
    Frankly, the statement about Acegi makes me laugh. I know someone that is suffering horribly trying to get Spring Webservices + Acegi working against a secure Webservice written in RAD deployed on Websphere. In fact, acegi works so well they decided to look else where, since it just wasn't working nicely with the webservice on Websphere. maybe if Spring screams louder, acegi will magically work nicely with a secure webservice written with RAD. peter
  108. Peter, you have not provided any specifics about the apparent issues between Spring Security (formerly Acegi Security), Spring Web Services, RAD and WebSphere. If you were able to provide specifics, we'd be able to help you and others in the Spring community. We work extremely hard to ensure our products interoperate correctly, and I could find no evidence in our JIRA issue tracker (http://jira.springframework.org/secure/BrowseProject.jspa?id=10040) of unresolved interoperability problems. If the person you refer to was indeed "suffering horribly", would you be so kind as to point me at the JIRA issue they logged which reported the bug? Or at least the forum post where they asked for assistance, so that we can take a look and help them work through their problems? Or, if they're one of our support customers, the SpringSource support reference number? Certainly I can assure you that countless people successfully integrate these products. Indeed, if you stop by the Spring Forum, you can easily see evidence of this. I am even giving a technical session next week at JavaOne that includes a demonstration of Spring Security and Spring Web Services interoperability (http://tinyurl.com/4bspgs). Again, if you would be good enough to provide an existing JIRA issue number, forum posting link, or SpringSource case number, I would be happy to take a look into your concerns. Otherwise I can only reiterate that people do use these products successfully together (they can see me demonstrate this live next week) and that assertions to the contrary without supporting evidence do not further constructive dialogue. Best regards Ben Alex Principal Software Engineer, SpringSource Lead, Spring Security
  109. Peter, you have not provided any specifics about the apparent issues between Spring Security (formerly Acegi Security), Spring Web Services, RAD and WebSphere.

    If you were able to provide specifics, we'd be able to help you and others in the Spring community. We work extremely hard to ensure our products interoperate correctly, and I could find no evidence in our JIRA issue tracker (http://jira.springframework.org/secure/BrowseProject.jspa?id=10040) of unresolved interoperability problems.

    If the person you refer to was indeed "suffering horribly", would you be so kind as to point me at the JIRA issue they logged which reported the bug? Or at least the forum post where they asked for assistance, so that we can take a look and help them work through their problems? Or, if they're one of our support customers, the SpringSource support reference number?

    Certainly I can assure you that countless people successfully integrate these products. Indeed, if you stop by the Spring Forum, you can easily see evidence of this. I am even giving a technical session next week at JavaOne that includes a demonstration of Spring Security and Spring Web Services interoperability (http://tinyurl.com/4bspgs).

    Again, if you would be good enough to provide an existing JIRA issue number, forum posting link, or SpringSource case number, I would be happy to take a look into your concerns. Otherwise I can only reiterate that people do use these products successfully together (they can see me demonstrate this live next week) and that assertions to the contrary without supporting evidence do not further constructive dialogue.

    Best regards

    Ben Alex
    Principal Software Engineer, SpringSource
    Lead, Spring Security
    luckily for me, I'm not the one that has to write the Spring WS to communicate with the WS written in RAD. I helped write a Webservice in RAD deployed on Websphere. It's a business partner that is struggling with Spring, so I have no details to report other than they are suffering. for the record, I do think spring is useful, but all this hype is really annoying to me. Since people are screaming "spring rocks" I feel someone should point out it's not all peachy. I've been using spring on a fairly complex project for the last 18 months. There are times I am happy using spring and there are times I dislike it. I think if you guys tone down the hype, it would be better, but that's just my bias opinion. peter
  110. Frankly, the statement about Acegi makes me laugh. I know someone that is suffering horribly trying to get Spring Webservices + Acegi working against a secure Webservice written in RAD deployed on Websphere. In fact, acegi works so well they decided to look else where, since it just wasn't working nicely with the webservice on Websphere.

    maybe if Spring screams louder, acegi will magically work nicely with a secure webservice written with RAD.

    peter
    Ok, who is masquerading as Peter?
  111. Frankly, the statement about Acegi makes me laugh. I know someone that is suffering horribly trying to get Spring Webservices + Acegi working against a secure Webservice written in RAD deployed on Websphere. In fact, acegi works so well they decided to look else where, since it just wasn't working nicely with the webservice on Websphere.

    maybe if Spring screams louder, acegi will magically work nicely with a secure webservice written with RAD.

    peter

    Ok, who is masquerading as Peter?
    I'm just having fun playing devil's advocate. I'm hoping the hype will turn into a flame fest and explodes into a huge soap opera. All this drama over spring is silly. peter
  112. idea...

    Rgds
    Rod


    Frankly, the statement about Acegi makes me laugh. I know someone that is suffering horribly trying to get Spring Webservices + Acegi working against a secure Webservice written in RAD deployed on Websphere. In fact, acegi works so well they decided to look else where, since it just wasn't working nicely with the webservice on Websphere.

    maybe if Spring screams louder, acegi will magically work nicely with a secure webservice written with RAD.

    peter Maybe its him. A developer friend Wednesday was singing praises about Acegi. Just because your friend cannot get it to work, doesn't mean its bad.
  113. But it's a waste of time to learn these alternative frameworks, as long as these frameworks are not maintained by financially healthy companies.
    I dont agree. If you are talking about infrastructure thats one thing. Thats a huge investment for both the vendor and the customer. But frameworks are lighter weight abstractions of underlying infrastructure. I think history has proven to be true that frameworks are an area where the industry can be more agile and have more competition and smaller players can innovate.
  114. Other frameworks such as Wicket for example: Nice and innovative approach. But it's a waste of time to learn these alternative frameworks, as long as these frameworks are not maintained by financially healthy companies.
    No, these frameworks thrive on the passion of the community that supports them. Companies and organizations may come and go but a framework that has happy users will keep going no matter what. You're under the severely mistaken impression that something being under a corporate umbrella provides safety -- it doesn't.
  115. Sustainable open source[ Go to top ]

    Companies and organizations may come and go but a framework that has happy users will keep going no matter what. You're under the severely mistaken impression that something being under a corporate umbrella provides safety -- it doesn't.
    Good technology, a strong community and a corporate umbrella all play a role in sustaining open source. The first is essential; the second and/or third also important. With Spring, we believe we have all three.
  116. Good technology, a strong community and a corporate umbrella all play a role in sustaining open source. The first is essential; the second and/or third also important. With Spring, we believe we have all three.
    I disagree. First good technology doesn't make good open source - Community does. Without community, you can have all the tech you want, but it won't get anywhere. And for open source, business support is not *that* important. I understand that as the lead for SpringSource you want to make the rest of the world buy into that. However I would've thought that with the vast amount of Apache folks within SpringSource, you would see the correct value of community. Without the Spring Community, SpringSource would not exist or lead a marginal existence.
  117. Re: Sustainable open source[ Go to top ]

    Companies and organizations may come and go but a framework that has happy users will keep going no matter what. You're under the severely mistaken impression that something being under a corporate umbrella provides safety -- it doesn't.

    Good technology, a strong community and a corporate umbrella all play a role in sustaining open source. The first is essential; the second and/or third also important. With Spring, we believe we have all three.
    The corporate umbrella isn't important at all. Like I argued elsewhere, it might actually hurt the project. Scale isn't always beneficial either, certainly not if you look at the total market, as scale and financial backing often leads to competition through marketing instead of plain technology. Though exceptions (frameworks of Google and Yahoo for instance) exist. There are thousands of successful projects out there without corporate backing. It would in fact be interesting to determine what successful is to start with, because in my world anything that helps my project is successful enough. I couldn't care less whether a framework or server is a market leader or not, and I actually think it helped my in the past going for choices that weren't. Surely you understand how that works being the originator of the Spring Framework, which after all started without any serious backing and went against the technology that was supposedly prevalent back then.
  118. Just for clarification: I'm not arguing that corporate backing is always bad/ is a bad idea for Spring(Source). Backing/ money surely has some advantages. I'm just fighting the idea that open source projects without such backing are destined to fail, or can't live up to their potential.
  119. Other frameworks such as Wicket for example: Nice and innovative approach. But it's a waste of time to learn these alternative frameworks, as long as these frameworks are not maintained by financially healthy companies.
    Open source projects do not require any financial backing. The notion that you should only use projects backed up by companies is pretty ridiculous. It's the kind of argument I'd expect from a paper shoving architect, not a developer. Do you think money automatically provides a culture of innovation and community participation (which is typically very good for bug fixing)? I'd argue to opposite (you are championing Microsoft for what exactly?). Actually, my *hunch* is that financial backing might actually hurt projects because they will have more to lose from getting behind on competition and they now have the means to use marketing muscle (which is typically easier/ more effective to use, especially when there is more money to spend) instead of just the project, and they will have more pressure to convert to financial backing into financial gains, thus preferring consultancy over things like maintaining the free mailing list and bug fixing that is not paid for; Also, hiring core developers to work on their project full time might even mean that they won't eat their own dog food anymore (and the kind of consultancy they'll do will be either fixing the difficult cases or training), which can hurt the quality of the project as well. But there is absolutely no reason to reject open source products coming from SpringSource based on whether the company has enough financial backing (or whether it is pushing proprietary standards for that matter). Just look at the quality and maturity of the project. and the community that evolves around it.
  120. Open source projects do not require any financial backing. of course they do. Or should the developers work for free? Someone has to pay their salary. And once the projects become mature and boring, who should do the maintenance? The notion that you should only use projects backed up by companies is pretty ridiculous. It's the kind of argument I'd expect from a paper shoving architect, not a developer. Do you think money automatically provides a culture of innovation and community participation (which is typically very good for bug fixing)? I'd argue to opposite (you are championing Microsoft for what exactly?). unfortunately my background is in Java-based technologies :-( During the last 10 years, I have been a successful investor in financial markets however, so as far as the evaluation of companies and understanding of financial issues is concerned, I'm far more experienced than the typical teckie who normally doesn't care at all about things like that. Actually, my *hunch* is that financial backing might actually hurt projects because they will have more to lose from getting behind on competition and they now have the means to use marketing muscle (which is typically easier/ more effective to use, especially when there is more money to spend) instead of just the project, and they will have more pressure to convert to financial backing into financial gains, thus preferring consultancy over things like maintaining the free mailing list and bug fixing that is not paid for so you get mailing list support for free from SpringSource? Do they answer every mundane question? I think the latter is a wrong expectation. But there is absolutely no reason to reject open source products coming from SpringSource based on whether the company has enough financial backing (or whether it is pushing proprietary standards for that matter). Just look at the quality and maturity of the project. and the community that evolves around it. of course there is a reason to reject products if the vendor company has not enough or only shaky financial backing. In the case of SpringSource, speculations are no FUD, but absolutely legitimate. It is reasonable to assume that the company is not profitable, at best they operate at break even (and this would be a tremendous achievement by SpringSource btw!). Actually it's fair to assume that SpringSource is burning through the VC investment. And look what Fleury did, when Red Hat acquired JBoss. He immediately retired as millionaire. Leading Spring developers will do the same should someone be so crazy and acquire SpringSource.
  121. Open source projects do not require any financial backing.

    of course they do. Or should the developers work for free? Someone has to pay their salary. And once the projects become mature and boring, who should do the maintenance?
    I've been working in my spare time on open source for years now. As has the rest of the Wicket team. And many, many other people I know. Most of who - like me - use these projects for their day time jobs, so there's bound to be some time available to spend during the day as it is often in the interest of the company as well, but yeah, many people work for free just because they believe in what their doing (and hopefully they'll have a bit of fun doing it).
    unfortunately my background is in Java-based technologies :-(

    During the last 10 years, I have been a successful investor in financial markets however, so as far as the evaluation of companies and understanding of financial issues is concerned, I'm far more experienced than the typical teckie who normally doesn't care at all about things like that.
    As a typical techie I don't care about who is the market leader blah and what the financial prospects of open source projects are blah. I care about the quality of the product and the community (which is a good indicator for many things, amongst others how long the project will be alive).
    so you get mailing list support for free from SpringSource? Do they answer every mundane question? I think the latter is a wrong expectation.
    I obviously can't speak for every project out there, but good open source projects will have good - and typically free - support through things like mailing lists. You can buy support if you feel it is important to have that support guaranteed. Whether you need that depends largely on your team and how urgent you expect your problems to be. You have the source after all.
    of course there is a reason to reject products if the vendor company has not enough or only shaky financial backing.

    In the case of SpringSource, speculations are no FUD, but absolutely legitimate. It is reasonable to assume that the company is not profitable, at best they operate at break even (and this would be a tremendous achievement by SpringSource btw!). Actually it's fair to assume that SpringSource is burning through the VC investment.

    And look what Fleury did, when Red Hat acquired JBoss. He immediately retired as millionaire. Leading Spring developers will do the same should someone be so crazy and acquire SpringSource.
    Even if the whole Spring team retires, there will be plenty of people around who know the framework so well by now that they could take over. Hell, give me a few months and I'll do it if I'd have to :-) I wonder why you think that SpringSource is not profitable. I have honestly no idea, but their business looks like a pretty good one to be in if you ask me. As Spring is so broad, they can pretty much take up any consultancy gig out there, and with those tens of thousands of users, I would expect there to be plenty of demand. But, it doesn't matter. Even if half of the Spring team retires tomorrow, you can still at least use what they have in final releases. If you need a crazy amount of support on those, maybe the choice isn't right - for technical reasons.
  122. I wonder why you think that SpringSource is not profitable. I have honestly no idea, but their business looks like a pretty good one to be in if you ask me. As Spring is so broad, they can pretty much take up any consultancy gig out there, and with those tens of thousands of users, I would expect there to be plenty of demand.
    The software is given away for free. Customers can use it without Springsource earning a single penny of revenue. The Springsource developers are paid employees. Take developers such as Keith Donald (author Web Flow) for example. If his task is to work on the maintenance and enhancement of Web Flow, JSF integration etc., he cannot at the same time generate much revenue for SpringSource unless SpringSource either sells the software or sells support subscriptions. I'd expect that leading spring developers receive attractive salaries. So it's absulelty reasonable to assume that SpringSource is a loss-making company right now and burning through the VC investment.
  123. Hi, the problem is, selling a product does scale. Just think about how many people are needed to maintain the Spring portfolio. How many consultants/ trainers would one need to finance such a development? Talking about scaling - I just don't understand the price model. Spring has created very interesting extra software (like the IDE, like the platform). I would get it for me immediately - but I cannot afford the 20k (correct me if I am wrong, but that's the price). I understand that support is expensive if it going to be of good quality. So why don't split it up? take .1k/y/developer for the software. It is the same model as with myeclipseide. Spring has a huge community, I believe that we all would pay for the addons/ goodies. Support can be purchased extra. So really many people would use the tools, understand the value gain, and those who can afford would go for the support subscriptions. Just my 2 cents
  124. I wonder why you think that SpringSource is not profitable. I have honestly no idea, but their business looks like a pretty good one to be in if you ask me. As Spring is so broad, they can pretty much take up any consultancy gig out there, and with those tens of thousands of users, I would expect there to be plenty of demand.


    The software is given away for free. Customers can use it without Springsource earning a single penny of revenue.

    The Springsource developers are paid employees. Take developers such as Keith Donald (author Web Flow) for example. If his task is to work on the maintenance and enhancement of Web Flow, JSF integration etc., he cannot at the same time generate much revenue for SpringSource unless SpringSource either sells the software or sells support subscriptions. I'd expect that leading spring developers receive attractive salaries.

    So it's absulelty reasonable to assume that SpringSource is a loss-making company right now and burning through the VC investment.
    So if you have people on staff positions you're bound to fail? And people working on open source projects can't do consultancy part of the time? Open source companies have been surviving and making money in the past, and in the case of SpringSource we just don't know how their financials look, so this discussion is going nowhere.
  125. financial backing might actually hurt projects because they will have more to lose from getting behind on competition and they now have the means to use marketing muscle (which is typically easier/ more effective to use, especially when there is more money to spend) instead of just the project, and they will have more pressure to convert to financial backing into financial gains, thus preferring consultancy over things like maintaining the free mailing list and bug fixing that is not paid for
    so if SpringSource is not facing any pressure to convert to financial backing into financial gains, is it a not-for-profit organization?
  126. financial backing might actually hurt projects because they will have more to lose from getting behind on competition and they now have the means to use marketing muscle (which is typically easier/ more effective to use, especially when there is more money to spend) instead of just the project, and they will have more pressure to convert to financial backing into financial gains, thus preferring consultancy over things like maintaining the free mailing list and bug fixing that is not paid for


    so if SpringSource is not facing any pressure to convert to financial backing into financial gains, is it a not-for-profit organization?
    My point was that they probably have that pressure, and that I can think of as many reasons why that might hurt the project as I can think of benefits of such pressure.
  127. Re: Why GPLV3 ?[ Go to top ]

    Oh, and don't forget that OSGi is a standard.
    I would argue that it is not a Java standard as it breaks the class loader contract in all runtimes hence the number of hacks labeled as innovation to workaround the class and resource visibility restrictions which break a large number of enterprise frameworks and tools based on byte code instrumentation. I have yet to see an enterprise application deployed to a OSGi container/platform that does not have issues. The solution which is clearly documented is for the bundles to declare their dependency on such injected instrumentation which effectively means that what OSGi gives in one hand takes back in another. Alternatively one just injects code in the OSGi runtime that ensures it obeys the contract to some degree. I am surprised that no one has mentioned the portability issues in terms of existing development, testing and performance management tooling that today works with the standard Java EE interfaces across many different implementations. But maybe it is easy to make statements about rocking your world whilst oblivious to IT management concerns. We should welcome this move by SpringSource in that finally there is a much clearer demarcation between the Java EE world and the Spring(Source) world. Customers will have an option to completely migrate to a single vendor single platform solution. In the end we will see whether customers value standards with much greater risk management over immediate value offerings. William
  128. Re: Why GPLV3 ?[ Go to top ]

    I would argue that it [OSGi] is not a Java standard as it breaks the class loader contract in all runtimes
    Then you have a very peculiar definition of a Java standard. Two fully approved JSRs (232 and 291) disagree with you, not to mention a 30+ member, cross-industry standards body. Problems with legacy technology do not make something non-standard. J2EE servers were never very good at running CORBA objects; that does not make either J2EE or CORBA invalid as standards.
  129. We should welcome this move by SpringSource in that finally there is a much clearer demarcation between the Java EE world and the Spring(Source) world. Customers will have an option to completely migrate to a single vendor single platform solution. In the end we will see whether customers value standards with much greater risk management over immediate value offerings.
    To the point! The competition is not only Spring vs. Standards and Spring vs. EE but also Spring vs. Apache: Company driven "open" source vs. Community driven Open Source.
  130. To the point! The competition is not only Spring vs. Standards and Spring vs. EE but also Spring vs. Apache: Company driven "open" source vs. Community driven Open Source.
    I fail to see how this is the case at all. How is it "Spring vs. Apache" when SpringSource obviously values Apache and the various Apache projects, such as Tomcat and HTTPD. You are creating a conflict when none exists. If anything it is "company driven 'open' source" complimenting "community driven Open Source". Isn't that a good thing for the open source community?
  131. How is it "Spring vs. Apache" when SpringSource obviously values Apache and the various Apache projects, such as Tomcat and HTTPD.
    Of course they do - as long as the "the various Apache projects" are compatible with the SpringSource business plan.
    You are creating a conflict when none exists. If anything it is "company driven 'open' source" complimenting "community driven Open Source". Isn't that a good thing for the open source community?
    The conflict naturally arises when two parties engage in the same field.
  132. Re: Why GPLV3 ?[ Go to top ]

    The solution which is clearly documented is for the bundles to declare their dependency on such injected instrumentation which effectively means that what OSGi gives in one hand takes back in another. Alternatively one just injects code in the OSGi runtime that ensures it obeys the contract to some degree.
    Actually, the solution for bytecode instrumentation is much, much simpler - you have no need to change any modules at all. We profile the Platform with YourKit and it works just fine by adding it to boot delegation. This works perfectly for launching profiling sessions from Eclipse.
    I am surprised that no one has mentioned the portability issues in terms of existing development, testing and performance management tooling that today works with the standard Java EE interfaces across many different implementations. But maybe it is easy to make statements about rocking your world whilst oblivious to IT management concerns.
    Do you have any examples of these portability issues. I'm genuinely interested to know if there is anything in particular you are facing that is problematic. Rob
  133. ClassLoaders[ Go to top ]

    Hi Rob, I assume you do know that a Java 5 standard javaagent used mainly to install a class file transformations is not loaded by the boot class loader which I think is what this osgi property relates to. So one needs to add a -Xbootclasspath: argument (specifying one or more javaagent libraries) to the command line which seems to defeat the whole point of the javaagent parameter accepting a jar file specification. Also I believe this property does not help one access resources (other than classes) added to the class path or even bootclasspath for that matter. I know at least two OSGi implementations that hide classes and resources (i.e. META-INF/aop.xml) required by a *** standard *** javaagent library. I would be more than willing to talk about them next week in person during JavaOne. If Sun introduced such a proposed standard breaking a large number of applications and blatantly ignoring existing runtime standards and contracts there would be major up-roar. In the OSGi camp this incompatibility is called innovation or a best practice. William
  134. Re: ClassLoaders[ Go to top ]

    I assume you do know that a Java 5 standard javaagent used mainly to install a class file transformations is not loaded by the boot class loader which I think is what this osgi property relates to.
    You assume correctly...
    So one needs to add a -Xbootclasspath: argument (specifying one or more javaagent libraries) to the command line which seems to defeat the whole point of the javaagent parameter accepting a jar file specification.
    This doesn't seem like a big problem to me. Also, Equinox allows for you to set the AppClassLoader to be used during boot delegation so no changes are need to your startup command.
    Also I believe this property does not help one access resources (other than classes) added to the class path or even bootclasspath for that matter.
    That's actually not true - boot delegation will find classpath resources as well.
    I know at least two OSGi implementations that hide classes and resources (i.e. META-INF/aop.xml) required by a *** standard *** javaagent library.
    The issue with META-INF resources is that you cannot define a package name of META-INF so package-base import/export falls down for this. The Platform fixes this problem to allow resources to be found in META-INF - its how we make AJ LTW work.
    I would be more than willing to talk about them next week in person during JavaOne.
    I'll be happy to do that.
    If Sun introduced such a proposed standard breaking a large number of applications and blatantly ignoring existing runtime standards and contracts there would be major up-roar.
    You'd think wouldn't you, except that OSGi existed before Java 5, so any breakage of the model is caused by Sun and Java 5 and not OSGi. OSGi was one of the very first JSRs and is now approved as JSR-291... Regards, Rob
  135. Re: ClassLoaders[ Go to top ]

    You'd think wouldn't you, except that OSGi existed before Java 5, so any breakage of the model is caused by Sun and Java 5 and not OSGi. OSGi was one of the very first JSRs and is now approved as JSR-291...
    OSGi was an externally managed specification and never part of the core Java runtime libraries or specifications. Admittedly it was ratified by a number of JCP members but rejected by Sun and others. I am sure you are aware of the comments but maybe others are not. http://jcp.org/en/jsr/results?id=3657 I do not want to turn this into a OSGi debate as that is a never ending story but I think it is important to point out that OSGi comes with issues which you yourselves have had to work around and others will have to do likewise because in the real world not every library belonging to an application gets packaged in a war archive or bundle. By the way is the inability to load resource files in packages (directories) not following the OSGi standard package naming a breach of the Java ClassLoader contract which today supports that? I am glad to see you focused on serviceability but I think this was always going to be the case to get things to work again in this new (and maybe better) managed environment. Kind regards, William
  136. Re: ClassLoaders[ Go to top ]

    I do not want to turn this into a OSGi debate as that is a never ending story but I think it is important to point out that OSGi comes with issues which you yourselves have had to work around and others will have to do likewise because in the real world not every library belonging to an application gets packaged in a war archive or bundle.
    I think we can safely agree OSGi isn't a panacea. Complex libraries that were not designed with modularity in mind do run into issues. The Platform addresses many issues in using popular libraries so that users don't have to. Also the SpringSource Enterprise Bundle Repository contains over 300 such libraries packaged as standard OSGi bundles and carefully checked so that OSGi users, including users of the Platform, can reuse those bundles with less trouble.
    By the way is the inability to load resource files in packages (directories) not following the OSGi standard package naming a breach of the Java ClassLoader contract which today supports that?
    OSGi uses standard Java package naming. The ClassLoader API specification leaves implementations free to decide which resources they find. Glyn Normington SpringSource
  137. We loaded the velocity template by using dataSourceResourceLoader object but not able to set the the loaded template in ModelAndView object to render the Model with view. thanks in Advance. Regard, Ranjeet
  138. Re: Single-vendor[ Go to top ]

    Customers will have an option to completely migrate to a single vendor single platform solution. In the end we will see whether customers value standards with much greater risk management over immediate value offerings.

    William
    Actually, customers have had this option for some time; it's called Microsoft .NET . And of course, Microsoft has had a reasonably successful adoption of that platform. If you meant a single vendor single platform solution based on Java, point made. Randy (P.S. Yes, I'm aware of Mono as an alternate impl of .NET...but few would argue it's a truly viable alternate impl.)
  139. Re: Why GPLV3 ?[ Go to top ]

    I am working to implement a project to do just that.
    Reza, We're happy to see people building on our Platform. If there is any support we can give you, don't hesitate to ping me: rob.harrop ( at ) springsource.com Regards, Rob
  140. Re: Why GPLV3 ?[ Go to top ]

    We're happy to see people building on our Platform. If there is any support we can give you, don't hesitate to ping me: rob.harrop ( at ) springsource.com
    Rob: Thanks, much appreciated and I will take you guys up on it very soon. A key indicator of a truly open, mature platform is to be open to collaboration with folks you might not neccesarily completely agree with. I'm happy to say the JCP/Java EE is getting better at that, despite my fears and doubts going into the EG committees. I'm spending a little more time that I expected on the requirements/architecture for the bridging project as to avoid typical mistakes a lot of open soure projects make. Reza
  141. Re: Why GPLV3 ?[ Go to top ]

    Because SpringSource wants to make dual-licensing money, a la MySQL. There's nothing wrong with GPL + dual licensing! MySQL does it. I know MarcF always wished JBoss had done GPL and retained copyright on all contributions. Its just too bad that Rod and even Adrian(I thought you were better than that!) are trying to spin it a different way. Just be blunt and honest guys. You have nothing to fear/hide. Rod, just hope that Apache doesn't decide that you are blasphemous and create a ASL fork of your app server ;-) -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com
  142. Interesting product release and certainly a bold move by SpringSource. I wouldn't be surprised if this is pretty cool technology, but the issue of vendor lockin is very real and shouldn't be minimized. At the enterprise level, deciding on an appserver platform is an expesnive decision and there are very real advantages to choose a 100% standards-based system at the infanstructure level. That is not to say that the vendor lockin issue would be enough of a reason by itself not to choose it at an enterprise level, but it certainly should be a factor in the decision making and should be balanced with any pain-removing technological innovation it brings. I saw some very awful Forte and SilverStream migrations.
  143. ... but the issue of vendor lockin is very real and shouldn't be minimized...
    Berry, The SpringSource Application Platform uses a standard OSGi, Spring and Spring DM programming model. Java code is just POJOs, configuration is standard Spring and modules are defined in standard OSGi. Your application shouldn't have any hard dependency on the Platform at all. Where the value of the Platform comes in is making all the typical libraries you use, work in the standard OSGi environment, but this has no effect on your application code. Rob
  144. ... but the issue of vendor lockin is very real and shouldn't be minimized...


    Berry,

    The SpringSource Application Platform uses a standard OSGi, Spring and Spring DM programming model. Java code is just POJOs, configuration is standard Spring and modules are defined in standard OSGi.

    Your application shouldn't have any hard dependency on the Platform at all. Where the value of the Platform comes in is making all the typical libraries you use, work in the standard OSGi environment, but this has no effect on your application code.

    Rob
    Well for one it has a non-standards based deployment configuration that it recommends developers use, so I think that is certainly a dependancy. But the bigger issue is that if there is no value added technology that creates dependancy from a coding standpoint that isnt provided by a "pure" OSGi server and Servlet container with Spring in the classpath, then what is the value proposition of this app server? This isnt a rhetotical question, Ive only given these articles a quick glance. Deployment compexity can be a pain in the ass, but its never come close to being the biggest headache Ive had in a big project. Im not trying to be negative or trying to flamebait, Im just trying to understand the issues.
  145. Well for one it has a non-standards based deployment configuration that it recommends developers use, so I think that is certainly a dependancy.
    The only non-standard piece of the deployment is the PAR file which is just a JAR file wrapping your standard OSGi bundles along with a three-line manifest. If you don't want to use this, you can deploy all the bundles individually.
    But the bigger issue is that if there is no value added technology that creates dependancy from a coding standpoint that isnt provided by a "pure" OSGi server and Servlet container with Spring in the classpath, then what is the value proposition of this app server? This isnt a rhetotical question, Ive only given these articles a quick glance. Deployment compexity can be a pain in the ass, but its never come close to being the biggest headache Ive had in a big project.
    This is a great question. We've had the chance over the last 18 months to watch people build OSGi applications with Spring DM. We've seen what works and what is good, but we've also seen the warts. What we wanted to do with the Platform was stick as closely to the OSGi standard as possible, and there we have done a great job, whilst getting rid of the warts. So, you can definitely take an application built for the Platform and deploy it on standalone Equinox, you're just going to need to do a lot more work. For example, a web application using JSP and EclipseLink is going to need Tomcat bundled and installed, support for JSP and TLDs which means hacking with Equinox to get it to give Jasper the URLs it needs, support for load-time weaving, which means wrapping the class loaders. All this becomes even more complex when you want to start putting multiple applications on the same runtime and you have to worry about how they might collide with each other. Another aspect of this is diagnostics. The Platform aims to give first class diagnostics. This ranges from simple things like extended message text in ClassNotFoundException and NoClassDefError showing the bundle where the error occurred, to full diagnosis of resolution failures with suggested fixes. The best way to appreciate this value is to try building a web app on raw OSGi and then on the Platform - please try it out and give me any feedback you have.
    Im not trying to be negative or trying to flamebait, Im just trying to understand the issues.
    Understood, I just hope my answers are helping :) Regards, Rob
  146. So, you can definitely take an application built for the Platform and deploy it on standalone Equinox, you're just going to need to do a lot more work. For example, a web application using JSP and EclipseLink is going to need Tomcat bundled and installed, support for JSP and TLDs which means hacking with Equinox to get it to give Jasper the URLs it needs, support for load-time weaving, which means wrapping the class loaders. All this becomes even more complex when you want to start putting multiple applications on the same runtime and you have to worry about how they might collide with each other.
    Semantics aside, if my code depends on a context to work correctly, there is unequivocally a dependacy there regardless if its via an API or DI. To offer an analogy: in theory servlets dont have a depandancy on a servlet container because I could always implement the Servlet API myself, but in practice the dependency is there. DI-based dependcies are arguably superior types of dependancies but they are dependancies none-the-less. So Id say my orginal thesis still stands. Since the dependancies inherent in this product are non-standards based, there is clearly some vendor-lock in issues having worked with more than a few CIOs I can promise that they give this issue alot weight. Anyway, thank you for your response and good luck with the success of your product. Spring has done alot to make developer's lives easier in key areas (even for those not using spring) and hopefully this continues the trend.
  147. So, you can definitely take an application built for the Platform and deploy it on standalone Equinox, you're just going to need to do a lot more work. For example, a web application using JSP and EclipseLink is going to need Tomcat bundled and installed, support for JSP and TLDs which means hacking with Equinox to get it to give Jasper the URLs it needs, support for load-time weaving, which means wrapping the class loaders. All this becomes even more complex when you want to start putting multiple applications on the same runtime and you have to worry about how they might collide with each other.


    Semantics aside, if my code depends on a context to work correctly, there is unequivocally a dependacy there regardless if its via an API or DI. To offer an analogy: in theory servlets dont have a depandancy on a servlet container because I could always implement the Servlet API myself, but in practice the dependency is there. DI-based dependcies are arguably superior types of dependancies but they are dependancies none-the-less.

    So Id say my orginal thesis still stands. Since the dependancies inherent in this product are non-standards based, there is clearly some vendor-lock in issues having worked with more than a few CIOs I can promise that they give this issue alot weight.

    Anyway, thank you for your response and good luck with the success of your product. Spring has done alot to make developer's lives easier in key areas (even for those not using spring) and hopefully this continues the trend.
    Berry, You make valid point, but I do believe that there is still a path if you wanted to move to a standalone OSGi runtime. Unfortunately, at the moment, it is harder to build raw OSGi applications than it needs to be. We are working through OSGi expert groups to build solutions to these problems in standard OSGi. For example, we are leading RFC 124 to standardise the ideas behind Spring Dynamic Modules. We purposefully kept our modifications and enhancements under the hood so that user applications are written using standard semantics. Rob
  148. We purposefully kept our modifications and enhancements under the hood so that user applications are written using standard semantics.

    Rob
    Hi Rob, I assume by standard semantics you mean you dont have to call any new types of APIs. I would say that is not the only or maybe even the most important measure if wether using a particular solution involves vendor lockin. Based on your prior response to me it seems cleat that if I wrote my code with the understanding that it would run in your app server and then decided to not use the app server but still wanted my code to run, Id have to: - Install Equinox - Get Tomcat bundled and installed, - Rebundle the deployment in a new resource archive configuration - Add support for JSP and TLDs which means hacking with Equinox to get it to give Jasper the URLs it needs - Develop support for load-time weaving, which means wrapping the class loaders. - Deal with even more complexity when I want to start putting multiple applications on the same runtime and worry about how they might collide with each other. And Im sure that is not a complete list if I make use of all the DI services are available. Again Im not arguing against the quality of the product, Im sure its an elegant solution to real problems, but the honest answer is the a solutions developer would for all practical purposes be locked into your product if they want their code to run (as I understand it from your answers to me). By contrast if I have a WAR based app I have many options for deployment with little or no configuration or deployment change.
  149. We purposefully kept our modifications and enhancements under the hood so that user applications are written using standard semantics.

    Rob


    Hi Rob,

    I assume by standard semantics you mean you dont have to call any new types of APIs. I would say that is not the only or maybe even the most important measure if wether using a particular solution involves vendor lockin.

    Based on your prior response to me it seems cleat that if I wrote my code with the understanding that it would run in your app server and then decided to not use the app server but still wanted my code to run, Id have to:

    - Install Equinox
    - Get Tomcat bundled and installed,
    - Rebundle the deployment in a new resource archive configuration
    - Add support for JSP and TLDs which means hacking with Equinox to get it to give Jasper the URLs it needs
    - Develop support for load-time weaving, which means wrapping the class loaders.
    - Deal with even more complexity when I want to start putting multiple applications on the same runtime and worry about how they might collide with each other.

    And Im sure that is not a complete list if I make use of all the DI services are available.

    Again Im not arguing against the quality of the product, Im sure its an elegant solution to real problems, but the honest answer is the a solutions developer would for all practical purposes be locked into your product if they want their code to run (as I understand it from your answers to me).

    By contrast if I have a WAR based app I have many options for deployment with little or no configuration or deployment change.
    Berry, Your reasoning isn't flawed, but I'll raise some additional points. Firstly, OSGi is definitely a step forward for developers, and we make OSGi a reality for enterprise developers today. That's something I'm proud of, and I think a lot of developers will see value in that. Secondly, if developers are afraid of lock-in and wish to stick to WAR files, then we support WAR files on our Platform as well, and there are definite benefits over and above a plain Tomcat/Spring pairing. Thirdly, we are working with the OSGi expert groups and we hope that we can push a lot of what we have done back into standards. Lastly, we don't feel the need to lock developers into our Platform. We believe it can standalone as a server platform. As part of this we are committed to supporting WAR files and we are committed to supporting profiles A and B of the upcoming Java EE 6 spec. Regards, Rob
  150. How do you even distribute Apache license code among with GPL code? Doesn't GPL imply that whole distribution must be licensed under GPL?
  151. How do you even distribute Apache license code among with GPL code? Doesn't GPL imply that whole distribution must be licensed under GPL?
    This one reason we chose GPL 3. GPL 3 is compatible with the Apache License. Of course, we took legal advice about our licensing strategy...
  152. How do you even distribute Apache license code among with GPL code? Doesn't GPL imply that whole distribution must be licensed under GPL?
    This one reason we chose GPL 3. GPL 3 is compatible with the Apache License. Of course, we took legal advice about our licensing strategy...
    OK, found this (http://www.gnu.org/licenses/quick-guide-gplv3.html), nice to know. Good luck to you, guys!
  153. GPLv3 compatibility[ Go to top ]

    This one reason we chose GPL 3. GPL 3 is compatible with the Apache License. Of course, we took legal advice about our licensing strategy...
    But EPL, as used by Equinox which you also bundle in S2AP, is not compatible with GPLv3. Could you tell us what your legal counsel advised with regard to this apparent problem?
  154. Apache license question[ Go to top ]

    How do you even distribute Apache license code among with GPL code? Doesn't GPL imply that whole distribution must be licensed under GPL?
    You can relicense any Apache code as GPL (but not vice versa). Peace, Cameron Purdy Oracle Coherence: Data Grid for Java, C# and C++
  155. Re: Apache license question[ Go to top ]

    You can relicense any Apache code as GPL (but not vice versa).
    Well, Apache is a business friendly license ...
  156. What about spring.jar?[ Go to top ]

    Interesting news and good luck with GPL-based application server. I have few practical questions: - will Spring Framework continue its independant development or is it now going to be done under S2AS ambrella only? - I assume that Spring Framework will retain its Apache 2.0 license, right? Thanks, Nikita Ivanov. GridGain - Grid Computing Made Simple
  157. Re: What about spring.jar?[ Go to top ]

    Nikita
    Will Spring Framework continue its independant development or is it now going to be done under S2AS umbrella only?
    Absolutely. Spring Framework is distinct from SpringSource Application Platform. It is designed to provide value to users whatever platform they may deploy on. The SpringSource Application Platform builds on Spring Portfolio and other technologies to deliver a complete, integrated solution.
    I assume that Spring Framework will retain its Apache 2.0 license, right?
    We have no plans to change the licensing of existing code. Rgds Rod
  158. Re: What about spring.jar?[ Go to top ]

    I see my previous post is a bit ambiguous. Let me clarify: Spring Framework absolutely will continue its independent development, and it will continue to be portable across whatever platforms the Spring community wants to run it on.
  159. I assume that Spring Framework will retain its Apache 2.0 license, right?

    We have no plans to change the licensing of existing code.

    Rgds
    Rod
    Rod, I'm a little bit confused by your reply (the "existing code" part)... Please, make a clear statement. Will Spring Framework code BE DEVELOPED under the Apache 2.0 License, or do you plan to convert it to GPL for future version? That would be fair to make such a statement at this moment.
  160. The power this implies cannot be understated.
    Unless youre flaming SpringSource, i think you mean to say, "The power this implies cannot be overstated."
  161. The idea of a WAR deployer into OSGI is quite cool, as is the idea of an "application" allowing for the segregation of bundles. However for those who are freaked out about the idea of a GPL application server, a DIY job on this one really isn't that hard. Eclipse Equinox SDK (OSGI container) + Spring Dynamic Modules will get you most of the way there. Either way, get ready to start seeing your new favorite exception, "java.lang.ClassNotFoundException" every 15 seconds :-)
  162. And there are ASLv2 bundles out there that also let you deploy WAR files onto OSGi, for example from OPS4J: http://wiki.ops4j.org/confluence/x/OQJN although, as with traditional DIY some assembly is required ;)
  163. And there are ASLv2 bundles out there that also let you deploy WAR files onto OSGi, for example from OPS4J:

    http://wiki.ops4j.org/confluence/x/OQJN

    although, as with traditional DIY some assembly is required ;)
    PAX is fine. The issue here is resolving OSGi services from within a servlet; that's the killer feature here.
  164. Really? I think its nice that you can inject OSGI services into a servlet - but it was nothing you couldn't do before. With or without Spring. Furthermore, Spring's OSGI service resolution has a habit of being more pain than its worth.
  165. Really?

    I think its nice that you can inject OSGI services into a servlet - but it was nothing you couldn't do before. With or without Spring.

    Furthermore, Spring's OSGI service resolution has a habit of being more pain than its worth.
    Daniel, If you could ping me a mail or raise a JIRA with the issues you are facing, I'll take a look at it for you. Thanks in advance, Rob
  166. The issue here is resolving OSGi services from within a servlet; that's the killer feature here.
    Hi Josep, Can you detail, especially why this you consider it as a feature of S2AP? Pax Web Extender can deploy war files into OSGi (using Pax Web = Jetty 6 based Http Service implementation). And if you need access to osgi services or spring bean you can achieve that using plain osgi or by making use of spring dm for its easy to use More you could use Pax Web Extender with or without Spring / Spring DM, you can use it in any OSGi framework implementation and I suppose (did not test it yet) as part of S2AP. And is available for 4 moths now. Alin Dreghiciu www.ops4j.org
  167. Sorry, but I don't see why this was necessary as everything was already there. I mean - the Spring framework, the Dynamic Modules, Tomcat, ... I have to congratulate the people at SpringSource though, as I see more and more people taking everything that comes out of that shop as simply the best thing without every looking twice. Well... at the end of the day it's just Java so what the heck ;-)
  168. Re: So why was this necessary again?[ Go to top ]

    I have to congratulate the people at SpringSource though, as I see more and more people taking everything that comes out of that shop as simply the best thing without every looking twice.

    Well its down to marketing...or FUD ;)
  169. Timing Is Everything[ Go to top ]

    Craig Walls said he didn't expect this announcement until another few months, but given the fact that JavaOne is around the corner, the timing couldn't have been better. It's about time we get a platform which combines the concepts of profiles, extensibility and module versioning. Nice work!
  170. Why is every non-JEE alternative to building enterprise java applications considered harmful? Why do we even bother creating other JSR's? Wikipedia defines proprietary as "components that are unique to a specific manufacturer, and do not conform to preset standards.". If we don't accept proprietary code at some point, and I would argue if GPL'ed code that builds on standards really is proprietary, we will have no innovation at all. All usable JSR's come from proprietary codebases. This is good stuff, and even if it would fail, I have a really hard time to find how I would be locked in to this platform. Look at existing enterprise JEE applications. They all have to break out of the spec and use jpa-, security-, ws-, whatever-extensions to do something useful...
  171. As an end-user developer. why should I care about OSGI? I can understand it's attractiveness to server vendors, but I don't get what problems this solves for developers. Can anybody explain in clear terms how this benefits developers?
  172. As an end-user developer. why should I care about OSGI? I can understand it's attractiveness to server vendors, but I don't get what problems this solves for developers. Can anybody explain in clear terms how this benefits developers?
    Odd. You do know that Eclipse uses OSGI? So that is not just for server? OSGI allows you, as a self professed developer, to realize the dream of componentized application development. From the OSGI web site - "The OSGi Alliance has developed many standard component interfaces for common functions like HTTP servers, configuration, logging, security, user administration, XML and many more."
  173. As an end-user developer. why should I care about OSGI? I can understand it's attractiveness to server vendors, but I don't get what problems this solves for developers. Can anybody explain in clear terms how this benefits developers?
    Odd. You do know that Eclipse uses OSGI? So that is not just for server?

    OSGI allows you, as a self professed developer, to realize the dream of componentized application development. From the OSGI web site - "The OSGi Alliance has developed many standard component interfaces for common functions like HTTP servers, configuration, logging, security, user administration, XML and many more."
    Mark is exactly right. OSGi provides an ideal base for building modular applications. I'm sure we can all agree that modularizing applications is a good idea... Regards, Rob SpringSource
  174. "You do know that Eclipse uses OSGI" yes, I know it uses Equinox, an OSGI implementation, but I do not deal with it directly (unless perhaps if I am a plugin developer), which is the point I was trying to make. I see it more as infrastructure-building mortar. And if that is indeed the intended target effect of OSGI, that's perfectly OK.
  175. I see it more as infrastructure-building mortar
    It is not though. If you build applications/systems/solutions/ you should be looking at it.
  176. As an end-user developer. why should I care about OSGI? I can understand it's attractiveness to server vendors, but I don't get what problems this solves for developers. Can anybody explain in clear terms how this benefits developers?
    The following page from the Programmer's guide for the Platform should give you fairly good idea about OSGi's relevance to you as an application developer. http://static.springsource.com/projects/s2ap/1.0.0.beta/programmer-guide/html/ch04.html -Ramnivas SpringSource
  177. As an end-user developer. why should I care about OSGI? I can understand it's attractiveness to server vendors, but I don't get what problems this solves for developers. Can anybody explain in clear terms how this benefits developers?


    The following page from the Programmer's guide for the Platform should give you fairly good idea about OSGi's relevance to you as an application developer.

    http://static.springsource.com/projects/s2ap/1.0.0.beta/programmer-guide/html/ch04.html

    -Ramnivas
    SpringSource
    Even though I don't like the hype around Spring these days. I want to thank Ramnivas Laddad for contributing AOP to the programming world. Alot of the ideas were floating around. It was AspectJ in Action that distilled it into a great book and showed the potential. peter
  178. oops, didn't proof read and click post to quickly. What I meant to say is thanks for contributing to AOP with your book AspectJ in action. I didn't mean to say you invented AOP, since that was invented at Palo Alto Research Center. http://www.parc.com/research/projects/aspectj/default.html I didn't know about AOP until AspectJ in Action. thanks again for a great book. peter
  179. OSGI == SOA[ Go to top ]

    SOA, although hyped by IBM and other giants for many years, wasn't a success. Therefore marketing decided "we" need a new buzzword: OSGI
  180. Re: OSGI == SOA[ Go to top ]

    SOA, although hyped by IBM and other giants for many years, wasn't a success. Therefore marketing decided "we" need a new buzzword: OSGI
    This comment seems to make zero sense to me. 1.) SOA has been a success for companies which have adopted SOA properly. In fact, I just finished a contract for a cheminformatics company which has a product that is sold as a suite of web services. The reason for this is that some pharmaceutical and life science companies have adopted a service oriented architecture and want to purchase products that expose services for the rest of their organization to benefit from. 2.) OSGI is a dynamic microkernel architecture which is not language agnostic (Not yet, at least. Also note that this is likely an oversimplified definition of OSGI, however my response is not intended to be technically rigorous). 3.) It is not the job of marketing to identify solutions to push because the previous one failed -- their job is to help a business identify markets (as if the name doesn't say it all?). 4.) SOA is a strategy pushed by more than one business, so I just don't see how, if SOA was in fact a failure, that marketing across several major corporations, including Microsoft, would create a new middleware buzzword in direct response to this supposed failure? Tom
  181. Re: OSGI == SOA[ Go to top ]

    1.) SOA has been a success for companies which have adopted SOA properly.
    Considering the hype and the high expectations since 2000 the adoption of SOA has been modest at best.
    2.) OSGI is a dynamic microkernel architecture which is not language agnostic (Not yet, at least. Also note that this is likely an oversimplified definition of OSGI, however my response is not intended to be technically rigorous).
    People just don't want those heavyweight, expensive (technically and financially) technologies, no matter how they are currently marketed.
  182. Re: OSGI == SOA[ Go to top ]


    2.) OSGI is a dynamic microkernel architecture which is not language agnostic (Not yet, at least. Also note that this is likely an oversimplified definition of OSGI, however my response is not intended to be technically rigorous).

    People just don't want those heavyweight, expensive (technically and financially) technologies, no matter how they are currently marketed.
    Hmm, the Concierge R3 OSGi framework is ~80kB and BSD licensed. To define a bundle you only need a couple of manifest entries. For me at least this doesn't sound heavyweight or expensive...
  183. Re: OSGI == SOA[ Go to top ]


    2.) OSGI is a dynamic microkernel architecture which is not language agnostic (Not yet, at least. Also note that this is likely an oversimplified definition of OSGI, however my response is not intended to be technically rigorous).

    People just don't want those heavyweight, expensive (technically and financially) technologies, no matter how they are currently marketed.

    Hmm, the Concierge R3 OSGi framework is ~80kB and BSD licensed. To define a bundle you only need a couple of manifest entries.

    For me at least this doesn't sound heavyweight or expensive...
    I have to agree. I fail to see how OSGi could be deemed to be either heavyweight or expensive. After all, this a spec that is designed to run in restricted environments such as J2ME and has numerous free implementations. Rob
  184. Re: OSGI == SOA[ Go to top ]

    Considering the hype and the high expectations since 2000 the adoption of SOA has been modest at best.
    Maybe you got caught up in the marketing-people hype, but I think plenty of us saw it for what it is from the beginning: A technological approach to solving large scale integration issues.
  185. Re: OSGI == SOA[ Go to top ]

    SOA, although hyped by IBM and other giants for many years, wasn't a success. Therefore marketing decided "we" need a new buzzword: OSGI
    What do you mean "wasnt a success"? SOA is an approach and a philosophy and I can promise you it is very much alive and relevant in large organizations. A SOA approach isnt within the scope of creating your average web-app, its important when you have many disparate systems that need to work in coordinated fashion. When you have that situation, web Services, ESBs and governance become important. That said, SOA is a much abused acronym by marketing and sales poeple, and they will eventually move on a to whatever the hot new concept is. What won't change is the need of large organizations to coordinate and share data among their many legacy systems and standards-based busses, web-services and governance are critical in that endevor.
  186. Reading the long chain of comments in the flame war is making me laugh. I just love how Spring is claiming to be better than sliced bread. From where I'm sitting, looks like spring is bundling other people's work and calling themselves innovators. How about come up with some that is completely new and isn't recycling other people's work? I think Spring is a useful tool, but all this hype and non-sense is completely silly. For me, it's a complete turn off and makes me think twice about recommending spring to anyone. peter
  187. True innovation[ Go to top ]

    Peter, Maybe you should read more deeply about the genuine innovation in the SpringSource Application Platform before jumping to conclusions. These two blogs by Rob and Adrian would be a good start. This is far more than repackaging of "other peoples' work." It introduces a significant amount of new code that solves a number of hard problems that are not solved by existing application servers. Many people have tried to solve those problems themselves, and run into numerous issues. (An example.) Furthermore, we make a significant technology contribution to the existing technologies used in the server over and above the Spring Portfolio. For example, we lead the AspectJ project and have ensured that thet project continued to move ahead with the recent 1.6.0 release. We are also making a major contribution to Tomcat and other Apache technologies. SpringSource has always believed that open source businesses can only be viable if they make a strong contribution to technologies they distribute, and we practise what we preach. Spring has always innovated. It pioneered POJO programming and helped transform enterprise Java for the better. With the SpringSource Application Server we hope to transform the application server. Rgds Rod
  188. Re: True innovation[ Go to top ]

    Peter,

    Maybe you should read more deeply about the genuine innovation in the SpringSource Application Platform before jumping to conclusions. These two blogs by Rob and Adrian would be a good start. This is far more than repackaging of "other peoples' work." It introduces a significant amount of new code that solves a number of hard problems that are not solved by existing application servers. Many people have tried to solve those problems themselves, and run into numerous issues. (An example.)

    Furthermore, we make a significant technology contribution to the existing technologies used in the server over and above the Spring Portfolio. For example, we lead the AspectJ project and have ensured that thet project continued to move ahead with the recent 1.6.0 release. We are also making a major contribution to Tomcat and other Apache technologies. SpringSource has always believed that open source businesses can only be viable if they make a strong contribution to technologies they distribute, and we practise what we preach.

    Spring has always innovated. It pioneered POJO programming and helped transform enterprise Java for the better. With the SpringSource Application Server we hope to transform the application server.

    Rgds
    Rod
    I'm of the opinion, there's nothing new (or very little new) under the sun in the software world. Far too much has already been done and most things today is just recycling old stuff. Is Spring application server a new product. Sure it's a new product, but I feel the world innovative is being applied far too liberally. If you can't tell, I'm playing devil's advocate for fun. I honestly don't think spring application server makes any difference and isn't gonna shake the world upside down. The spring team has put in a lot of hard work and made useful tools. I used to like spring a lot more before some one turned the hype dial to "seriously insane" level. peter
  189. Re: True innovation[ Go to top ]

    I honestly don't think spring application server makes any difference and isn't gonna shake the world upside down.
    +1 Someone needs to update TSS' application server matrix -- looks like there's room underneath #34 on the list. Tom
  190. Reuse[ Go to top ]

    How about come up with some that is completely new and isn't recycling other people's work?
    Ignoring prior art available in open source would be crazy. Why reinvent the wheel? Every server platform, including WebSphere and WebLogic, incorporates substantial amounts of open source software. That way the industry can move forward. The right approach is to contribute back and help to support the projects whose work you use. We do that. Thus we can innovate in new areas rather than waste effort pointlessly re-solving solved problems.
  191. Re: Reuse[ Go to top ]

    How about come up with some that is completely new and isn't recycling other people's work?
    Ignoring prior art available in open source would be crazy. Why reinvent the wheel?
    Really ? What about this ? http://www.springframework.org/spring-integration


    Thus we can innovate in new areas rather than waste effort pointlessly re-solving solved problems.
    Hmm...with this platform/(server ?) you guys have done just that for last 18 months...
  192. Re: Reuse[ Go to top ]




    Thus we can innovate in new areas rather than waste effort pointlessly re-solving solved problems.
    Hmm...with this platform/(server ?) you guys have done just that for last 18 months...
    Interesting... what do suppose it is that we have reinvented here? We have used an existing OSGi implementation (Equinox), an existing servlet container (Tomcat) and existing application frameworks (Spring, Spring WebFlow etc). I certainly haven't seen another application server platform that can run user applications as OSGi bundles as easily as the Platform can. Rob SpringSource
  193. Negative surprise...[ Go to top ]

    Hi Rod & Spring Source team, I must admit I am rather NEGATIVELY surprised with your recent move to create your own application server. I have been a long-time fan and believer of your work done at the application framework level. I always liked the distinction (actually expressed by Rod in his books) between the application framework and the infrastructure (e.g. app servers). Each of them focuses on different areas, has its own issues and solves different problems in different ways. For me the beauty of Spring Framework always lied in the set of nice abstractions, which made USING the low-level infrastructure much more efficient, while at the same time making the application more elegant, more OO, etc. I also liked your philosophy of treating all the most popular infrastructure products (esp. app servers) equally well, while at the same time, again in elegant way, exposing their strengths (transaction management is the best example, i.e. the way of exposing the strengths of WebLogic and WebSphere mature transaction managers). Spring-DM was another excellent example of the value which you guys are bringing to the Java community. This value for me was the ability to use - in a very intelligent way - some well known techniques (like IoP/DI, AOP, patterns like template method, etc.) to abstract sometimes complex technologies, so the life of us, developers is much easier. But this time with Spring Application Platform the situation is different. Instead of extending the application framework, you actually provide the infrastructure. Not just provide, but actually promote it as being more useful, more efficient, etc. The WAY you do it is in big contradiction to what you have been doing so far. Between the lines the message is 'customers - do not be stupid - do not even consider those bulky elephants JEE app servers. Pick us!'. This is strange - many JEE vendors actively promoted Spring. Some, like BEA, even created products in which Spring Framework is critical component (examples: WebLogic Server 10 and WebLogic Event Server). Some of the guys from the app server vendor space even worked actively with you to create the software (e.g. Spring-DM - key part of the new Spring App Platform - participation of Andy Piper from BEA and Hal Hildebrand from Oracle). By entering the infrastructure space, this is like a declaration of war. Is this REALLY what you intent to do??? Sooner or later ALL of the app server vendors will move into OSGi and into EXPOSING modular application deployment model ! By the way - Spring App Platform is not the only infrastructure EXPOSING OSGi model to developers (so, EXPOSING, not just doing internal modularization, which both WebLogic and WebSphere have done quite extensively already). I am sure you know about BEA WebLogic Event Server, based on BEA micro-Service Architecture - the applications here ARE OSGi-based. Event more - WebLogic Event Server provides the programming model via Spring-DM ! So, the key value of Spring App Platform will disappear quite soon - all leading app servers will offer the OSGi-based programming model, so it will be again like comparing Tomcat to WebLogic... Surely - looking at Spring App Platform I see some very nice things, like the OSGi libraries idea, PAR packaging or bundles repository. I would welcome those extensions as part of application framework (e.g. next version of Spring-DM), benefiting ALL developers, all containers. But by promoting the idea of Spring App Platform as next-gen application server being SO much better than established containers I feel a little bit cheated... It is obvious for me that coming next is you claiming "oh, yeah, this feature of Spring Framework works ONLY if you use OUR platform....". I think you are playing risky game. I do not know app framework vendor being equally good at infrastructure (look at JBoss SEAM adoption on non-JBoss servers - it is significantly smaller, close to non-existing). Same is vice-versa - infrastructure vendors have tough time creating good application framework (there is no better example than EJB and Sun). The road from concept to product to making money for infrastructure is very long nowadays. As a USER of both the application framework and the application servers, I appreciated the nice cooperation between SpringSource and the vendors. Now, I am afraid that you are offending your friends at BEA, Oracle, IBM, etc. which might make the cooperation much more difficult, affecting the products we use. Users, like me, will not be happy, if this happens... Cheers, Alexey Reimer from Ukraine
  194. Additional choice[ Go to top ]

    Alexey I'm disappointed that you find having an additional application server choice a bad thing. We are not aiming to force users down a particular path. Just giving them an additional choice. If they take that choice it will be because they perceive it benefits them. The Spring Framework retains its commitment to portability, and contains no code specific to SpringSource Application Server.
    Surely - looking at Spring App Platform I see some very nice things, like the OSGi libraries idea, PAR packaging or bundles repository. I would welcome those extensions as part of application framework (e.g. next version of Spring-DM), benefiting ALL developers, all containers. But by promoting the idea of Spring App Platform as next-gen application server being SO much better than established containers I feel a little bit cheated... It is obvious for me that coming next is you claiming "oh, yeah, this feature of Spring Framework works ONLY if you use OUR platform....".
    We are excited about those features also, which is why we want to deliver a product with them. We are looking at building SpringSource Enterprise distributions for particular environments like WebLogic and WebSphere. We certainly aim as a business and a contributor to open source to provide value to users on those platforms. However, I think you will appreciate that it is technically difficult to deliver the same value and a more modular approach when you don't have the ability to think in terms of the whole stack. (Not to mention the issue of duplication and increased size.) For example, the popular use of OSGi via "bridge servlets" fails to solve many of the practical problems around OSGi and completely fails to address important areas such as library sharing etc.
    As a USER of both the application framework and the application servers, I appreciated the nice cooperation between SpringSource and the vendors. Now, I am afraid that you are offending your friends at BEA, Oracle, IBM, etc. which might make the cooperation much more difficult, affecting the products we use. Users, like me, will not be happy, if this happens...
    That would be our friends at Oracle, IBM etc. as of this week :-)
    This is strange - many JEE vendors actively promoted Spring. Some, like BEA, even created products in which Spring Framework is critical component (examples: WebLogic Server 10 and WebLogic Event Server).
    BEA and other vendors began to take an interest in Spring once they saw it was successful and their customers demanded they had a story on it. They did so out of their own business interests, not out of the kindness of their hearts. (That's not a criticism--it's perfectly normal for companies to be motivated by their business interests.) In the case of WebLogic 10 and WebLogic Event Server, BEA used Spring internally because it helped to maximize adoption and because the availability of high quality code improved time to market. Should we apologize to BEA for the fact that their WebLogic 10 product, for which they charge license fees, contains software at its core that we built for which we receive nothing from BEA or their customers? Seriously, we are very happy to work with leading enterprise software companies. We have traditionally had an excellent relationship with BEA and we hope that continues following the Oracle acquisition. We have worked cooperatively with both IBM and Oracle, and hope to continue to do so. We recognize the importance of these vendors to many of our users and customers. But they don't have a God-given right to be free from competition in the application server space. Competition is a good thing. It drives innovation and benefits consumers. If our platform delivers value, people will use it. If it doesn't, they won't. Furthermore, both BEA and IBM make significant contributions to the Apache Foundation, yet some of their customers abandon Java EE servers for Tomcat. I'm sure such companies are sufficiently mature to realize that co-opetition is a normal reality of business. For example, IBM Global Services do many projects on WebLogic. IBM still has an interest in Lenovo, which ships laptops with Windows on them. IBM's product line is so broad that they need to be able to live in a world where they maintain good relationships with companies that compete with a part of their business. The Spring Framework will continue to serve your needs and will continue to get better. Note the many recent Spring Portfolio releases I've listed on this thread, none of which is specific to our platform. SpringSource will happily sell you support and other services, whatever your platform. We intend to try to maintain a positive relationship with other companies in the space. We don't need to apologize for providing a new choice that we believe will meet the needs of many users better than existing products. Rgds Rod
  195. Portability[ Go to top ]

    Alexey I hope you understand that we remain absolutely committed to making Spring Framework work on all platforms. We understand the needs of users who are happy on their current platforms. I would also suggest that users let their platform vendors know that they value Spring integration. I look forward to healthy co-opetition. Rgds Rod
  196. Re: Negative surprise[ Go to top ]

    Rod, Actually, in our case it was BEA who introduced us to the Spring Framework and OSGi, NOT VICE VERSA ! I do not think our case is specific - I would agree with your opinion few years ago, but not now. I do belive Spring's dominant position in the enterprise space is partialy effect of the app server vendors support - and sometimes, like BEA, commitment - to Spring as THE programming model. The vendors are enterprise animals and have appropriate strengths (like presence, support coverage, etc.). Spring is not exception here - best example is history of Linux in the enterprise. BEA did convinced us to go with Spring on JEE and be cautious with EJB. We really appreciated the clean separation between the application framework and the application server. Sorry, but Tomcat is NOT AN OPTION for us. We have done the comparisions, proofs of concept, etc. and the winner was clear. As you mentioned in your books and in your blog - the difference between app servers is not anymore in the APIs it implements - it is in Qualities of Service of the container. Sorry, but Tomcat is merely web container and lacks wealth of enterprise features of WebLogic. Sure WLS has license cost, but you pay for what you get (and still we have strong feeling the TCO is lower with WLS than with Tomcat). The Oracle aquisition does not change anything (if not actually improves the situation, esp. in our region - Eastern Europe - where Oracle has much bigger presence). Oracle has not really been serious middleware vendor so far, so surely BEA will take the role as part of Oracle. I am very confident about WLS future. The cooperation we have seen (Spring-DM being very good example) have been giving us MORE assurance. Your move with own application server means for us MORE risk. It is clear that some of the features I mentioned will not appear as part of Spring-DM, so we will have to rely on HOPES that BEA (and other vendors) will implement some kind of compatibility layer, when WebLogic Server will expose OSGi programming model to programmers (as your Platform currently does). This will happen rather soon - I count on 3-6 months timeframe as both BEA and IBM are quite advanced in OSGi-fying their app servers. As BEA demonstrated us with the WebLogic Event Server (which ALREADY exposes the OSGi programming model through the same Spring-DM layer) - they are really close. I am even thinking about suspension of our move into OSGi to see what kind of impact your recent move will have. Well - if I feel cheated, then what actually the BEA guys must be feeling now... Cheers, Alexey Reimer from Ukraine
  197. Re: Negative surprise[ Go to top ]

    Alexey I believe my previous post explained all the reasons that you are completely wrong, so I'll only comment on your new comments.
    Actually, in our case it was BEA who introduced us to the Spring Framework and OSGi, NOT VICE VERSA !
    That's great, but your case is not typical. This is the case for a small fraction of the Spring user base. Most Spring users do not use WebLogic (as Spring is used on all popular platforms), and BEA chose to work with Spring and partner with SpringSource (Interface21) only because their own market research showed that a large proportion of their user base were using Spring. As I explained before, this introduction would have been in their interests. Unhappy customers are bad for business. I'm sure that BEA preferred having happy, successful customers using Spring than grumpy, unsuccessful customers using a flawed legacy programming model.
    Well - if I feel cheated, then what actually the BEA guys must be feeling now...
    I imagine they would be feeling quite pleased about the benefits they have got and continue to get from Spring. They didn't need to implement the new injection and interception functionality in Java EE, because they could use Spring (with our cooperation). They didn't need to have a proprietary programming model for WebLogic Event Server, as they could use Spring. They didn't need to do more than a small proportion of the work on Spring DM, yet they got sophisticated integration of that component model with OSGi. And they got all of that for free. And they charged customers license fees for the combined product. Frankly, BEA (Oracle) can express their own views and don't need you to jump to conclusions for them. We've always had a good relationship with both companies. We anticipate continued cooperation. We are absolutely committed to making the Spring Framework and other Spring Portfolio projects work outstandingly on their platforms and make their customers happier. Thus I am very confident that we will continue to work together in a constructive fashion for the benefit of everyone's users and customers.
    when WebLogic Server will expose OSGi programming model to programmers (as your Platform currently does). This will happen rather soon - I count on 3-6 months timeframe as both BEA and IBM are quite advanced in OSGi-fying their app servers.
    Of course they will OSGi-ify their application servers. They need to, because it's the future of enterprise Java. Let's look at the products when they ship them. I'm puzzled that you seem to want SpringSource to apologize for delivering tomorrow's technology today, and I didn't realize that we needed to ask Larry Ellison for permission before doing so. Rgds Rod
  198. Re: Negative surprise[ Go to top ]

    I'm puzzled that you seem to want SpringSource to apologize for delivering tomorrow's technology today

    Rgds
    Rod
    that sentence doesn't make any sense to me. If it's here today, how can it be the technology of tomorrow? Did you invent a time machine, go to the future, grab source code and then come back to May 2nd 2008? Assuming you did go to the future, isn't time traveling a bit irresponsible and dangerous? The follow up question is, why didn't you also look at the lottery numbers when you were in the future? I'm not convinced it's "tomorrow's technology" since it's a refinement of old and existing ideas. Perhaps "different, new or shiny" would be a better adjective than "tomorrow"? Don't mind me though, carry on with the hyperbole and hype. peter
  199. Re: Negative surprise[ Go to top ]

    I'm puzzled that you seem to want SpringSource to apologize for delivering tomorrow's technology today

    Rgds
    Rod


    that sentence doesn't make any sense to me. If it's here today, how can it be the technology of tomorrow? Did you invent a time machine, go to the future, grab source code and then come back to May 2nd 2008? Assuming you did go to the future, isn't time traveling a bit irresponsible and dangerous? The follow up question is, why didn't you also look at the lottery numbers when you were in the future?
    Peter, Rod was referring to SpringSource leading the way with providing access to new technology. The phrase "tomorrow's technology today" is fairly well known when describing this. In fact, popular gadget magazine T3, takes its title from this idiom and I don't think anyone could accuse its writers of time travel :) Regards, Rob
  200. Re: Negative surprise[ Go to top ]

    I'm puzzled that you seem to want SpringSource to apologize for delivering tomorrow's technology today

    Rgds
    Rod


    that sentence doesn't make any sense to me. If it's here today, how can it be the technology of tomorrow? Did you invent a time machine, go to the future, grab source code and then come back to May 2nd 2008? Assuming you did go to the future, isn't time traveling a bit irresponsible and dangerous? The follow up question is, why didn't you also look at the lottery numbers when you were in the future?


    Peter,

    Rod was referring to SpringSource leading the way with providing access to new technology. The phrase "tomorrow's technology today" is fairly well known when describing this. In fact, popular gadget magazine T3, takes its title from this idiom and I don't think anyone could accuse its writers of time travel :)

    Regards,

    Rob
    Good thing I don't read T3 magazine. It sounds a bit too terminator-ish to me. Too bad Spring didn't invent a time traveling machine, it would be wicked sweet to see who wins the next 10 super bowls. Maybe Tom brady will redeem himself. peter
  201. Re: Negative surprise[ Go to top ]

    I'm puzzled that you seem to want SpringSource to apologize for delivering tomorrow's technology today

    Rgds
    Rod


    that sentence doesn't make any sense to me. If it's here today, how can it be the technology of tomorrow? Did you invent a time machine, go to the future, grab source code and then come back to May 2nd 2008? Assuming you did go to the future, isn't time traveling a bit irresponsible and dangerous? The follow up question is, why didn't you also look at the lottery numbers when you were in the future?


    Peter,

    Rod was referring to SpringSource leading the way with providing access to new technology. The phrase "tomorrow's technology today" is fairly well known when describing this. In fact, popular gadget magazine T3, takes its title from this idiom and I don't think anyone could accuse its writers of time travel :)

    Regards,

    Rob
    And it is still beta software, so one might argue it's not here yet ;-)
  202. Re: Negative surprise[ Go to top ]

    I'm puzzled that you seem to want SpringSource to apologize for delivering tomorrow's technology today

    Rgds
    Rod


    that sentence doesn't make any sense to me. If it's here today, how can it be the technology of tomorrow? Did you invent a time machine, go to the future, grab source code and then come back to May 2nd 2008? Assuming you did go to the future, isn't time traveling a bit irresponsible and dangerous? The follow up question is, why didn't you also look at the lottery numbers when you were in the future?


    Peter,

    Rod was referring to SpringSource leading the way with providing access to new technology. The phrase "tomorrow's technology today" is fairly well known when describing this. In fact, popular gadget magazine T3, takes its title from this idiom and I don't think anyone could accuse its writers of time travel :)

    Regards,

    Rob


    And it is still beta software, so one might argue it's not here yet ;-)
    Oh, I get it now. Since it's betaware, it's tomorrow's technology. Wait, that doesn't work though. Google has had a lot of stuff that has been Beta for years. If we go by Beta status, I could argue windows Vista is tomorrow's technology that never materialized. peter
  203. Re: Negative surprise[ Go to top ]

    Oh, I get it now. Since it's betaware, it's tomorrow's technology. Wait, that doesn't work though. Google has had a lot of stuff that has been Beta for years.
    Yeah, I've heard Google has an email client in Beta. Wonder if anyone is brave enough to use that yet ;-)
  204. Talking about the technology[ Go to top ]

    Getting back to the technology, here's a link to a user experience.
  205. EPL vs. GPL3[ Go to top ]

    Any comments from the SpringSource guys about the EPL not being compatible with GPL3 issue that has been brought up a few times now? It's an interesting question and it seems to have fallen on deaf ears.
  206. If what you are looking for is Spring Framework + Tomcat + genuinely modular Spring-based application development, Impala is a simpler solution. See http://impala.googlecode.com/ The first public release has been uploaded - expect an announcement on this site next week. At this point, OSGi is not present in Impala: here's why: http://impalablog.blogspot.com/2007/11/impala-and-osgi.html At the end of the day, I'm yet to be convinced that rank and file developers (or even smart ones) will take easily to OSGi. Betting so heavily that they will is a gamble. Phil Zoio
  207. Spring arrives[ Go to top ]

    In an effort to provide a little context to this ever-increasing debate, i wrote a blog entry for the first time in some months: http://douglasdooley.blogspot.com/2008/05/spring-arrives.html it is my first attempt at giving Spring supporters the benefit of the doubt, as I am impressed by this announcement, douglas dooley http://douglasdooley.blogspot.com/
  208. Re: Spring arrives[ Go to top ]

    In an effort to provide a little context to this ever-increasing debate, i wrote a blog entry for the first time in some months: http://douglasdooley.blogspot.com/2008/05/spring-arrives.html
    It's not Spring vs. Sun (gnome vs. giant) but Spring vs. Apache, venture capital vs. community.
  209. Re: Spring arrives[ Go to top ]

    In an effort to provide a little context to this ever-increasing debate, i wrote a blog entry for the first time in some months: http://douglasdooley.blogspot.com/2008/05/spring-arrives.html

    It's not Spring vs. Sun (gnome vs. giant) but Spring vs. Apache, venture capital vs. community.
    Hardly. SpringSource supports a large number of Apache-licensed software including Spring Framework, Spring Web Flow, Spring Web Services, Spring Security, Apache Tomcat and Apache HTTPD. It's hard to see how that can be construed as Spring vs. Apache. And there is the small fact that Jim Jagielski, Apache Software Foundation co-founder and Chairman, is our Chief Architect. Bill Rowe, HTTPD developer and Apache board member, and Filip Hanik, leading committer on Tomcat also work at SpringSource. Regards, Rob
  210. What about JMS?[ Go to top ]

    Perhaps I missed it because I didn't go through all the docs, but what about pre-integrated JMS support? Do I have to hook up activemq to Tomcat? This is definitely something most of us need. Cheers, Yuval.
  211. Re: What about JMS?[ Go to top ]

    Perhaps I missed it because I didn't go through all the docs, but what about pre-integrated JMS support?
    Do I have to hook up activemq to Tomcat?

    This is definitely something most of us need.

    Cheers,
    Yuval.
    Yuval, In the 1.0 release we don't have any explicit JMS support other than that already present in the Spring Framework. We will be including JMS support in the 2.0 release. Regards, Rob
  212. We are in the process of evaluating the Java EE platform for our applications. Currently, they are running on WebLogic 8.1. We will choose between WebLogic 10 or JBoss 5.0. We can not add to this list S2AP for lack of loadbalancing of remote services. Otherwise it seems like a good alternative.
  213. We are in the process of evaluating the Java EE platform for our applications. Currently, they are running on WebLogic 8.1.
    We will choose between WebLogic 10 or JBoss 5.0.
    We can not add to this list S2AP for lack of loadbalancing of remote services. Otherwise it seems like a good alternative.
    If you would be more specific about your load balancing requirements, I think we might suggest a better option that would work with the current platform. I can assure you that it was not overlooked. Iwein Fuld SpringSource
  214. Our need is the use of only remote stateless services (RMI, HTTP Invoker) with dynamic discovering (like features of Cluster4Spring). Of course, you intend to comply with the future Java EE 6 Profile B, however, this is not enough for us since EJB "Lite" are restricted ("for now") to EJB Local.
  215. -1 for this licensing move of SpringSource. I hope they change their mind. In my day job, I am working on proprietary end-user software while using lots of open source libraries. I make a point of contributing back patches (bugfixes, new features, ...) and feed-back (jira's, ...). To GPL this end-user software won't be an option and paying for every deployment neither. That's why the springframework was the right choice. So using the SpringSource application platform won't be an option for us. When SpringSource starts neglecting springframework's core (in favor of it's application platform), we'll need to look for an alternative for the springframework too (which I am not looking forward too). On the other hand, the idea of an OSGi app server is really appealing to me, I can't wait for JBoss to fix the JBoss AS deployment model to be OSGI compatible, under the LGPL license. Or maybe SpringSource can be convinced to change their mind to LGPL their application platform. This is my personal opinion (not necessary that of my employer) as java developer, spare-time spring-richclient developer and spare-time drools-solver developer.
  216. Won't happen[ Go to top ]

    When SpringSource starts neglecting springframework's core (in favor of it's application platform), we'll need to look for an alternative for the springframework too (which I am not looking forward too).
    "starts neglecting springframework's core"--this won't and can't happen. Won't: SpringSource is committed to all portfolio products. So those will not be neglected in any way. Can't: SSAP provides an execution environment and not a programming model. The preferred model on SSAP will always be the Spring framework and it cannot be in our self interest to neglect it. If anything, you will see more focus on the core. -Ramnivas SpringSource
  217. When SpringSource starts neglecting springframework's core (in favor of it's application platform), we'll need to look for an alternative for the springframework too (which I am not looking forward too).
    How do you justify this conclusion? As Ramnivas points out, the Spring Portfolio is the basis of everything we do. I've already given a detailed explanation earlier in this thread of how we are doing more in Spring than ever. As SpringSource grows, resource devoted on Spring grows. That's not my opinion; it's demonstrable fact.
  218. As SpringSource grows, resource devoted on Spring grows. That's not my opinion; it's demonstrable fact.
    That's good news :) So I hope I 'm wrong on that part. But it still doesn't change the fact that we can't use (or contribute to) SpringSource application server due to it's license. LGPL would have allowed that (as it's commercial-friendly). So once we can't run a separate JVM for every server application no more, we 'll have to look for a deployment solution elsewhere. Though the idea of an OSGi based app server does sounds great.
  219. Running gag?[ Go to top ]

    There is this open issue regarding the EPL license. I've benn through the postings and did not find any statement here. It looks like GPL and EPL licenses are completely incompatible. How is that?
  220. There is this open issue regarding the EPL license. I've benn through the postings and did not find any statement here.

    It looks like GPL and EPL licenses are completely incompatible.

    How is that?
    Rod & Co.. have quickly replied to just about every other issue so my guess is they are purposefully avoiding this one. Either they don't have a good answer or are scrambling to come up with one. Either way, don't hold your breath.
  221. We took advice from open source licensing experts at two leading law firms who assured us that our distribution complies with both licenses. It is correct that it is impossible to relicense EPL code under the GPL. As shown on our downloads page, the EPL and GPL code and binaries are distributed separately. Accordingly, we are respecting the terms of both licenses. Naturally we would like to maximize convenience to the community by having the SpringSource Application Platform available as a single download. We are currently in discussion with the Eclipse Foundation (of which SpringSource is also a member) to explore whether this might become possible in the future. More information is available at our licensing FAQ. If you have any questions, please feel free to contact me at neelan dot choksi at springsource dot com Neelan Choksi SpringSource
  222. This is great and all. But how can I distribute an application to customers? I have to ask them to download three files, right? No wait, my app still would become GPL covered since it's not the LGPL and you are not using "standards" interfaces. That is why I buy a Spring Framework licence from you then. I think my customer just lost his "open source rights". Anyway, he still would have to download and install the OSGi runtime separately, right?
  223. GPL: Was it worth it?[ Go to top ]

    I am wondering if after all, GPL is was a good idea. If you look at the length and the content of this thread, you will see that the overall understanding of how and why GPL should be used has a wide spectrum. Thanks SpringSource for the postings clarifying "your understanding" of the GPL. The problem is, there is too much room for "in our understanding" and "maybes". IMHO, I cannot rely on those statements. They are not binding, but the GPL is. It is fact, FUD or not, that many companies won't even take a look at the Application Platform - just because its GPL. It is also fact, that SpringSource was licensing Apache2, now it's licensing GPL and Apache2 and some closed source stuff (Enterprise Spring, etc.). In the past I could simply say "SpringSource? No prob, it's safe, just pick it and go". Today I have to say "Well, it depends... maybe... it is their understanding that...". This is a significant shift in the direction. I hope it is the right one. My point is: the Spring framework is much more than a Framework and those 125++ SpringSource employees. There are thousands of developers spreading the word, hundreds of companies providing training, coaching, support. Spring really has grown out of the community, and SpringSource did a good job steering, providing the right direction. I don't see it as a hype. Hypes don't last that long and relase that much... ;-) The Spring framework is awesome and used by many. It is licensed Apache 2 - it could be closed source. No one ever did that (or did I miss it?). What are you afraid of with the Aplication Platform? Even if someone closes it - so what? As you explained before, there is more then code when it comes to success. As stated here in some postings, you need a least a good idea, good people, funding. SpringSource seems to have all of it. Why this sudden change of mind? The same applies to your new enterprise development environment. As far as I understood, it is only available for those who have the subscriptions. In my point of view this only means less people using it, less people spreading the word, less people that really understand the value gain. It could be that Gammas new toy called Jazz is very goog - I will probably never know it. It is by far too expensive for me. On the other hand, I love those people providing MyEcliseIDE. Hey, it's commercial. But not that greedy (sorry for the word, but I think it describes it well). I have been doing lots of Spring development, coaching, support lately. Until now, I felt like I am part of a community. My contribution cannot be measured in code, patches or Jira issues. But still, I was first class citizen in this Spring community. My feeling tells me I am not anymore. I hope SpringSource is steering in the right direction. I know some of SpringSource personally and I know how hard they work and that they have raised the quality bar in the OSS comunity. I just hope that GPL, commercial licenses and closed certification programs aren't the beginning of the end. Just my 2 cents. Papick G. Taboada Technology Scout
  224. JDO Sucked[ Go to top ]

    You guys call this a thread? Pfft. JDO Sucked and you just can't get reliable performance on ad hoc queries in an object database. - Don
  225. The notion that you should only use projects backed up by companies is pretty ridiculous. It's the kind of argument I'd expect from a paper shoving architect, not a developer. Do you think money automatically provides a culture of innovation and community participation (which is typically very good for bug fixing)? I'd argue to opposite (you are championing Microsoft for what exactly?).
    Sure, it's ridiculous. Every one of use architect/developer types here, I'd bet 99.99% of us, would agree it's ridiculous. Here's the problem though: in large corporations it is frequently NOT the architects/developer-types that make those decisions. It's lawyers and executives who maybe read somewhere once that open-source, and the GPL maybe in particular, are "viral" and therefore "dangerous" to their business. Understanding doesn't come into it, learning the details doesn't come into it. Well, for the executives anyway... one *presumes* the lawyers understand to *some* degree because that's their job, but either way it doesn't matter: someone from legal, or someone from the executive suite, makes a short-sighted decision and that's the way it is for that company, period. This isn't an isolated attitude, it's not a rare attritude in my experience. *Many* large corporations come to the same conclusions, right or wrong, good or bad, ridiculous or not. *I* don't agree with it, but so what? And it doesn't matter what any of us in the OS community say, or in projects trying to go commercial say. That's reality, and for anyone to get high-minded and say those people are stupid and will come around eventually, well, maybe the will and maybe they won't, maybe they are stupid and maybe they aren't... but it doesn't change the reality of *today*, that's my point.
    But there is absolutely no reason to reject open source products coming from SpringSource based on whether the company has enough financial backing (or whether it is pushing proprietary standards for that matter). Just look at the quality and maturity of the project. and the community that evolves around it.
    Likewise, many large corporations will only use software that comes from some other corporation, someone that either (a) indemnifies them against the perceived risk of open-source, or (b) is a target for legal action should something go wrong. It sadens me every time a decision is made with these things in mind, and I've seen it far too often. It's foolish in my opinion, but it's also the climate of the business world, at least here in the U.S. So, as much as I want to see it change, this is the way it is today. Not for every business mind you, there's plenty of exceptions, plenty of companies run by people who can see things a little differently (clearer, IMO)... I don't even know if that attitude of avoidance is the most prevalent frankly, maybe it's not. I *do* know it's not exactly rare though, it's not that unusual.
  226. We aren't primarily focused on the section of the market that is running very old applications using such legacy technology.
    EJB 2.0x is 'very old'?? Aside from that, I can't help thinking that the reason a substantial portion of the Java community was so happy with Spring was the fact that it was such a 'lightweight' framework as opposed to all those bloated JEE application servers. Ever since Spring came on the scene I've been saying the only reason it's 'lightweight' is because it doesn't implement much of what a JEE app server does. So now Spring decides to implement some of the other stuff which presumably is all those bits that most people don't use. We use a high degree of complicated transactions that span JDBC, CICS ECI, Tuxedo and Message brokers. Funny how we had to wrap the calls in a single EJB 2.0 session bean in order to get a distributed transaction to work across this array of resources when we decided to discard EJB in favour of POJO and Spring. We are not the only large organisation that needs to do a lot of this kind of stuff either. I've no doubt that Spring will eventually get there but it doesn't cut it for the scale of apps we work with and I'm also sure that by the time it does, it will be just as complicated, bloated and hard to configure as the current swag of app servers.