VMware offers training and certification to turbo-charge your progress.Learn more
(updated 15Oct2009) Beginning in milestone M5, dm Server 2.0 employs regions to isolate the kernel from users’ applications. This means that the kernel implementation is almost completely invisible to applications and to application management.
Also in milestone M5, support for cloning is completely removed. Region isolation and scoped plans between them offer much simpler and more manageable solutions to the most common problems that cloning was intended to address.
In the following two sections I outline these changes, and the reasons we made them.
dm Kernel creates a single User Region in which to run applications and all applications (including the ones that dm Server supplies—Splash, Admin, Web and Hosted Repository) are deployed into the User Region.
Kernel bundles are not installed in the user region (apart from a few needed for region management). The necessary function to support the kernel runs in the OSGi framework, but the user region applications cannot see it, except for the services that are normally offered. The applications are isolated from the kernel implementation.
This isolation has many benefits: for example, it is no longer necessary for the kernel and the users’ applications to use the same version of the Spring Framework. (In fact the kernel doesn’t install all of the Spring Framework—it doesn’t need to.) If the kernel is updated it is far less likely that applications will need to be upgraded or adjusted to accommodate this. The kernel implementation is therefore much more stable and resilient and applications are much more likely to survive kernel upgrades between releases.
For example, sharing bundles with static state may not be desirable, and being able to have a copy (clone) of such a bundle means that different applications can use the different clones (the application scoping mechanism allows us to have multiple copies installed in the framework under distinct names). In another case, when a lower-level bundle is pinned by a dependency through a common intermediary (which is often part of the Spring Framework), cloning the intermediary allows the clone to depend upon a different lover-level bundle, freeing the clone to satisfy a transitive constraint the original intermediary could not.
In the milestone releases of dm Server 2.0 (up to M4) cloning support (both manual and automatic) has been available. We have received a lot of feedback and experience from this implementation and as an experiment it has proved fruitful. However, time and experience have shown us that this is not yet ready for production, so cloning is removed from M5, and will not be part of the final 2.0 release. Region isolation, together with scoped plans, can be used to manage the most common problems that cloning was designed to address. These solutions are much easier to understand and much easier to support in production.
Manual cloning is relatively stable, but even here there are problems:
Finally, the cloning implementation had to include Spring dependencies as a special case in order to work efficiently. The Spring DM extender also introduced special cases: these do not generalise at all well for other extenders and other libraries. It’s just too Spring-specific.
Overall, although some of the achievements of cloning and auto-cloning were impressive, the function is simply not stable enough to support in the field and is therefore removed in the interests of overall quality and stability.
The most important problems can be solved by region isolation and explicit scoping.
The pinning problems were nearly all produced through the Spring Framework, so the isolation of the user region offers a solution to most of these issues.
Other common cases can be solved through appropriate use of scoped applications, and this is actually a much more controllable and supportable way of managing the artefacts installed in the server. Scoped plans make it easy to create the desired scopes, and the resolution wiring remains stable during production as the framework context changes.