Spring For JavaServerFaces - TSSJS Slides and Demos

Engineering | Keith Donald | March 27, 2008 | ...

Today I am delivering a presentation entitled Spring for Java Server Faces at TSSJS in Las Vegas. The presentation looks at how JSF and Spring fit together, and walks the audience through approaches to integrating these two technologies.

The slides are available for your viewing pleasure, and for you to use as you see fit.

In the presentation, I outline two approaches to integrating JSF and Spring. The first approach is what I call "JSF-centric", which is the integration approach most folks with a traditional JSF background employ today. The second approach is what I call "Spring-centric…

Spring Java Configuration - What's New in M3

Engineering | Chris Beams | March 26, 2008 | ...

Today marks the third milestone release of the Spring Java Configuration project (JavaConfig for short). The release contains numerous bug fixes and new features - I'll highlight a few of the most interesting changes below, but first let me give a quick refresher as to what JavaConfig is all about.

If you have any experience with Spring, the following snippet of XML configuration will likely be familiar. Let's assume we're looking at a file named application-config.xml:


<beans>
	<bean id="orderService" class="com.acme.OrderService"/>
		<constructor-arg ref="orderRepository"/>
	</bean…

Using a Hybrid Annotations & XML Approach for Request Mapping in Spring MVC

Engineering | Rossen Stoyanchev | March 23, 2008 | ...

In Spring 2.5 it is possible to use annotations to configure all parts of a web application. Seeing annotations applied is particularly interesting in the Web layer where developers traditionally rely on the SimpleFormController and the MultiActionController for form page handling. The introduction of annotations has created a third option, one that does not require a base class while still offering the flexibility of previous approaches.

While it is easy to see the elegance in using annotated POJOs to implement Controllers, the benefit is not as clear in the area of URL-to-Controller…

SpringSource Tool Suite Released

Engineering | Christian Dupuis | March 20, 2008 | ...

This year's EclipseCon was the first that we attended as a company. We had quite a few talks, which were all well received and we announced the beta program for SpringSource Tool Suite. Overall we all had a very great time and we got lots of feedback from the Eclipse community about the projects in the Spring Portfolio and especially what we are doing in the web space. I'll make sure to forward all the feedback to the project leads in the coming weeks. Since EclipseCon is coming to its end today, I finally found time to sit down and write about what we introduced at the conference.

We unveiled the Personal Use Edition of SpringSource Tool Suite (STS) during our BoF on Monday and I have spent a lot of time talking and mailing to people about what extra value it brings. In this blog I will outline the features of the SpringSource Tool Suite in more detail. First of all, I have heard quite a few times that people think that the announcement of the SpringSource Tool Suite means that we will stop improving and shaping Spring IDE. Please let me make the point that this absolutely not the case; actually the opposite is true and already evident by taking a look at the Spring IDE JIRA and Subversion repository. In fact since I joined SpringSource in January, I was able to increase the amount of time that I spent on Spring IDE while working on the tool suite in parallel.

The goal of the SpringSource Tool Suite is to give you the most sophisticated development tools for doing enterprise development with the Spring Portfolio on the Eclipse platform - sounds like marketing slang but that is the mission statement the tools team is committed to. STS certainly builds on top of the proven Spring IDE but it ties deeply into Eclipse Mylyn and already extends both open source tools to bring enterprise level extensions into your IDE. With the effort to provide the best Spring tooling available we already started and continue to add tooling related features, hooks and extension points into the Spring core framework and other Spring projects.

So with the tool suite you finally get all the benefits of Mylyn's Task-Focused User Interface for doing Spring development. You get context management and focusing while working on Spring application blueprints. Additionally we took the Task-Focused UI approach to a new level and introduced a new technology that we named Task-Focused Tutorials. Task-Focused Tutorials extend the Eclipse Cheat Sheet framework and add task-focusing to each step of the tutorial. With a Task-Focused Tutorial a user - someone new to Spring or someone who wants to learn a certain feature or Spring project - will be able to import a running sample application with a single click and start exploring the sample. Each tutorial step will then provide an explanation of a certain aspect of the tutorial and show only those Java and Spring elements that are relevant to understand and explore the explanation.

Task-Focused Tutorials

From the above screenshot you can see how that looks in Eclipse. The tutorial brought the PetClinic sample application into the Eclipse workspace and focused the workspace to show only the @Autowired annotation and how it is applied to application components. On the right side you can see the expanded step that explains how and why you should use the @Autowired annotation. At the very end of the tutorial the user is able to launch the sample application on a bundled Tomcat server that is automatically installed and configured; again just with a single click.

