The Spring Blog
<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01//EN”>
This week the EclipseLink team announced the release of EclipseLink 1.0. I’ve been using EclipseLink on S2AP for a while now; in fact, I used EclipseLink when developing our JPA load-time-weaving support.
We’ve yet to upgrade our internal usage to 1.0 - our beta9 was tagged just before the announcement - but I wanted to demonstrate how effectively the pairing works in an OSGi environment.
EclipseLink in Petclinic
In the 1.2.0 version of the S2AP Petclinic sample, we released the EclipseLink implementation of the Clinic back-end. The back-end is a drop-in replacement for the JDBC back-end that was previously the only option.
SpringSource is organizing its first dedicated seminar day in central Europe: the SpringSource Seminar Day in Linz, Austria, on September 8th, 2008. This is a full-day seminar about current hot topics in the Spring portfolio: a rare chance to hear about what’s brand-new and upcoming right from the Spring project leads! The agenda is planned as follows:
8:30 … Open for registration
9:30 … Welcome and introduction (by Juergen Hoeller)
9:45 … Keynote: The Spring Portfolio (by Rod Johnson and Adrian Colyer)
11:00 … Introducing the SpringSource Application Platform (by Rob Harrop and Eberhard Wolff)
12:00 … Lunch break (lunch buffet provided on site)
13:00 … Tools for Enterprise Development and Management (by Christian Dupuis and Jennifer Hickey)
14:15 … Developing Rich Web Applications with Spring (by Keith Donald and Agim Emruli)
15:15 … Coffee break (coffee and cookies provided on site)
15:45 … Spring Framework 3.0 – The Next Generation (by Juergen Hoeller and Mike Wiesner)
17:00 … Spring.NET 1.2 (by Mark Pollack and Erich Eichinger)
18:00 … Meet & Greet at the SpringSource booth (including drinks and snacks)
19:00 … End of the seminar
When Oracle acquired BEA systems, I and others noted the significance of the loss of the only independent Java middleware vendor. With Oracle's recent announcement of a price hike for their products, including WebLogic Server, this is no longer a theoretical issue. They have the oil, and they think they have existing customers over a barrel. The need for alternatives is now even more painfully clear.
In fairness, Oracle's move is partly driven by the weakness of the US dollar, but the increases in WebLogic pricing are far greater than those affecting other products.
In this article I will show you how to run a Spring Batch job in the SpringSource Application Platform. I ran an early version of this up as a little demo for JavaOne, and then again at the London Spring User Group, and thought it might be a good thing to share. The sample code is here.
First we’ll do a quick tour of the bundles in the sample code. Start the server now, or at any point after you have installed some bundles.
This one is useful to have around for development and testing. All it does is launch an instance of HSQLDB in server mode, so that you can connect to it and inspect the database using SQL statements. You can just drag and drop it into the Platform Server instance in the Servers View. Do this first, because the Platform remembers the order in which bundles were installed, and starts them in that order. This one has to be started first because other bundles will try to connect to the database server.
As an open source software provider, we think we should be open about our strategy, too. We’d like to share how we got here, where we’re going and why the journey will be good for Spring, good for Spring users and good for SpringSource.
The Spring story began in 2001, when I began working on the 30,000 lines of framework code I published along with Expert One-on-One J2EE Design and Development in 2002. My objective was to help others to avoid the pitfalls that I had encountered completing J2EE projects since 1999.
After my talk on Spring Integration I’ve been getting quite some questions on clarification and samples. To meet the demand I will start a small series on implementing different integration patterns using Spring Integration. This first article will focus on the basics. It will show you how to get up and running and walk through one of the samples.
If you never heard about Spring Integration before it might be a good idea to familiarize yourself with it reading the introductory blog Mark Fisher wrote about it or by browsing the project website. In general
InfoQ has a discussion thread summarizing the reactions to the announcement of the SpringSource Application Plaform. Michael Burke asked a great question on that thread which can be paraphrased as “forgetting the hype surrounding OSGi, what benefits can I expect to see if I port an application currently packaged as an EAR to OSGi bundles?”.
I started answering this question on the InfoQ thread, but my answer was growing too long for a comment so instead I’ll address it here.
The question is a good one. The main difference you will see in an OSGi-based application versus a traditional JEE EAR-based application is improved modularity. So the question becomes, does this improved modularity bring me any benefits, and if so what are they? The book “Design Rules, The Power of Modularity” gives a very thorough treatment of the question. It’s great background but I get that feeling that Michael may be looking for something a little less theoretical than what you’ll find in that book! Let’s break the modularity benefits down into two categories: benefits you should expect to experience during development time, and benefits you should expect to experience during runtime:
It’s been great to hear so much discussion on the SpringSource Application Platform, online and on the floor here at JavaOne. One of the most insightful comments is from WebSphere transaction architect Ian Robinson:
Does any of this affect WebSphere? Well, nothing has changed in the core Spring framework. Regardless of what the future holds for the SpringSource Application Platform, the core Spring framework project remains complimentary to WebSphere. Like fish and chips.remains committed to portability
One of the main advantages of the SpringSource Application Platform is its ability to provision dependencies on an as-needed basis. The benefits of this are two-fold: it ensures that the Platform’s memory footprint is as small as possible and it allows applications to be deployed without encapsulating all of their dependencies in a monolithic deployment unit, e.g. a WAR file. To take advantage of these capabilities you will require an understanding of the Platform’s provisioning repository and this blog intends to provide just that.