Pluggable styling with SpringSource Slices

Engineering | July 10, 2009 | ...

Since we announced SpringSource Slices, a number of users and customers have asked about using Slices to make the styling and branding of their Web sites pluggable. In this blog, I'll demonstrate how easy it is with Slices.

Pluggable styling

I have a standard war file, named styled.host.war, that contains a very simple index.html page:

<html>
	<head>
		<title>SpringSource Slices Pluggable Styling Demonstration</title>
		<link rel="StyleSheet" href="styles/main.css" type="text/css" />
	</head>
	<body>
		<div class="header">
			<div class="title">SpringSource Slices</div>
			<div class="subtitle">Pluggable Styling Demonstration</div>
		</div>
	</body>
</html>

As you can see, it's looking for a CSS file…

Deploying WARs to the OSGi Web Container is now even easier

Engineering | June 16, 2009 | ...

As Rob mentioned in his introduction to the OSGi Web Container, dm Server automatically imports system packages into Web bundles. This has proved very useful, especially when deploying existing WAR files into an OSGi environment. I've recently spent some time moving this functionality from dm Server's Web subsystem into the OSGi Web Container RI. This blog describes the new functionality, and how to make use of it.

Enabling import of the system packages

There are two ways in which you can instruct the RI to import all of the exported system packages.

When you install a Web bundle, you can now use the SpringSource-SystemPackages…

dm Server 2.0 M2

Engineering | May 19, 2009 | ...

dm Server 2.0.0.M2 has been released, and is now available for download. In the two sprints since 2.0.0.M1, we've made significant progress towards the final release, both in terms of new features, and in defect fixes. Take a look at the M2 release notes if you're interested in seeing everything that we've been working on. Please keep your feedback coming as comments on our blog, in the forums, and on JIRA.

New and noteworthy

Spring 3 support

In the milestone, we've upgraded dm Server to run on Spring 3. As we move towards the final release of dm Server 2.0, we'll be upgrading the version of Spring 3 as new milestones and snapshots become available.

Improvements to cloning

We've made some significant improvements in our support for auto-cloning. For example, you can now run Spring 2.5.6 and Spring 3-based applications side-by-side in the same dm Server.

Watched repositories

Support for watched repositories has been added. A watched repository is configured to watch a directory on your filesystem and, as artifacts are added to the directory, they will become available to dm Server's provisioning system. Equally, as artifacts are removed from the directory, they will no longer be available to dm Server's provisioning system.

Here's some example configuration for a watched repository:

"watched-repo" : {
    "type" : "watched",
    "watchDirectory" : "repository/watched",
    "watchInterval" : 5
}

Working with SpringSource Application Platform's provisioning repository

Engineering | May 09, 2008 | ...

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.

Where is the provisioning repository and how does it work?

By default the Platform's provisioning repository can be found in the repository directory at the root of the installation: Directory structure of the provisioning repository

Directory structure of the provisioning repository

As you can see, there are three main directories: bundles, installed and libraries. installed is for the Platform's internal use so we'll focus on the bundles and libraries directories here. Each contains a number of subdirectories to separate the different types of dependencies:

ext contains external dependencies that are provided with the Platform but are not part of the Platform itself.
subsystems contains all of the subsystems that comprise the Platform.
usr is initially empty and is intended to contain user-added dependencies, i.e. anything upon which your applications depend that is not already provided by the Platform.

The Platform searches the repository directory structure for both bundles and libraries during its initial startup. I'll talk about how this searching can be configured later on in this entry. As bundles and libraries are found within the repository, details of their symbolic names, exported packages etc. are added to an in-memory index of the repository. Upon completing the scan the in-memory indexes are cached to disk. Minimising the Platform's startup time was a priority for us during development. This caching allows the Platform to save some time during startup: it can skip the scan unless it detects that the contents of the repository have changed.

Runtime provisioning

In a plain OSGi environment a bundle's dependencies can only be satisfied by other bundles which have already been installed in the environment. For example, installing and starting a bundle that imports the org.apache.commons.dbcp package will fail if no bundle which exports that package has already been installed. This can be a real pain for users as they have to manually install all of a bundle's dependencies. Thankfully, the SpringSource Application Platform improves upon this significantly by dynamically installing dependencies on an as-needed basis.

When a deployed application is started by the Platform its…

Andy Wilkinson

Pluggable styling with SpringSource Slices