We think that this way of introducing new features and products is a very powerful approach and makes it really easy for people to explore the Spring Portfolio. Everything a developer needs to have and know when getting started is right where it should be: inside the IDE. When you download the Personal Use Edition Beta you will have instant access to around 20 tutorials that have all been created by either project leads or experienced consultants that directly work with clients. Most notable Adrian Colyer took time to create 7 tutorials that introduce OSGi concepts, Equinox and Spring Dynamic Modules. These tutorials are really cool if you want to jump on the OSGi train right now. The tool suite contains a automatic OSGi bundle update/refresh mechanism that finally allows working on applications and get instant redeploy semantics based on the power of the OSGi runtime (have you ever tried that with EJBs; I did).

The next feature I would like to talk about is called Runtime Error Analysis: the SpringSource Tool Suite is able to provide information on how to solve runtime problems by analyzing Java stack traces. To make that happen we created a online knowledge base that is integrated into the suite and which is being queried right inside the Eclipse IDE. The knowledge base is open for everybody using the tool and we even encourage people to contribute their own analyses by using build-in rich editing features. Take a look at the following screenshot.

Runtime Error Analysis

With the tool suite you don't only get support for analyzing runtime errors but also the tool will help to find common pitfalls and Spring best-practice violations. Especially while working on XML bean definition files this feature becomes really handy as it will inform the developer right inside the XML editor that there is something in the file that he/she might want to revise. For example the tool will detect and recommend the usage of bean inheritance under certain circumstances. Also it will recommend the usage of the constantly improving namespace elements instead of using traditional style bean definitions. Here is an example:

Runtime Error Analysis

So lets see what we got:

  • Spring Development Tools
  • Mylyn's Task-Focused User Interface for Java, Resources and Spring application blueprints
  • Task-Focused Tutorials
  • Runtime Error Analysis
  • Best Practice and Architecture Review tools

There are more features that I haven't touched on. Do you see the main theme in this feature line-up? The last three listed features provide invaluable assistance to develop powerful Spring-based applications. Internally we started to use a metaphor for that feature set: Consultant in a Box. With the SpringSource Tool Suite we want to give access to SpringSource knowledge as if you had a consultant sitting next to you!

I would like to encourage everybody to head over to the beta registration page and give the Tool Suite a try. In closing I also want to say thanks to everybody who has already submitted feedback, issues and suggestions. I will get back to all of you as soon as this overwhelming week at EclipseCon has ended.

Spring Dependency Injection & Java 5 (including slides and code)

Engineering | Alef Arendsen | March 18, 2008 | ...

I'm writing this as I'm on my way to Cairo. We're flying just West of Italy and I have clear view on the Italian coast line, with its blue waters and waves gently moving towards shore. It must be nice down there now. I'm heading to Cairo for a meeting of the Egyptian User Group, organized by Ahmed Hashim, who no doubt will have done an excellent job, I'm sure of that. I'll be presenting on Spring with the theme this time being Dependency Injection, type safety and Java 5. Yesterday (March 14th that is), I did almost the same presentation at the Profict Wintercamp in Loenen, NL for an audience…

Spring Web Flow 2.0 M4 - Feedback Requested

Engineering | Keith Donald | March 11, 2008 | ...

The Web Flow team has been working hard on Web Flow 2. We just reached our 4th milestone and will enter release candidate status as early as next week. The 2.0 final release is scheduled for the end of the month.

Between now and 2.0 final, we'd like your feedback! If you are an application developer currently using Web Flow 1.x, or evaluating Web Flow for use in your project, please give 2.0 M4 an evaluation and let us know what you think. If you are a web framework provider integrating the Web Flow engine into your framework, we encourage you to evaluate the refined hooks in 2.0 M4 and…

Enabling Test Driven Development in GWT client code

Engineering | Iwein Fuld | February 19, 2008 | ...

In the past months I've been working with various clients on projects using Google Web Toolkit [GWT]. I like GWT primarily because of the Java to javascript compiler. This is the key to the door letting mere mortal Java developers create RIA's without having to learn a new language.

I've allways been a fan of test driven development, and to my disappointment at first sight it looked like TDD and GWT were not going to play together.

Testing GWT code is a bit problematic. The core of the problem is that GWT code is compiled to javascript before it is run. In many cases a GWT.create() statement…

Creating OSGi bundles

Engineering | Costin Leau | February 18, 2008 | ...

When approaching OSGi, one of the first concepts that have to be learned is the notion of a bundle. In this entry, I'd like to take a closer look of what a bundle actually is and how a vanilla jar can be transformed into an OSGi bundle.  So, without further ado,

What is a bundle?

The OSGi spec describes the bundle as a "unit of modularization" that "is comprised of Java classes and other resources which together can provide functions to end users.". So far so good, but what exactly is a bundle? Quoting the spec again:

