While a relatively young project, each version of Spring Dynamic Modules (even minor ones) offers new functionality. This chapter is a guide to the new and improved feature and intended as a high-level, short summary. Please follow the appropriate links for more in-depth information.
Spring DM served as the basis for the Blueprint Container specification, introduced by OSGi 4.2. Spring DM 2.0 stands as the RI for the aforementioned specification, providing the Blueprint API and implementation out of the box. Various aspect of Spring DM have been adjusted for consistency to the Blueprint specification. For more information on the two models, see Chapter 5, OSGi 4.2 Blueprint Container for more information.
As of 2.x, Spring DM requires JDK 5 to run (or compile). The framework code has been
revised to take advantage of the JDK 5 features such as language improvements, concurrency and generics: for example, various enum-like classes
used by the exporter and importer API have been deprecated and replaced with proper Java 5
Considerable effort has been spent to keep the code backwards compatible however, it is recommended to compile the code against the Spring DM 2.x
code and perform sanity checks before upgrading.
Besides the Java 5 upgrade, DM 2.0 requires Spring 3.x to get access to the latest framework features and JDK optimizations.
2.0.x provides several improvements for service imports (whether single or collection based) in terms of speed, configuration and service lifecycle. Section 8.2, “Defining References To OSGi Services” provides more details.
Continuing the work in 1.2.x, Spring DM 2.0 executes all user code using its credentials (the managed bundle permissions). See Appendix B, Security Integration for more information.
Since 1.2.x, Spring Dynamic Modules is aware of secured environments by making use of dedicated privileged blocks for executing security sensitive code. Thus, Spring DM can run as a trusted library without requiring escalated permissions for its managed bundles. See Appendix B, Security Integration for more information.
Since 1.2.0 M2, the Spring DM bundles symbolic names have been aligned with Spring's 2.5.6+. Thus the prefix
org.springframework.bundle.osgi has been changed to
org.springframework.osgi; for example
Spring DM extender symbolic name was changed from
(notice the missing
bundle word). Additionally, the documentation has been updated to reflect Spring 2.5.6+ symbolic names.
To minimize the number of repositories used and the confusion caused by OSGified vs non-OSGified artifacts especially to users using Spring dm Server,
after 1.2.0 RC1, Spring Dynamic Modules aligned as many of its dependencies as possible with SpringSource EBR.
In practice this means that Spring framework artifacts, such as
spring-aop.jar can be now found as
We apologize for any inconvenience created to users relying on these naming conventions.
The biggest feature in Spring Dynamic Modules 1.1.x is the transparent support for web applications on OSGi platforms. By integrating directly with web containers (such as Apache Tomcat and Jetty), Spring DM allows WARs using Servlet, JSP and taglib technologies to be used with little or no effort at all. Please see Chapter 10, Web Support for details.
Additionally, with 1.1.x it is possible to run Spring-MVC applications inside OSGi environments. See Section 10.7, “Spring-MVC Integration” for more information.
1.1.x adds support for
classpath*: prefixes to the OSGi
abstraction. This allows the discovery of classpath resources (such as Spring's
component scanning) to
work out-of-the-box across multiple bundles on the supported OSGi platforms. See Section 6.4, “The Resource Abstraction” for more information.
1.1.x makes it easy to change the default configuration for the various extenders used by Spring DM. By using fragments, users can customize the way application contexts are started, the web container used for web deployment or the thread-pool for running Spring applications. Additionally, it is possible to receive events regarding the OSGi Spring application contexts lifecycle. Section 6.1, “The Spring Dynamic Modules Extender Bundle” lists the available options and explains them in detail.