Taking the SpringSource Application Platform for a Spin
So, I headed over to the Beta Program page and filled out the form. Apart from the standard details, SpringSource was curious about whether my interest in its platform comes out of its OSGi support or its Spring basis, as well as my OS and my currently used server platforms (which, as far as I understand, are all servers, not server platforms, at least not in the way that SpringSource's offering is a server platform):

What was pretty cool was that as soon as I completed the form above, I was presented with a login form. I had expected to have to wait for some kind of confirmation message or something similar. But, no, I was good to go right away. I downloaded and unzipped the archive I found on the following page, read the (very good) documentation and discovered that applications autodeploy when placed in the "pickup" folder, which is what I did, with a Tomcat sample app, as highlighted below:
Next I ran the two scripts you see in the "bin" folder above. First, I ran "setupClasspath.sh" (would have been nice if some output had been displayed, so I could see what had been set exactly, without needing to look into the shell script itself) and then the "startup.sh", which showed me the following interesting info:
Nice. The server is clearly running. I went to my browser, opened it at the spot specified in the user document, and saw the app had been successfully deployed, i.e., the browser displayed the same as it would normally do for the application I tested. Then I had a look at the online admin console, which showed me that my app was deployed, while enabling me to manually deploy anything else from there:
All very intuitive, an experience that was seamless with what I would expect a server to do for me. I did find the whole experience very fast and fluid. As stated above, I was very impressed by the documentation, which is very extensive, considering we're only dealing with a Beta release here. Very nicely organized, nice friendly font, clear instructions, and so on:
I haven't looked through the latter of the two above in great detail yet, but the former presents everything one would want, even including the admin user/password, which would have presented a frustrating experience if it hadn't been documented. The biggest thing I'm missing right now is information on how to move from a WAR to a PAR. "What?" you ask, "what on earth is a PAR!?" A PAR is a "Platform ARchive", a collection of OSGi bundles. To really gain from the SpringSource Application Platform, one would have a PAR instead of a WAR (or EAR). But, I think it is incumbent upon SpringSource to explain, step by step, how one moves from a WAR (or EAR) to a PAR. I.e., not only high level statements on what one would do in principle, but practical steps using an actual example application. (Maybe they've done so, but I haven't yet come across it in the documentation.)
Finally, not all my test applications successfully deployed. All those in which I was using the Wicket framework failed, with this message in the browser:

Not only am I hoping that there's nothing about Wicket that should prevent it from being deployed to the SpringSource Application Platform, but I'm also hoping that there'll be better diagnostics in messages such as the above by the time the official release comes out.
Nevertheless, aside from those caveats, I'm very impressed by the SpringSource Application Platform's ease of use and speed, even without OSGi bundle deployment. Have you tried it? Want to share your experiences here?
| Attachment | Size |
|---|---|
| s2ap-2.png | 151.22 KB |
| s2ap-3.png | 36.89 KB |
| s2ap-4.png | 95.19 KB |
| s2ap-5.png | 29.87 KB |
| s2ap-1.png | 15.21 KB |





Comments
JS Bournival replied on Thu, 2008/05/01 - 2:16pm
Tried it with Grails:
> grails war
> cp myapp-0.1.war $PLATFORM_HOME/pickup
It just works.
Craig Walls replied on Thu, 2008/05/01 - 3:13pm
Geertjan Wielenga replied on Thu, 2008/05/01 - 3:17pm
Craig Walls replied on Thu, 2008/05/01 - 3:25pm
I can't say for certain whether it has anything to do with Wicket 1.3.3 or not. We're still using 1.3.0 because we were too close to a release of our app to go to a newer version of Wicket. I do recall seeing some odd behavior when going from 1.3.0 to 1.3.1 some time ago, so I switched back and never tried again (again, too close to a release to take any risks).
As for more info...have you looked in the "serviceability" folder? There are some logs in there that might help you.
Rob Harrop replied on Fri, 2008/05/02 - 3:03am
Geertjan,
Great blog entry! With respect to migrating from a WAR to PAR, we'll be updating our online docs daily as new content arrives, and we have a migration tutorial planned for inclusion in the next couple of days (barring JavaOne interruptions!).
I'd like to get to the bottom of your Wicket issue - can you send me your test project and we'll try it out for you.
Regards,
Rob
Geertjan Wielenga replied on Fri, 2008/05/02 - 5:53pm
Michael O'Keeffe replied on Fri, 2008/05/02 - 9:15pm
Hmm, I could swear I read a while back, on the ServerSide perhaps, about how the Spring folks didn't think the app server added any value. Thank you very much, but I'll take my neat, polished admin console over futzing with a bunch of XML files.
So this here beta application server is a bit of a flip-flop.
But I'm all for improving the Java platform, and seeing Eclipse, Glassfish, and now Spring jump on the bandwagon, should really give OSGi some credibility. Excellent.
Welcome, Spring.
Rob Harrop replied on Sun, 2008/05/04 - 5:55am
Geertjan,
You can create a JIRA issue at http://issuetracker.springsource.com and attach your project there.
Regards,
Rob