a bundle is a JAR file that:

  • Contains [...] resources
  • Contains a manifest file describing the contents of the JAR file and providing information about the bundle
  • Can contain optional documentation in the OSGI-OPT directory of the JAR file or one of its sub-directories

In short, a bundle = jar + OSGI information (specified in the JAR manifest file - META-INF/MANIFEST.MF), no extra files or predefined folder layout are required. This means that all it takes to create a bundle from a jar, is to add some entries to the JAR manifest.

OSGi metadata

The OSGi metadata is represented by manifest entries that dictate to the OSGi framework what the bundle provides or/and requires. The specification indicates around 20 manifest headers but we will just take a look at the ones you are most likely to use.

Export-Package

As the name implies, this header indicates what packages (available in the bundle) are exported so they can be imported by other bundles. Only the packages specified by the header will be exported, the rest will be private and will not be seen outside the containing bundle.

Import-Package

Similar to Export-Package, this header indicates the packages that are imported by a bundle. As well, only the packages specified by this header will be imported. By default, imported packages are mandatory - the importing bundle will fail to start, if the imported package is not available.

Bundle-SymbolicName
The only required header, this entry specifies a unique identifier for a bundle, based on the reverse domain name convention (used also by the java packages).
Bundle-Name
Defines a human-readable name, without spaces, for this bundle. Setting this header is recommend since it can provide a shorter, more meaningful information about the bundle content then Bundle-SymbolicName.
Bundle-Activator
The BundleActivator is an OSGi specific interface that allows Java code to be notified when a bundle is started or stopped by the OSGi framework. The value of this header should contain a fully qualified name of the activator class which should be public and contain a public constructor without any arguments.
Bundle-Classpath
This header is handy when the jar contains embedded libraries or class packages under various folders, by extending the default bundle classpath (which expects the classes to be available directly under the jar root).
Bundle-ManifestVersion
This little known header indicates the OSGi specification to use for reading this bundle. 1 indicates OSGi release 3 while 2 OSGi release 4 and later. Since 1 is the default version, it is strongly recommended to specify this header since an OSGi release 4 bundle will not work as expected under OSGi release 3.

Below is an example, taken from Spring 2.5.x core bundle manifest that uses some of the headers mentioned above:

 
Bundle-Name: spring-core 
Bundle-SymbolicName: org.springframework.bundle.spring.core 
Bundle-ManifestVersion: 2 
Export-Package:org.springframework.core.task;uses:="org.springframework.core,org.springframework.util";version=2.5.1 org.springframework.core.type;uses:=org.springframework.core.annotation;version=2.5.1[...] 
Import-Package:org.apache.commons.logging,edu.emory.mathcs.backport.java.util.concurrent;resolution:=optional[...] 

Most of the time used on OSGi metadata is likely to be spent on Export/Import package entries as they describe the relationship between bundles (that is, between your modules). When it comes to packages, nothing is implicit - only packages that are mentioned are imported/exported, the rest aren't. This applies also to sub-packages: exporting org.mypackage will export just this package and nothing else (like org.mypackage.util). Same goes for importing - even if a package is available inside the OSGi space, it will not be seen by a certain bundle unless it is explicitly imported by it.

To summarize, if a bundle A exports package org.mypackage and bundle B wants to consume it, then the META-INF/MANIFEST.MF for bundle A should specify the package inside its Export-Package header, while bundle B should include it in its Import-Package entry.

Package consideration

While exporting is fairly straight forward, importing is slightly more complex. It is common for applications to degrade nicely by searching the environment for certain libraries and using only what is available, or for libraries to include code that is not used by the user. Such examples include logging (using JDK 1.4 or Log4j), regular expressions (Jakarta ORO or JDK 1.4+) or concurrent utilities (java.util in JDK 5 or backport-util-concurrent library for JDK 1.4).

In OSGi terms, relying on a package based on its availability translates to an optional Package-Import. You have already seen such a package in the previous example:

```code Import-Package: [...]edu.emory.mathcs.backport.java.util.concurrent;resolution:=optional ```

Since in OSGi, multiple versions of the same class can exist, it is best practice to specify the version of the class package both when exporting and importing a package. This is done through the version attribute which is added after each package declaration. The version format supported by OSGi is <major>.<minor>.<micro>.<qualifier> where major, minor and micro are numbers and qualifier is alphanumeric.

The meaning of the version is completely up to the bundle provider however, it is recommend to use a popular numbering scheme such as the one from Apache APR project where:

  • <major> - indicates a significant update which doesn't guarantee any compatibility
  • <minor> - indicates an update which preserves compatibility with older minor versions
  • <micro> - represents an insignificant update from the user point of view which is perfectly compatible both forwards and backwards
  • <qualifier> - is a user defined string - it is not widely used and can provide an additional label to the version number, such as the build number or target platform without a standardized meaning

