dm Server 2.0.0.M4 has been released, and is now available for download.

We've made a lot of progress since 2.0.0.M3, adding a number of new features upon which the users tracking the nightly builds have already given us some excellent feedback. Take a look at the M4 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

dm Server now embeds Medic: our OSGi serviceability project

As part of the work on M4, we've moved dm Server's serviceability support out into a separate ASL-licensed project called Medic. As part of this move, we've also taken the opportunity to make some significant improvements:

• The logging support is now based on LogBack which means that users now have complete control over the format of log output and have the complete range of LogBack's appenders available to them.
• Support for serviceability dumps is now fully extensible. User code running in dm Server can now contribute to serviceability dumps simply by publishing a DumpContributor implementation to the service registry.
• Event log support (the coded messages that are output to the console) is also available to user code. Event log entries can be generated using an EventLogger which can be obtained from the service registry.

We'll be blogging more about Medic, covering how to use it both in dm Server and in plain OSGi, in the coming weeks.

Support for deploying properties files

Properties files can now be deployed to dm Server, either through the admin console, or by dropping them into the pickup directory. When a properties file is deployed, a ConfigurationAdmin Configuration is created with a pid derived from the name of the properties file. For example deploying a properties file named com.foo.bar.properties will create a Configuration with the pid com.foo.bar.

Admin console enhancements

We've some significant improvements to the admin console in M4. Chris already covered some of these in his recent blog.

In addition to the enhancements that…

dm Server 2.0.0.M3 has been released, and is now available for download.

In the sprints since 2.0.0.M3, we've made significant progress towards the final release, both in terms of new features, and in defect fixes. Take a look at the M3 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

Integration of the OSGi Web Container reference implementation

dm Server now contains the OSGi Web Container reference implementation and uses and builds upon it for all of its web support. As part of this work we've also moved to using the standard XML format for the configuration of Tomcat in dm Server.

Dump analysis in the Admin Console

A new Dump Inspector has been added to dm Server's admin console. The Dump Inspector can be used to examine diagnostic dumps produced by dm Server's serviceability component.

Using Git as our version control system

We've recently moved dm Server's source code to Git as we felt that we could benefit significantly from Git's distributed nature and its excellent support for branches. If you're interested in accessing dm Server's source code, and in building dm Server from source, instructions for doing so now that the code is hosted in Git can be found below.

Documentation updates

A number of the newly-added features are now covered in the dm Server user guide and programmer guide.

Use of ConfigurationAdmin

dm Server now makes extensive use of ConfigurationAdmin to manage its configuration. This has resulted in changes to dm Server's configuration files and their format. The new files and format are described in the updated user guide.

Updated application development guide

We've updated our guide to creating an enterprise Java application with dm Server to bring it up-to-date with the 2.0 line.

Working with dm Server's source code

dm Server's Git repositories

Repository URL	Contents
git://git.springsource.org/dm-server/util.git	General-purpose utility code
git://git.springsource.org/dm-server/artifact-repository	Artifact repository
git://git.springsource.org/dm-server/osgi-extensions.git	OSGi extensions and Equinox hooks
git://git.springsource.org/dm-server/kernel.git	dm Kernel
git://git.springsource.org/dm-server/web.git	OSGi Web Container integration and extensions
git://git.springsource.org/dm-server/servlet.git	Admin console
git://git.springsource.org/dm-server/hosted-repository	Hosted Artifact repository
git://git.springsource.org/dm-server/documentation.git	Documentation
git://git.springsource.org/dm-server/dm-server.git	Packaging

Building dm Server from source

Setup

Before you can build dm Server from source, the following will have to be setup on your machine:

• Java 6 installed and the JAVA_HOME environment variable configured to point to it
• Ant 1.7.1 or later installed
• An ANT_OPTS environment variable configured to provide a max heap of at least 512MB, e.g. ANT_OPTS=Xmx512m
• Git client

With this setup complete you're ready to build dm Server.

Packaging published binaries

The easiest way to build a packaged dm Server zip file is to build one from existing binaries that have already been published:

git clone git://git.springsource.org/dm-server/dm-server.git
cd dm-server
git checkout --track 2.0.0.M3 -b 2.0.0.M3
ant…

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…

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.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
}

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: 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…