|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 225
Messages: 225
Messages: 225
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
SpringSource Application Platform - totally rocks
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.
|
|
|
Message #251540
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource Application Platform - cool but not there yet!
And naturally, it's there now - not fifteen minutes after I called SpringSource to ask about it. :)
|
|
|
Message #251543
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource Application Platform - cool but not there yet!
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.
|
|
|
Message #251544
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
It might be about as good as Glassfish
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.
|
|
|
Message #251545
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource Application Platform - cool but not there yet!
Rob Harrop just posted a blog entry providing a high-level overview of the platform and providing links to documentation and downloads.
-- Regards, Adrian.
|
|
|
Message #251546
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Worth noting
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.
|
|
|
Message #251547
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: It might be about as good as Glassfish
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.
|
|
|
Message #251548
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: It might be about as good as Glassfish
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
|
|
|
Message #251549
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Worth noting
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
|
|
|
Message #251556
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: It might be about as good as Glassfish
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.
|
|
|
Message #251557
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Great job
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.
|
|
|
Message #251559
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why GPLV3 ?
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.
|
|
|
Message #251561
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why GPLV3 ?
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
|
|
|
Message #251562
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why GPLV3 ?
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
|
|
|
Message #251565
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: It might be about as good as Glassfish
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.
|
|
|
Message #251567
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource Application Platform - cool but not there yet!
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?
|
|
|
Message #251568
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: It might be about as good as Glassfish
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
|
|
|
Message #251570
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource Application Platform - cool but not there yet!
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.
|
|
|
Message #251569
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource Application Platform - totally rocks
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.
|
|
|
Message #251571
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource Application Platform - totally rocks
... 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
|
|
|
Message #251572
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why GPLV3 ?
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.
|
|
|
Message #251573
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource Application Platform - totally rocks
... 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.
|
|
|
Message #251575
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
GPL3 and FUD
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
|
|
|
Message #251576
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource Application Platform - totally rocks
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
|
|
|
Message #251578
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Re: Why GPLV3 ?
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.
|
|
|
Message #251577
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource Application Platform - totally rocks
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.
|
|
|
Message #251579
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource Application Platform - totally rocks
How do you even distribute Apache license code among with GPL code? Doesn't GPL imply that whole distribution must be licensed under GPL?
|
|
|
Message #251580
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource Application Platform - cool but not there yet!
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.
|
|
|
Message #251581
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource Application Platform - totally rocks
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...
|
|
|
Message #251582
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What about spring.jar?
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
|
|
|
Message #251583
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource Application Platform - totally rocks
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!
|
|
|
Message #251584
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource Application Platform - cool but not there yet!
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?
|
|
|
Message #251585
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: What about spring.jar?
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
|
|
|
Message #251586
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: What about spring.jar?
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.
|
|
|
Message #251590
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: GPL3 and FUD
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).
|
|
|
Message #251591
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: GPL3 and FUD
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
|
|
|
Message #251592
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: GPL3 and FUD
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.
|
|
|
Message #251594
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
.NET modules
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
|
|
|
Message #251596
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: .NET modules
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
|
|
|
Message #251598
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why GPLV3 ?
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@lycos.com. I could use all the help I can get :-).
|
|
|
Message #251599
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Just a quick edit remark......
> The power this implies cannot be understated.
Unless youre flaming SpringSource, i think you mean to say,
"The power this implies cannot be overstated."
|
|
|
Message #251600
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
GPLv3 compatibility
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?
|
|
|
Message #251603
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
GPLV3 - SpringSource will fail
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.
|
|
|
Message #251604
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Equinox + Spring Dynamic Modules
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 :-)
|
|
|
Message #251605
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why GPLV3 ?
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...
|
|
|
Message #251608
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource Application Platform - totally rocks
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
|
|
|
Message #251609
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why GPLV3 ?
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
|
|
|
Message #251610
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: What about spring.jar?
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.
|
|
|
Message #251611
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why GPLV3 ?
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
|
|
|
Message #251613
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
So why was this necessary again?
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 ;-)
|
|
|
Message #251615
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Equinox + Spring Dynamic Modules
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.
|
|
|
Message #251616
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why GPLV3 ?
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).
|
|
|
Message #251617
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: So why was this necessary again?
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 ;)
|
|
|
Message #251621
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why GPLV3 ?
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
|
|
|
Message #251620
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why GPLV3 ?
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
|
|
|
Message #251622
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why GPLV3 ?
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.
|
|
|
Message #251623
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: We should welcome this move by SpringSource
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.
|
|
|
Message #251624
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Apache license question
You can relicense any Apache code as GPL (but not vice versa).
Well, Apache is a business friendly license ...
|
|
|
Message #251625
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why GPLV3 ?
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
|
|
|
Message #251626
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why GPLV3 ?
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
|
|
|
Message #251627
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Timing Is Everything
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!
|
|
|
Message #251629
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Single-vendor
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.)
|
|
|
Message #251630
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: We should welcome this move by SpringSource
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?
|
|
|
Message #251631
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why GPLV3 ?
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
|
|
|
Message #251633
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Springsource == shaky company
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.
|
|
|
Message #251634
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why GPLV3 ?
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.
|
|
|
Message #251636
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: GPLV3 - SpringSource will fail
Still waiting for the why EPL is compatible with GPL v3...
|
|
|
Message #251640
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Malicious FUD
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
|
|
|
Message #251642
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
GPL/EPL licenses are incompatible
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
|
|
|
Message #251644
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Still ASL 2.0 license?
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.
|
|
|
Message #251645
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Still ASL 2.0 license?
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.
|
|
|
Message #251647
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Absolutely no FUD
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.
|
|
|
Message #251650
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Re: GPLV3 - SpringSource will fail
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!
|
|
|
Message #251651
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
ClassLoaders
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
|
|
|
Message #251657
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: ClassLoaders
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
|
|
|
Message #251659
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SpringSource != shaky company
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
|
|
|
Message #251662
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: ClassLoaders
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
|
|
|
Message #251663
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SpringSource == shaky company
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.).
|
|
|
Message #251665
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SpringSource == shaky company
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.
|
|
|
Message #251668
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SpringSource success means growing investment in open source
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
|
|
|
Message #251669
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why is JEE the only alternative?
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...
|
|
|
Message #251671
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Absolutely no FUD
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
|
|
|
Message #251674
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Spring's Web Portfolio
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.
|
|
|
Message #251672
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource == shaky company
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.
|
|
|
Message #251675
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource == shaky company
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.
|
|
|
Message #251677
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Still ASL 2.0 license?
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.
|
|
|
Message #251678
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why is OSGI important to developers?
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?
|
|
|
Message #251680
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Sustainable open source
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.
|
|
|
Message #251681
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Wow, talk about hyping themselves
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
|
|
|
Message #251682
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource success means growing investment in open source
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
|
|
|
Message #251684
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
True innovation
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
|
|
|
Message #251686
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Reuse
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.
|
|
|
Message #251687
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource success means growing investment in open source
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
|
|
|
Message #251688
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource success means growing investment in open source
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?
|
|
|
Message #251689
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why is OSGI important to developers?
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."
|
|
|
Message #251690
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource success means growing investment in open source
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
|
|
|
Message #251691
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Negative surprise...
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
|
|
|
Message #251692
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: True innovation
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
|
|
|
Message #251693
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: SpringSource success means growing investment in open source
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
|
|
|
Message #251695
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Additional choice
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
|
|