The default version (if the attribute is missing) is "0.0.0".

While the exported packages have to indicate a specific version, the importers can indicate a range using the mathematical interval notation - for example

[1.0.4, 2.0) will match version 1.0.42 and upwards up to 2.0 (excluding). Note that an specifying only a version instead of an interval will match all packages that are at greater or equal then the specified version, that is :

Import-Package: com.mypackage;version="1.2.3"

is equivalent to

Import-Package: com.mypackage;version="[1.2.3, ∞)"

As a last tip, make sure to always use quotes when specifying an version, whether it is a range or not.

Working with OSGi metadata

Now that we have some information on what bundles are, let's see what tools we can use for osgi-fying an existing jar:

by hand

This do-it-yourself approach is discouraged as typos and extra spaces can easily sneak in and render the manifest useless. Even when working with a smart editor, the manifest format itself can cause some problems since it has a limit of 72 spaces per line which, if broken, can cause some cryptic problems. Manually creating or updating the jar is not a good idea since the jar format requires the META-INF/MANIFEST.MF entry to be the first one in the archive - if it's not, even though it's present in the jar, the manifest file will not be read. The manual approach is really recommended for cases where there are no other alternatives.

However, if one really wants/needs to work directly with the manifest, then a editor that can deal with UNIX/DOS spaces should be used along with a proper jar creation utility (such as the jar tool that comes with the JDK) to cope with all the MANIFEST requirements.

Bnd

Bnd stands for BuNDle tool and is a nice utility created by Peter Kriens (OSGi Technical Officer) that "helps [...] create and diagnose OSGi R4 bundles". Bnd parses the java classes to understand the available and imported packages so it can create the equivalent OSGi entries. Bnd offers a series of directives and options which can customize the resulting artifact. The nice thing about bnd.jar itself is that is can be run from command line, by Ant through dedicated tasks or integrated into Eclipse as a plug-in.

Bnd can create jars from the classes available on the classpath or inside Eclipse projects or can osgi-fy existing jars by adding the needed OSGi artifacts. Additionally, it can print and verify the OSGi information about the given jar making it quite a powerful, yet simple to use tool.

First time users, can use Bnd to see what OSGi manifest will be added to a vanilla jar. Let's pick a vanilla jar such as c3p0 (which is an excellent connection pool library) and issue a print command:

```code java -jar bnd.jar print c3p0-0.9.1.2.jar ```

The output is fairly big and contains of several sections:

  1. Generic manifest information:
    [MANIFEST c3p0-0.9.1.2.jar]
    Ant…

Spring Batch Recent Changes and Upcoming m4 Release

Engineering | Dave Syer | February 04, 2008 | ...

We've been working really hard on Spring Batch getting ready for the Spring Portfolio 2.5 release train, and I thought it would be a good time to update everyone on what is happening. In this article I'm going to expand a bit on the domain modelling, and our decision to raise the profile of some of the core domain objects, and increase their responsibilities. I will also give a few tastes of what is coming in the next couple of releases leading up to 1.0, so people have a chance to comment if they want to.

By way of an apology: there have been some quite significant changes in the internals…

Some Decisions are Easy – Like SpringSource Acquiring Covalent

Engineering | Rod Johnson | January 29, 2008 | ...

My last blog showed how Spring is soaring past EJB. Research by BZ Media and others shows that Apache Tomcat is the leading open source application server with a 64% market penetration. The dominance of Spring and Tomcat is well-known. What people may not know as well is that thousands of organizations are running Spring on Tomcat as their middleware infrastructure. Those organizations want one company to turn to for the products and services they need to be successful.

Today we announced our acquisition of Covalent Technologies. Not only does Covalent bring Apache leadership, but our combined company now has significant leadership on Apache Tomcat and HTTP. Two weeks ago, Sun paid $1bn for the "M" in LAMP. Now that Covalent's outstanding Apache expertise and services are part of SpringSource, we are strong leaders in the “A”. We have always been about technology leadership, so we're very excited about what we can do together with Covalent. Over the last few years, Covalent has earned a great reputation in the marketplace with its support for Apache projects, including Tomcat and Apache HTTP. Its hundreds of support customers include more than half of the Fortune 500, and household names like Pfizer, Johnson & Johnson, British Telecom (BT), NASA, Intel, Royal Bank of Scotland and Bear Stearns. Our announcement…

Get the Spring newsletter

Thank you for your interest. Someone will get back to you shortly.

Get ahead

VMware offers training and certification to turbo-charge your progress.

Learn more

Get support

Tanzu Spring Runtime offers support and binaries for OpenJDK™, Spring, and Apache Tomcat® in one simple subscription.

Learn more

Upcoming events

Check out all the upcoming events in the Spring community.

View all